DM8127 encode link stop due to no output buffer

chinghok,

frame skipping could be because of multiple reasons like - 

1. Enc/Dec resource HDVICP running out of performance for the requested frame rate & resolution. In this case you can try increasing the clock of HDVICP.

2. Insufficient DDR b/w for the use-case

3. Insufficient output buffer (bitstream buffer) allocated for the encoder. In this case as soon as the bitstream buffer is full the encoder starts skipping frames. Whenever bitstream buffer is freed you start seeing encoding again.

Thus the next step in debug is to first figure out which of the above is causing the frame skips.

Can you check the frame skip print logic and try to deduce the reason?

Regards

Rajat

Hi Rajat,

Thank you very much for your reply.

1. Enc/Dec resource HDVICP running out of performance

- how can I check for this? The processor statistics show that only 10.4% CPU loading.

[m3vpss ] 640329: LOAD: CPU: 16.5% HWI: 5.7%, SWI:5.1%
[m3vpss ]
[m3vpss ] 640329: LOAD: TSK: IPC_OUT_M30 : 0.6%
[m3vpss ] 640329: LOAD: TSK: CAPTURE : 0.5%
[m3vpss ] 640329: LOAD: TSK: NSF0 : 0.5%
[m3vpss ] 640329: LOAD: TSK: DISPLAY0 : 0.4%
[m3vpss ] 640329: LOAD: TSK: DUP0 : 0.1%
[m3vpss ] 640330: LOAD: TSK: SWMS0 : 1.4%
[m3vpss ] 640330: LOAD: TSK: MERGE0 : 0.1%
[m3vpss ] 640330: LOAD: TSK: MISC : 2.1%
[m3vpss ]
[m3video]
[m3video] 640833: LOAD: CPU: 10.4% HWI: 2.7%, SWI:5.3%
[m3video]
[m3video] 640834: LOAD: TSK: IPC_IN_M30 : 0.3%
[m3video] 640834: LOAD: TSK: ENC0 : 1.2%
[m3video] 640834: LOAD: TSK: DEC0 : 0.6%
[m3video] 640834: LOAD: TSK: MISC : 0.3%
[m3video]

2. Insufficient DDR b/w

- We just use EMIF0 with 32 bit bus width in our design, which is differ from the APPRO's reference design, so DDR b/w maybe the issue.

- However, as I just run the multich_encode_decode usecase, with 1080p25, I think the DDR b/w is far more less than some other use case eg. full power tri-stream usecase

- Also, how can I check the DDR b/w is sufficient or not? And how can I modify the b/w settings?

3. Insufficient output buffer allocated for the encoder

- As I am running the multich_encode_decode usecase, and this demo application on the APPRO's IPNC reference design without any problem. They are just using the same number of output buffers in two platforms.

- I have try to change the encoder output buffer count from default value 4 to 8, it doesn't help much.

As I have mentioned, we use EMIF0 only in our design. Also we use capture port instead of camera port for video capturing. Will these difference be the cause of the issue? (As you know in multich_encode_decode, the captured video is duplicated and output to HDMI, I have changed the output to CVBS, and can see the video correctly at CVBS SD display)

Regards,

ChingHok

I suspect that it could be because of output buffers. 

Can you add prints in the filer encLink_common.c ? Search for 'pChObj->inFrameSkipCount++' and add a print for notification whenever skip count is increased. This way you can check what reason is responsible.

Regards

Rajat

Hi Rajat,

The incoming frames are rejected due to Utils_bitbufGetEmptyBuf() returns with pOutBuf NULL and status -1. 

Chinghok

Chinghok,

This means that the bitstream buffer pool is not able to accommodate the bitrate output of the encoder.

Can you try increasing the size of the bit buffer pool?

Also, are you trying in debug mode build or release mode? If you are in debug mode, I suggest trying with release mode build as well.

Regards

Rajat

Hi Rajat,

All previous results are build in the release mode already.

How to increase the size of bit buffer pool? Just manually edit the source code of "UTILS_ENCDEC_GET_BITBUF_SIZE"? I have try to double the size, there is no improvement.

