How to correctly reset decoder?

How to correctly reset decoder?

Hello, I am trying to understand how to reposition the decoder at an arbitrary key frame within an h264 video.

The function MFXVideoDECODE_Reset takes an mfxVideoParam* as an argument, which I assume is the same mfxVideoParam* that was obtained from MFXVideoDECODE_Query after the first successful MFXVideoDECODE_DecodeHeader. Or at least, anything else I tried to pass returned MFX_ERR_INVALID_VIDEO_PARAM.

I'm wondering what should be done with the next data (starting from the new key frame) after the decoder is reset. Should I call DecodeHeader again, but this time skip initializing surfaces since they're already initialized and the video params didn't change? Do I need to call MFXVideoDECODE_Init again? (Apparently not, that failed too.) Apparently the decoder is happy with me continuing to call DecodeAsync as if nothing happened, however sometimes I'm getting artifacts so I assume I'm not resetting the decoder correctly. Or perhaps there's some information missing in the H264 stream?

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi,

Please refer to the "Media Developers Guide" (chapter 3.4) document part of the SDK package for recommendations on how to perform repositioning.

Regards,
Petter 

Thanks. It looks like what I'm doing is basically correct, and most of the time it decodes correctly. It's just that from time to time there are artifacts. We had the same issue with other decoders, and the only solution was to re-create the decoder from scratch at each new key frame. This is a hack and I'm trying to understand what's really going on.

I dumped the decoder input as a .h264 file. When I tried to open it with ffprobe, it complained "sps_id out of range". VLC would not open it either. However, I embedded the file into an mp4 container (i.e. ffmpeg -i file.h264 -vcodec copy file.mp4), and then that would play beautifully in VLC, except for stepping one frame at a time - that was broken. I compared the files in a hex editor and the only differences were the mp4 header (just ASCII text), and the 00 00 00 01 start codes were replaced with the frame lengths. Everything else was binary identical. No re-encoding, no injection or removal of any data, just start codes replaced with length prefixes.

It really bugs me that VLC is able to play the exact same input stream with no significant alteration and I'm getting artifacts with every decoder - including VLC's own ffmpeg! - when I just feed the frames one after the other. I would be quite surprised if VLC was re-creating its decoder from scratch every keyframe to achieve this.

EDIT: looks like there's corruption in my stream after all. Even VLC displays garbage. Will have to investigate. 

My ignorance of H264 isn't helping. I guess my question is, given an h264 stream, is this usage supposed to play correctly?

 - Seek at arbitrary key frame

 - Feed frames until end of GOP

 - Reset decoder

 - Seek at arbitrary key frame

 - Feed frames until end of GOP

 - etc.

It looks like when we give the GOPs in order, they play fine, but when they are fed in disorder, even with calling reset on the decoder in-between, there are random artifacts. 

Hi,

The sequence of events you describe does not seem to match the recommended approach in the Media SDK Developer Guide document. Please explore following the recommendation instead.

Regards,
Petter 

Login to leave a comment.