[FFmpeg-trac] #958(undetermined:closed): matroska seek problem file (3 bugs)

FFmpeg trac at avcodec.org
Tue Feb 14 01:33:33 CET 2012


#958: matroska seek problem file (3 bugs)
-------------------------------------+-------------------------------------
             Reporter:  DonMoir      |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  mkv h264     |               Resolution:  fixed
  seek                               |               Blocked By:
             Blocking:               |  Reproduced by developer:  1
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by DonMoir):

 There have been several times when I was told either it's a bad file, or
 ffmpeg doesn't work that way, or just don't use that format. Most of these
 issues were later fixed. Bad files tend to show you problems and good
 files mostly take care of themselves.

 When someone tells me something like "it's a bad file", it's like some
 support guy saying: "just reboot, take 2 aspirins, and call me in the
 morning".

 If it is a bad file and nothing can be done about it, then thats fine, but
 be sure nothing can be done about it.

 I tested the above file in VLC, ffplay, SMPlayer 0.7.0, WMP using ffdshow,
 and my own app.

 VLC 1.1.11 mostly gets seeking right but not without distorted frames
 which do clear up.

 SMplayer 0.7.0 gets it right.

 WMP using ffdshow gets it right but somewhat slow.

 My own app gets it right.

 ffplay only calls avformat_seek_file for the most part, and is not able to
 seek on the file.

 So the thing is to create the expected user experience as much as possible
 and who knows what might be wrong with their files. I assume that WMP,
 VLC, and SMPlayer take care of this in their own way.

 For my own app, I detect the problem and proceed. I would not have to do
 this if it could be handled in mastroska_read_seek but sometimes a higher
 level app just needs to have work arounds in place.

 So the level at which this is taken care of for me and others has to be
 moved up. I don't wish to cop out and do nothing.

 I am assuming that your recent patches for matroska have not changed this
 as I have not had a chance to test that out but maybe they have helped in
 some way related to this problem.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/958#comment:9>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list