DM8127 H264编码数据异常

你好，

请问你是否有保证capturewidht是16的倍数？也就是采集buffer的宽度是16的倍数，数据可以在buffer的左侧？

我的采集宽度是1600。出问题的那几帧数据的地址，都是在申请的地址的前面。

       我在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（）。

你好，

那我还是觉得被篡改的可能性比较大。有很多客户都使用1600x1200的分辨率来编码的。

有这个可能。但是编码后的数据直接就通过ipcbitsout,ipcbitin,给到linux了。中间没有插入任何环节的。

而且出问题的永远都是开头的几个地址。很像是cache刷新的问题。

但是我已经加上了cache刷新也不管用。

你好，

先在M3上打印看看，是否在M3上的时候就不对了？

对的。我在h264编码后打印就不对。

在encLink_h264.c的Enclink_h264EncodeFrameBatch（）的((IVIDENC2_Handle)handle)->fxns->process(）后，打印allocatedRingBufferAddr的内容。

发现数据就不对。

找到问题了。

是M3默认会在h264编码数据的地址空间之前申请一段空间用作boxcar的数据采集。

ISS的文档显示boxcar的采集的数据大小是根据图像的分辨率而变化的。

但是默认的boxcar的申请的buffer大小会不够。

所以就导致写boxcar的地址会越界到h264的数据空间去。

Ruqun,

非常感谢你的分享！