TI中文支持网各位大牛：
我目前在做dm368的实时解码，参考demo中的decode程序，码流由编码端编码后，通过网络发送给解码端，由解码端实时解码，然后送给hdmi输出。目前发现一个比较尴尬的问题。
图片的分辨率为1280*720，解码后输出的buff，其中dim的x、y分别为24和48，图像在整个buff中的坐标为（24,48），通过查看dmai对应的display接口，发现只有y被设置到内核，而x没有被设置到内核中。从而显示横向出现右偏移，即最左边的24列像素点是无效的（被拉长），最右边缺少24列像素点。而纵向由于设置正确，显示是没有问题的。
刚开始，我以为是我的程序有问题。因此我用的dvsdk原生的decode程序以及自带的264文件测试，发现也有同样的问题。这个问题不仔细查看，是很难看出的。因此我猜测，这个应该是一个共性bug。
我尝试新建显示buff，通过framecopy，将解码后偏移为（24，48）的buff拷贝到偏移为（0，0）的buff中，再送显，图像就正常了，但测试时发现，framecopy占用cpu资源，会导致码流接收丢帧，总出现解码错误，因此该方案暂没继续实施。
在这里请教各位大牛，有没有更好的办法，这个bug还是比较明显的，相信不止我一个人碰到。
非常感谢！
kooking：
好像没这么复杂吧，有个startx之类的参数设置一下就可以了，我晚上回去看看代码
zhoutao：
顶下。我碰到同样的问题，求解。。。。。。。。
Chris Meng：
回复 kooking:
你好，
请问你是否有参考过h264dec user guide里面的Figure 3-3. Frame Buffer Pointer Implementation？你使用的是IVIDDEC_OutArgs->displayBufs作为显示输出的buffer首地址么？
zhoutao：
回复 Chris Meng:
你好，
我用DM368，用dvsdk-demos_4_02_00_01的例子decode，做的测试，出现的问题和一楼的问题一样，就用例子里的的程序（没做任何修改）
root@dm368-evm:/usr/share/ti/dvsdk-demos# ./decode -y 3 -v ../data/videos/davincieffect.264
出现的问题和一楼的问题一样，左边多了一条24点宽的白边（把最左边的点拉长24点）
仔细查了下例子里，用的是IVIDDEC_OutArgs->displayBufs作为显示输出的buffer首地址.
Chris Meng：
回复 zhoutao:
你好，
davincieffect.264的原始大小是720×480还是1280×720？-y 3应该是720p输出，如果原始图像是D1的，建议用CVBS输出看看原图大小的时候是否有偏移。
zhoutao：
回复 Chris Meng:
davincieffect.264的原始大小是1280×720
xue bing：
回复 Chris Meng:
不好意思,最近一直没时间上论坛.
我用的是DMAI的标准接口.
xue bing：
回复 Chris Meng:
不好意思,最近一直没时间上论坛.
我试过480P 576P 720P格式的解码输出,所有的buff全部都是偏移(24,48).
xue bing：
回复 zhoutao:
各位,此问题已经完美解决,该问题分析起来比较复杂,但修改起来很容易,在此简单提示一下:
1 因为ti的架构要求大多数buff都要32字节对齐,有些还要64字节对齐.因此很难从上层直接修改,我的做法是直接在venc修改,将venc set timeing接口的HSTART加上24,当然,如果想提高兼容型,可以申请一个字符设备,将这个偏移通过ioctl传递下来.
这一条是解决左边24个点拉伸的问题
2 在应用层修改display设备的width,将width修改为linelength&(~0x3F),即比例linelength小,但还要64字节对齐(720P的话,这个值是1344).同时修改dmai和对应的驱动,使这个值能设置下去(把范围放开就行了,widthmax放到2000就行了)
这一条是解决右边被裁掉的24个点
不要试图从应用->osd->venc一步一步下来,因为根本不可行.
ps:
TI的测试,把关不严啊,这么严重的问题,居然直接放出来了.相信坑了不少兄弟,各位如果用到了dvsdk包作解码显示,建议赶紧看看自己的显示,会不会左边被拉伸,右边被裁减了.
