Linux/TMS320DM368: H264 Encoder resetHDVICPEveryFrame

Hi Randy,

Can you give details of the below?

1. Are you using IPNC-RDK. If yes what is the version? If not which software are you using?

2. Version numbers of JPEG and H264 Encoders.

3. Resolution of  h264 encoder and JPEG encoder.

4. Do you see hang in very first frame?

Hi Prashanth,

I am not using the IPNC-RDK.  I am using the latest dvsdk for the DM368 (version 4.03).  However, I have updated to the latest JPEG and H264 codecs provided by TI because they released new versions after the DVSDK.  I am using JPEG encoder version 1.00.00.12 and H264 encoder version 2.30.00.06.

I am primarily using a resolution of 1920x1080 on the H264 encoder and 320x180 for the JPEG encoder.

I am not seeing a hang on the first frame.  I have seen them hang after a day but have also observed them running continuously for 30 days until a hang.

 Thanks,

Randy Scheifele

Hi Randy,
Thanks for the details. Please share your H264 and JPEG encoders parameters. I will have a look into it.

Hi Randy,

Can you please try making enableDDRbuff = 1; other parameters looks fine.

Ideally resetHDVICPEveryFrame =1 should work. Once this works. resetHDVICPEveryFrame =2 will also work, if you set it to 2, it is optimised version.

Prashanth,

Thanks for looking into this.  I can try and change enableDDRbuff to equal 1, but from the documentation it doesn't seem like it would help.  According to one of the TI wiki pages, enableDDRbuff "allows VICP based codec/algorithm to run in parallel to H.264 codec, subject to other resource like EDMA availability."  We can't run the JPEG and H.264 encoder in parallel because they are in the same codec group ID so they are run sequentially.  Will the enableDDRBuff attribute be useful in this case?

-Randy

Randy,

Yes you are right. enableDDRbuff will help when running in parallel. You can give a try.

I have attached the debug library of H264 Encoder. It will give more information on where it has hung. Please share me the logs when it hangs. Full log will help.5282.h264venc_ti_arm926_debug.a.txt

8424.ih264venc.h

Rename the library to .a and use it in place of the current library you are using. Mean while, did you observe any hand when you set resetHDVICPEveryFrame = 2;

Prashanth,

Thanks for the reply.

Since I've changed the resetHDVICPEveryFrame parameter to 2, I have not seen this issue.  However, with the value of 1, my system could run for a month or longer before it had a problem (I'm currently at around 16 days with resetHDVICPEveryFrame=2).  I'm hesitant to change the value of the enableDDRbuff field because it doesn't seem to apply to our use case.  I agree, I could change it, but I'd like to have a rationale for making the change, especially because it takes so long to verify the new parameter value.

Do you have access to any other documentation around the resetHDVICPEveryFrame parameter?  I'd really like to know what function it is performing under the hood.  The h264 encoder library is shipped as object code, so I can't look at the source myself to find out.

-Randy

Randy,

Nice to know you did not observe the issue after setting it to 2.  There is no such document for resetHDVICPEveryFrame. The brief info is in the h264encoder Userguide. You might have it. I have attached it here again.  When it takes long time to reproduce the issue you need not try out with enableDDRbuff.

resetHDVICPEveryFrame = 1; will reload code & data assuming memories of HDVICP is overwritten by other codec

resetHDVICPEveryFrame = 2; will assume no memory of HDVICP is overwritten but mapping of EDMA channels on TC i changed by different codec. Userguide recommends to set this flag to 2 when H264+JPEG running together.

h264_encoder_dm365_userguide.pdf 

Hi Prashanth,

You are correct, I already have the h264encoder User Guide.  That is the exact document that I read that prompted me to make the change from 1 to 2 for the resetHDVICPEveryFrame parameter.

One thing I just noticed when reviewing the h264encoder User Guide, the latest version says it is 2.40.xx but the latest codec page from TI only has version 2.30.xx.  Is there a newer version of the encoder?

-Randy

Codec download: software-dl.ti.com/.../index_FDS.html

Hi Randy,

Randy Scheifele said:

One thing I just noticed when reviewing the h264encoder User Guide, the latest version says it is 2.40.xx but the latest codec page from TI only has version 2.30.xx.  Is there a newer version of the encoder?

Yes, there is release of the codec 02.40.xx, this was done for some specific implementation. It should not effect you. What I recommend is to use 02.30.00.06(the latest GAed release), which is present in the web link shared by you.