[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