H264 decoder issue for seeking I-frames

Diego Solano

Hi,

We are trying to enable seeking functionality on an application that uses the h264_decoder omx component. We are using ezsdk-5_05_02_00 on dm814x platform.

We have two h264 encoded videos, when applying seeking to the first video (moving from frame 500 to frame 3000 of the h264 video, for instance), the decoder is able to resume and process the video just fine. On the second video, after jumping a few frames further in the video, the image looks distorted (like it has lost its reference picture buffer or IDR frame) and is never able to recover.

The difference between those videos is that 2nd video has I-frames instead of IDR-frames, just the first frame of the video is IDR:

We are testing this behavior by modifying the decode_display omx demo (dropping some buffers in the middle of the video stream to simulate the seeking functionality).

This is 4011.decode_display_bin.zip the decode_display binary and this is 2867.decode_display_code.zip decode_display source code with the modifications if you want to try to reproduce the behavior. Also, this link https://www.dropbox.com/s/ivqgpgswz7196mq/Video_1.zip?dl=0 is Video_1 with IDR-frames and this link www.dropbox.com/.../Video_2.zip is Video_2 with the I-frames.

According to my knowledge on h264 format; both IDR and I-frames are full frames, so the decoder should be able to recover on both cases, is the decoder able to refresh the reference picture buffer for both types of frames?

So in relation to the omx h264 decoder, if the video does not have any more IDR-frames besides the one at the beginning, is there any way to manually tell the decoder to refresh itself after decoding a few frames?.

Thanks!

over 10 years ago

0 Margarita Gashova over 10 years ago

TI__Guru* 80190 points

Hello,

Are you have the overlay package?

BR
Margarita

0 Margarita Gashova over 10 years ago

TI__Guru* 80190 points

Hello,

I was able to reproduce the issue with the default EZSDK:

./decode_display_a8host_debug.xv5T -w 1920 -h 1080 -f 30 -g 0 -d 0 -c h264 -i A07_RAW.h264

I am not observing it any more but the fix is in the overlay package vdec component.

BR
Margarita

0 Diego Solano over 10 years ago in reply to Margarita Gashova

Prodigy 60 points

Hi Margarita,

Thanks for the quick reply,

Yes, we have the Overlay package installed, however, after build again the EZSDK with the overlay package, I`m still getting the same behavior of the default EZSDK, the picture still looks bad after dropping the frames.

We have your email here at RidgeRun, I could send you our built firmware (HDVICP.xem3) and our EZSDK compiled library (libtiomx.so.5.2) so we can see if one of those files are not set correctly or if we are missing something in our Overlay package.

Thanks for the help.

Best regards,

DiegoSolano

0 Margarita Gashova over 10 years ago in reply to Diego Solano

TI__Guru* 80190 points

Hello,

There is a patch for this issue in the vdec component. You could try to check the errors which the decoder report and to fix it. You could see that bits 0,7,9,10,11,12,25,31 are set.

BR
Margarita

0 Ramprasad over 10 years ago in reply to Margarita Gashova

TI__Mastermind 30480 points

Hi diego,

Actual issue of distortion is arising from application feeding top field again after decoding a top field.

After decoding a top field, if your applciation starts dropping frames and then feeds a TOP filed again this issue will come and decoder will never recover from distortion because, top field will be decoded bottom field and bottom field will be decoded as top.

The patch Margarita is talking about, identifies the field reversal and takes care of this problem.

ideally this issue should come for any interlaced stream.

Ram

0 David Soto - RidgeRun over 10 years ago in reply to Ramprasad

Genius 3700 points

Hi Margarita and Ram,

Thanks for your help, we really appreciate your comments about this problem. Could you send me the patch that takes care of this (david.soto@ridgerun.com)? Diego and I are using the EZSDK overlay for version 5.05.02.00, should that one work? I would like to check that our source code has the change,

Thanks again,

-David

0 David Soto - RidgeRun over 10 years ago in reply to David Soto - RidgeRun

Genius 3700 points

Maybe I can "grep" for something in my code and see if I have the change,

One other question. Do you handle several versions of the overlay or for EZSDK 5.05.02.00 there is just one version of overlay package?

-David

0 Margarita Gashova over 10 years ago in reply to David Soto - RidgeRun

TI__Guru* 80190 points

Hello David,

Open a email thread.

NOTE: Overlay package can not be discussed in the public forum since is under NDA!

Margarita

0 Ramprasad over 10 years ago in reply to Margarita Gashova

TI__Mastermind 30480 points

Hi David,

Without this patch you will be able to fix the issue, if you apply FLUSH command before starting the dropping frames and after before starting normal decoding again.

Please try this option also from you iLclient.

Ram

0 David Soto - RidgeRun over 10 years ago in reply to Ramprasad

Genius 3700 points

Hi,

With TI's help we were able to narrow down the problem to the H264 decoder version that we were using. We needed a newer version to support seeking

-David

Processors

Processors forum

H264 decoder issue for seeking I-frames