[Libav-user] Bug in mpegts reader with H.264 video?

[Thomas Worth]

I've encountered what seems to be a problem with the mpegts reader. If
I read and decode an MTS-wrapped video compressed with H.264, I can
get DTS and PTS values just fine. For example:

/* within an endless loop */
if(packet.stream_index == video_st_id){
			
	avcodec_decode_video2(vcodecCtx, test_frame, &got, &packet);
			
	if(got){
			
		if(packet.dts != AV_NOPTS_VALUE){
			fprintf(stderr,"dts is %lld\n",packet.dts);
		}
	}
}
/* end loop */

/* now back up and repeat */
av_seek_frame(formatCtx, video_st_id, 0, AVSEEK_FLAG_BACKWARD);
avcodec_flush_buffers(vcodecCtx);

This all works as expected. If I use av_seek_frame() to seek to the
beginning of the stream and repeat the read/decode process, fetching
DTS/PTS values all day, it works just as well. I can repeat this
process a million times and it's 100% predictable. Fine. Great.

The problem is when I open a video that contains a known corrupted
picture. When the corrupted frames are reached, I get this:

[h264 @ 0x7faf1b86b400] mmco: unref short failure
[h264 @ 0x7faf1b86b400] reference picture missing during reorder
[h264 @ 0x7faf1b86b400] Missing reference picture
[h264 @ 0x7faf1b86b400] reference picture missing during reorder
[h264 @ 0x7faf1b86b400] Missing reference picture
[h264 @ 0x7faf1b86b400] mmco: unref short failure
[h264 @ 0x7faf1b86b400] mmco: unref short failure

Ok, fine. BUT, once these errors occur, if I try to seek to the
beginning again the DTS and PTS values are ALWAYS
-9223372036854775808. It doesn't matter how many times I flush
buffers, or close and reopen the codec, I am stuck with never being
able to read the correct DTS and PTS ever again for that file (unless
I quit and restart the app)! It's like something internal to avcodec
is botched and can't be recovered. If these decode errors are
encountered in the middle of a loop, the DTS/PTS are still shown
correctly until the end of the loop but once I issue the
av_seek_frame() and flush buffers to rewind the stream, the timestamps
are always -9223372036854775808 from that point on.

Has anyone encountered this? Is there something else I need to do to
restore proper DTS/PTS after a decode error?