[FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

wm4 nfxjfg at googlemail.com
Thu Nov 26 21:08:54 CET 2015


On Thu, 26 Nov 2015 20:46:25 +0100
Nicolas George <george at nsup.org> wrote:

> Le sextidi 6 frimaire, an CCXXIV, wm4 a écrit :
> > Better do the looping internal in flvdec.c (if there's no huge number
> > of other demuxers which need this), instead of adding a new error code
> > that is also part of the public API.  
> 
> There are a few, but not many. This was my first intent, but looping in the
> framework is way more elegant and much cleaner design.

I fail to see how letting such a workaround (required for flv) leak to
common code is more elegant. It's better to keep such exceptions to the
rule inside the demuxers which violate the normal API. Or you will
eventually end up with dozens of special cases in utils.c.

> Nothing would prevent us from defining the error code in
> libavformat/internal.h if we make sure it does not leaks to the application,
> but as Michael mentioned earlier and I did in the comments for patch 2/3 in

> this series, having a public code allows to give the application
> fine-grained control over the looping, for example to maintain basic user
> interaction while a demuxer tries to find a sync word in a big corrupted
> file on a slow local medium.

Such an application will have to run the demuxer in a thread. Not
returning from the demuxer for a while because data is read is
perfectly ok because the API is inherently blocking. What are you going
to do if reading even a single packet takes milliseconds because the
data is e.g. shuffled over a slow HTTP link?

I don't foresee that more demuxers will make use of AVERROR_REDO when
no new packet data is immediately available, only to appease to
applications with broken or less than ideal IO code.

> Therefore, I maintain the proposed patch as is.

Disagree.


More information about the ffmpeg-devel mailing list