DM6467 periodical IDR frame generation possible bug

Nir,

No, this is not a known issue. The fact that 65536 is exactly equal to 2^16, could indicate that a 16-bit value could be overflowing. We can check this at our end. Could you please share the version of the H264 encoder you are using? Also if possible can you share the encoded stream?

Regards,

Kapil

I will be able to supply the version and the encoded stream in 2 days, since I am currently out of office. Anyway, since the issue was replicated by 2 different h.264 encode codecs (the first - the one which comes with the DM6467 EVM, the second - the new codec with 1080p30 support), I assume that if the reason for the issue is a codec bug, then it exists in all its versions.

Thank you,

Nir

Nir,

I just came across another thread (INTernal) on the same issue. The user is currently doing a reset to work-around this issue. However, as Kapil suggested, please share the stream so that we can check this at our end

Regards,

Anirban

The versions of the CODECs I use are:

h264fhdvenc version 01.10.01.00 November 2009
h264enc version 1.00.013 June 2008

Please find attached 2 streams:

good_stream - file with recording of encoder output when it is OK

bad_stream - file with recording of encoder output when it results in pixelization

regards,

Nir

Nir,

It looks like the idr_pic_id is crossing the value 65535 and hence the pixelization being observed. That needs to be taken care inside the encoder.

Best Regards,

bhushan.

Bhushan,

Is it something I can do with my environment, or I must wait for a new CODEC release?

Thank you,

Nir

Nir,

Do you have access to the source code?

Also, you can try doing a RESET before encoding the 65536th forced IDR frame to work-around the issue. (this might have some impact on the encoder's rate control behaviour)

Is this something you can try? Let us know how it goes and if you still see the issue.

We have filed a bug to address this issue in the next CODEC release

Regards,

Anirban

Anirban,

No, I do not have access to the source code.

What do you mean by RESET? Do you have a sample code? Will the result of the RESET affect the stream and I will see artifacts after decoding?

When is the next CODEC release scheduled?

Thank you,

Nir

Nir,

RESET means calling the Control API with XDM_RESET command - example -

H264FHDVENC_control(
                             handle,        /* Instance Handle      */
                             XDM_RESET, /* Command        */
                             &dynamicparams,/* Pointer to Dynamic structure-Input  */
                             &status        /*Pointer to status structure-Output   */
                          );

Do let us know if this helps you to work-around this issue.

Regards,

Anirban

Anirban,

OK, I will test this as follows:

1. Do a reset after several forced IDRs, to see if this affects the stream - this test can be done immidiately.

2. Do a reset after the 65535 forced IDR frame  - for this I have to wait ~6 hours for the result, since I force an IDR frame every 10 frames (only for accelerating the outcome).

I will post the results.

Thank you,

Nir

Nir,

A quick suggestion - for (2) do a reset after the 65530th forced IDR frame instead of 65535th forced IDR frame - there looks to be some bug in the codec when IDR_PIC_ID becomes 65535 - so you may apply a reset sometime before (65530) it reaches this condition. Anyway, in either case, the test is equivalent.

(1) seems fine

Let us know your observations.

Regards,

Anirban

Hello, 

this bug is present in the latest code version v1_20_02_00 also?

It there any plan for a new release ?

Regads

Claudio