I have further compare the result of "Utils_bitbufGetEmptyBuf" when the same application is run on Appro's IPNC and our platform, I found that on Appro's IPNC, the status returned of "Utils_bitbufGetEmptyBuf" is 0, with pOutBuf not NULL for some moments, and then it will return -1 with pOutBuf = NULL. And after a while, the status return will be 0 and pOutBuf not NULL again. And this happens on and on. But on our platform, the status return is 0 (means success) for a while, and then the status return becomes -1. And afterwards, it is always -1. It means that the empty/full que mechanism do not wake up again.

I have further compare the captured image both on Appro's IPNC and on our platform, all are 1080p25, so the bit buffer size is the same on both platform. So I think it is not the bit buffer size issue.

Regards,

ChingHok

Hi Rajat,

Further debug show that calling the function "Enclink_h264EncodeFrameBatch" will block forever after run for a while, and this blocking means that no frames being encoded and always pending there, and after all buffers being submit to the processQue, then there will be running out of buffer.

So now, my question becomes "why Enclink_h264EncodeFrameBatch do not return? Is it related to hardware?"

Regards,

ChingHok

Hi Rajat,

As I have mentioned, the DDR3 configuration of our board (use EMIF0 only) and APPRO's IPNC (use both EMIF0 and EMIF1) is different, but their total memory size is the same, both are 512 MBytes. So their memory sections will be:

Our Board:

0x80000000 - 0x9FFFFFFF (512MBytes, continuous)

APPRO's IPNC:

0x80000000 - 0x8FFFFFFF (256 MBytes)

0xB0000000 - 0xBFFFFFFF (256 MBytes)

Will this difference be the cause of the issue? When we booting Linux, we specify notifyk.vpssm3_sva=0xBFD00000, do we need to change this? Also when loading vpss and video m3 firmware, the boot message shows:

[m3video] 5256: MEM: Shared Region 2: Base = 0xb8000000, Length = 0x06900000 (105 MB)
[m3vpss ] 5256: MEM: Shared Region 2: Base = 0xb8000000, Length = 0x06900000 (105 MB)
[m3video] 5257: MEM: Shared Region 1: Base = 0x89000000, Length = 0x03c00000 (60 MB)
[m3vpss ] 5256: MEM: Shared Region 1: Base = 0x89000000, Length = 0x03c00000 (60 MB)

How can we change the base memory address of SR2?

Regards,

ChingHok

ChingHok,

I think what is happening is that in your application the bitstream buffers are getting filled (used) by the encoder but not getting consumed (freed) by the application, thus after some time you see that get-bit-buffs returning null and the encoder stuck.

Can you send out your usecase file for review?

Regards

Rajat

Hi Rajat,

As I have mentioned, further  debug showing that the m3video stuck at calling "Enclink_h264EncodeFrameBatch", when it start executing the following line, it doesn't quit.

error = ((IVIDENC2_Handle)handle)->fxns->process((IVIDENC2_Handle)handle,inputBufDesc,outputBufDesc,(IVIDENC2_InArgs *)inArgs,(IVIDENC2_OutArgs *)outArgs);"

And I have trace the code that, it should get the empty buffer ready before doing submit  the batch for encoding.

Anyway, my use case is modified from "multich_encode_decode.c", please see the attachment.

Hi Rajat,

Did you receive my usecase file? Is there any other hints?

Regards,

ChingHok

Hi Rajat,

I meet the same problem,you said the issue was the bitstrembuf getting filled by the encode, not getting consumed by the application. so I want to know how do I make the bitstreambuf got comsumed.

Thanks in advance.

BR

Zhong

Hi Zhong,

Finally I found this is a hardware problem. Make sure that the voltage CVDD_HDVICP is correct. In my case, the designed value is 1.1 volt, but as the trace is not thick enough, the voltage reach DM8127 drops to 1.083. After I add a thick copper wire from the power source to DSP, this problem fixed.

Regards,

ChingHok

Hi Zhong,

You should have decoupling caps which are placed close to VDD_HDVICP pins at DM8127, so just measure the voltage at these capacitors.

Regards,

ChingHok

Hi ChingHok,

I am appreceiate for you reply. Now I have solved my problem, I modified the encodelink code, that is adding a release buffer function after the encoder got  the outque buffer failed.So  whatever it will bring some unexpected stuffs but it works.Thanks.

BR

Zhong