TI中文支持网您好！
我在是用DM8127，采集bayer图像，然后1080P H264编码的时候出现数据异常。
encLink_h264.c的((IVIDENC2_Handle)handle)->fxns->process()后，H编码的数据前4个字节不是0x00,0x00,0x00,0x01.
如果我修改采集的分辨率，小于1920，那么就会出现这个问题。但是设置为1920就没有问题。
请问这个是什么情况产生的？
Chris Meng：
你好，
请问你是否有保证capturewidht是16的倍数？也就是采集buffer的宽度是16的倍数，数据可以在buffer的左侧？
ruqun xu：
回复 Chris Meng:
我的采集宽度是1600。出问题的那几帧数据的地址，都是在申请的地址的前面。
ruqun xu：
回复 ruqun xu:
我在linux 里面通过 IpcBitsInLink_getFullVideoBitStreamBufs(gVencModuleContext.ipcBitsInHLOSId,&fullBitsBufList)，
来获取编码后的数据。如果获得的(fullBitsBufList.bufs[i]->addr+ fullBitsBufList.bufs[i]->startOffset)的地址范围是a~b.
我发现出问题的那几帧都是紧靠着a地址的。
我已经在处理(fullBitsBufList.bufs[i]->addr+ fullBitsBufList.bufs[i]->startOffset)之前加上了Cache_inv（）。
Chris Meng：
回复 ruqun xu:
你好，
那我还是觉得被篡改的可能性比较大。有很多客户都使用1600×1200的分辨率来编码的。
ruqun xu：
回复 Chris Meng:
有这个可能。但是编码后的数据直接就通过ipcbitsout,ipcbitin,给到linux了。中间没有插入任何环节的。
而且出问题的永远都是开头的几个地址。很像是cache刷新的问题。
但是我已经加上了cache刷新也不管用。
Chris Meng：
回复 ruqun xu:
你好，
先在M3上打印看看，是否在M3上的时候就不对了？
ruqun xu：
回复 Chris Meng:
对的。我在h264编码后打印就不对。
在encLink_h264.c的Enclink_h264EncodeFrameBatch（）的((IVIDENC2_Handle)handle)->fxns->process(）后，打印allocatedRingBufferAddr的内容。
发现数据就不对。
ruqun xu：
回复 ruqun xu:
找到问题了。
是M3默认会在h264编码数据的地址空间之前申请一段空间用作boxcar的数据采集。
ISS的文档显示boxcar的采集的数据大小是根据图像的分辨率而变化的。
但是默认的boxcar的申请的buffer大小会不够。
所以就导致写boxcar的地址会越界到h264的数据空间去。
ruqun xu：
回复 ruqun xu:
找到问题了。
是M3默认会在h264编码数据的地址空间之前申请一段空间用作boxcar的数据采集。
ISS的文档显示boxcar的采集的数据大小是根据图像的分辨率而变化的。
但是默认的boxcar的申请的buffer大小会不够。
所以就导致写boxcar的地址会越界到h264的数据空间去。
Chris Meng：
回复 ruqun xu:
Ruqun,
非常感谢你的分享！
