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格式的图像数据就得到了,接着拿给应用程序处理也行,直接显示也行了。

你可能感兴趣的:(DM642 图像存储格式)