[FFmpeg-devel] matroska file hits eof on any seek

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Feb 17 18:07:24 CET 2012

On Fri, Feb 17, 2012 at 04:45:30AM -0500, Don Moir wrote:
> This file is probably a "bad" file.
> VLC can seek into it effectively but it will end up breaking down with distorted frames.
> ffdshow can seek into it but it is very slow.
> Use avformat_seek_file at any position including zero and the next packet read will fail.
> avformat_seek_file returns zero as an indication of success.
> The only recovery is to shut the file down and reopen it.
> Any seek with ffplay, smplayer, my own app,  just stops playback (because it will hit EOF) and you can't get out of it without closing the file.
> I have not opened a ticket on it but will if requested. I figure you have enough tickets already but let me know.
> If nothing else can be done about it, then at least a failure by avformat_seek_file would be good as long as it was able to continue to playback.
> If anyone wants to take a look, here's the file:
> http://sms.pangolin.com/temp/bad_seek_matroska_eof.mkv  (103 mb)

The problem is that this uses intra refresh but no intra frames.
I do not know what the specification says, but the problem is
that the file (IMO incorrectly) marks all frames as non-keyframes
when it should mark all as keyframes.
So the seek works just fine, but after the seek the read function
skips all non-keyframes, which goes all the way to the end of the file.
Enabling the parser for H.264 as well gives the packets the right
keyframe flags afterwards, but does not help the demuxer.
Not sure what to do here.
One way would be to add a flag that makes libavformat
discard non-keyframes after having run the parser over
Another would be to just manually figure out if those
are intra-refresh H.264 frames.
Or lastly just declare it as too broken to support
better than this.

More information about the ffmpeg-devel mailing list