DM642 图像存储格式

（一）：我们实验室的板卡用到的解码芯片是TVP5150，大家都知道这款芯片本身不支持缩放，通过配置其寄存器，得到一个8-BIT的BT.656格式的数字视频流—其Y:Cb:Cr为4:2:2.（这个视频流的分辨率应该是D1格式的吧？大家给说说）。
（二）：这个内嵌同步信号的8-BIT的数字视频流进入DM642的Video-Port，在Video-Port中自带了Filter（滤波器）（硬件实现），它可以通过配置Video-Port的寄存器来实现对流入数据的重采样，（比如，可以将流入的Y:Cb:Cr-4:2:2数据重采样成4:2:0，也可以将水平像素数缩放为原始数据的二分之一。），这些参数的具体设置在结构VPORTCAP_Params中会有（文档The TMS320DM642 Video Port Mini-Driver对该结构也有很详细的说明），我们只需对某些元素值进行修改即可。在这里，我用到了滤波器的水平二分之一缩放功能（horizontal ½-scaling）。
（三）：大家都知道，要从D1格式实现CIF格式，水平和垂直方向都应该有一个二分之一的缩放。最要紧的是如何实现竖直方向的二分之一缩放了（Vertical ½-scaling）。这也是困扰我的主要原因，因为TI的文档说到，Vertical scaling must be performed in software.我就是被这句话害得很苦啊。其实我们都知道，TVP5150是按奇偶场的方式扫描一帧图像的。竖直方向的二分之一缩放不外乎就是只取其中一场数据即可。在DATA_copy中，数据的搬移是这样的（只以亮度分量说明，Cb,Cr分量是一个道理）：
   for(i = 0; i < numLines; i ++) 
                {
                DAT_copy(capFrameBuf->frame.iFrm.y1 + i * capLinePitch, 
                     disFrameBuf->frame.iFrm.y1 + i * disLinePitch,
                     numPixels);
                }
其中，numLines=287，capLinePitch=352，disLinePitch=720，numPixels=352；这说明在本程序中，capFrameBuf中y分量的确是按奇偶场方式分开排列的。在Y中的前287行数据的确是两场数据中的一场。然而在我跑另外一个D1格式的采集与显示的例程时，我只让DATA_copy搬移capFrameBuf中y分量的前一半数据，发现图像是正常显示的，尽管只显示了图像的一半（即只显示了720*576图像的上半部分，但如果capFrameBuf中y分量的前一半数据存放的是一场数据的话，显示的图像应该是一个压扁状的图像阿）。
（四）：问题还是出在了结构VPORTCAP_Params的设置上。这个结构中有一个元素Int mergeFlds，对这一位 置1的话，表示Video-Port在将数据放入BUF之前会将两场数据糅合到一起再放入BUF中，而如果置0的话，两场数据是隔离的，即在BUF中存放顺序是先放完一场数据再紧跟着将另外一场数据存入。这也是为什么D1格式的采集与显示的例程会出现我说的上述情形，是因为在这个例程中，将mergeFlds设置为了1 。而在CIF格式的历程中，将mergeFlds设置为了0。
（五）：将mergeFlds设置为了0以后，只需DATA_copy capFrameBuf中y分量的前一半数据，即实现了搬移两场数据中的一场数据，即实现了竖直方向的二分之一缩放。于是一幅完整的CIF格式的图像数据就得到了，接着拿给应用程序处理也行，直接显示也行了。