Mplayer fails to seek without losing reference frames in MKV file with a H.264 stream

[jeebjp@…]

As the summary tells, the current default MKV splitter seems to lose reference frames at times, ending up with tons of:

[h264 @ 0x8957ec0]number of reference frames exceeds max (probably corrupt input), discarding one

...and garbage on the screen with the current svn. With the lavf splitter, though, seeking forward in a file seems to work fine, but seeking backwards has the same problem, and seeking forward again from that position seems to break it too, until you let it play normally until the next IDR frame. With the lavf splitter and (possibly because of it being default during when rc2 was recommendable) on an rc2 version I found from several other university computers you get:

[h264 @ 0x8957ec0]Missing reference picture
[h264 @ 0x87707d0]reference picture missing during reorder

..output like this.

A file example of how to get this behaviour (111MB, mkv):
​http://www.sendspace.com/file/snxzjt

The file was also tested on Windows with DirectShow playback tools, Haali's splitter and it seems to play and be seeked well.

--Occurs on:

*practically all builds of mplayer, independent of the arch
*tested on older builds as well as the newest svn

[compn]

eventually we are moving to lavf demuxer.
report the backwards seek problem on ​http://roundup.ffmpeg.org

the same person maintains both, and plans to kill mp mkv.
so dont expect mp demux to be fixed (unless someone chimes in with a aptch).

[reimar]

I think this probably is fixed, a lot of seeking issues with -demuxer lavf were resolved and it is the default now.
Sample file is no longer available so not actually tested though.