DM385压缩问题

第一次压缩正确，参数如下：

[m3video] videnc2DynamicParams -> inputHeight : 1080
[m3video] videnc2DynamicParams -> inputWidth : 1920
[m3video] videnc2DynamicParams -> refFrameRate : 60000
[m3video] videnc2DynamicParams -> targetFrameRate : 60000
[m3video] videnc2DynamicParams -> targetBitRate : 8000000
[m3video] videnc2DynamicParams -> intraFrameInterval : 30
[m3video] videnc2DynamicParams -> generateHeader : 0
[m3video] videnc2DynamicParams -> captureWidth : 1984
[m3video] videnc2DynamicParams -> forceFrame : -1
[m3video] videnc2DynamicParams -> interFrameInterval : 1
[m3video] videnc2DynamicParams -> mvAccuracy : 2
[m3video] videnc2DynamicParams -> sampleAspectRatioHeight : 1080
[m3video] videnc2DynamicParams -> sampleAspectRatioWidth : 1920
[m3video] videnc2DynamicParams -> ignoreOutbufSizeFlag : 1
[m3video] videnc2DynamicParams -> lateAcquireArg : 0

但第二次以后，压缩错误，打印发现，参数是乱的，不知道怎么引起的

[m3video] ——— CH 0 : H264 ENC : Dynamic Params ——-
[m3video]
[m3video] videnc2DynamicParams -> inputHeight : 538976288
[m3video] videnc2DynamicParams -> inputWidth : 538976288
[m3video] videnc2DynamicParams -> refFrameRate : 538976288
[m3video] videnc2DynamicParams -> targetFrameRate : 538976288
[m3video] videnc2DynamicParams -> targetBitRate : 538976288
[m3video] videnc2DynamicParams -> intraFrameInterval : 538976288
[m3video] videnc2DynamicParams -> generateHeader : 538976288
[m3video] videnc2DynamicParams -> captureWidth : 538976288
[m3video] videnc2DynamicParams -> forceFrame : 538976288
[m3video] videnc2DynamicParams -> interFrameInterval : 538976288
[m3video] videnc2DynamicParams -> mvAccuracy : 538976288
[m3video] videnc2DynamicParams -> sampleAspectRatioHeight : 538976288
[m3video] videnc2DynamicParams -> sampleAspectRatioWidth : 538976288
[m3video] videnc2DynamicParams -> ignoreOutbufSizeFlag : 538976288
[m3video] videnc2DynamicParams -> lateAcquireArg : 538976288

Chris Meng：

Xin Jin,

可能的原因有：

1. 有代码修改了该参数，有可能是vidoe m3，也有可能是其他核越界篡改。

2. DDR不稳定，DDR上数据错误

jin xin：

回复 Chris Meng:

DDR的频率是333MHZ，使用multich_tristream_lowPower，只是三个stream，改成1个stream，去掉D1和JPEG。

而且都是有规律的，都是第二次开始。

Chris Meng：

回复 jin xin:

Xin Jin，

不修改use case，是否就没有该问题了？

jin xin：

回复 Chris Meng:

我只能通过串口烧写程序，时间较长，只有明天才能验证不修改use case 是否正常。还有一个奇怪的现象：

FPGA发送0xff,dm385收到0xef

FPGA发送0xef,dm385收到0xdf

FPGA发送0xdf,dm385收到0xcf

FPGA发送0xcf,dm385收到0xbf

FPGA发送0xbf,dm385收到0xaf

以此类推，高4位总比接收到的数据少1.