[FFmpeg-trac] #2530(undetermined:new): Seeking in transport stream spams decoder error messages

FFmpeg trac at avcodec.org
Sat May 4 15:42:48 CEST 2013


#2530: Seeking in transport stream spams decoder error messages
-------------------------------------+-------------------------------------
             Reporter:  gjdfgh       |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  unspecified  |  undetermined
             Keywords:  mpegts h264  |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by gjdfgh):

 Replying to [comment:3 cehoyos]:
 > libavformat seeks to the intended position and libavcodec drops the
 frames until the next recovery point.

 And it spams errors like mad.

 > > It feels like it should be silent as long as no bug is hit and the TS
 is not broken.
 >
 > If you don't like the warnings, turn them off. (honestly!)

 They are errors (AV_LOG_ERROR), not warnings. Are you seriously asking
 users to filter out error messages to paint over a symptom of a possible
 problem in ffmpeg? And all that with the risk that users would filter out
 errors due to unrelated important issues too? Am I here really on the
 ffmpeg bug tracker... I mean, the purpose of a bug tracker is to report
 and analyze bugs in ffmpeg, isn't it? Filtering warnings by text can't
 really be the correct way of using ffmpeg as library either.

 Besides, the fact that mplayer's internal ts demuxer is much faster at
 seeking is what is actually important to me. As I already said, it doesn't
 cause the decoder to vomit all over the place as well. This makes me think
 that there's definitely something wrong with the libavformat demuxer. I
 don't know what would cause the perceived speed issue, and I don't know
 how to prove that it exists, so the error messages are all what I have. In
 any case, user experience is much better with the mplayer demuxer. And
 this stuff does matter, because it happens when doing playback via
 libbluray too.

 > {{{$ ffmpeg -ss x -i input}}}

 Exactly the same result.

 > > And how is ffplay not enough?
 >
 > It depends on an external library (that is known to be buggy) and it is
 generally much harder to reproduce issues with ffplay than ffmpeg.

 $ ldd `which ffmpeg`|wc -l
 100


 ....................

 > > But I tested with mplayer (svn from a few days ago). With -demuxer
 lavf it's even worse (shows gray garbage right after seek)
 >
 > Use {{{$ mplayer -demuxer lavf -lavdopts wait_keyframe}}} to get the
 same behaviour as FFmpeg. (Reimar prefers the MPlayer behaviour which you
 can get with FFmpeg using {{{-flags2 showall}}}.)

 Output corruption goes away, error messages and slowness stay.

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


More information about the FFmpeg-trac mailing list