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

[wm4]

On Thu, 26 Nov 2015 21:21:08 +0100
Nicolas George <george at nsup.org> wrote:

> Le sextidi 6 frimaire, an CCXXIV, wm4 a écrit :
> > I fail to see how letting such a workaround (required for flv) leak to  
> 
> ... and a few other demuxers...
> 
> > common code is more elegant.  
> 
> You fail to see, but I do, and I am not alone:
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180681.html
> 
> > eventually end up with dozens of special cases in utils.c.  
> 
> "Slippery slope" fallacy.
> 

Not really.

> > Such an application will have to run the demuxer in a thread.  
> 
> Can we use threads to get peace in the Middle East too? Threads seem to be
> your solution to almost everything, but you fail to realize they bring a
> whole lot of problems of their own, ranging from portability to trickiness
> and memory consumption.

Well, unlike with peace in middle-east, everyone already figured out
that threads are a good solution to I/O.

Especially for an API that is blocking anyway.

> If you want to use threads everywhere, fine, by all means do so. Bu please
> have the decency not to bikeshed proposals that make it easier NOT to use
> them when they do not make your life easier.

Sorry, but this doesn't have to do with anything, especially not with
my life. What's it with personal attacks on my life anyway? (I also
haven't heard yet whose life is supposed to get easier by letting the
user handle EREDO.)

As I've already said, using threads for I/O is commonly accepted, and
also the libavformat API is already this way. Why do you treat my
suggestion to use a thread with so much scorn?

What you suggest is adding a special-case for a single demuxer (and
maybe 1 or 2 others? you didn't make it clear). And this special-case
looks pretty unwarranted. All other demuxers follow the rule to read
data until a packet is found, and then return that packet. And if I/O
is slow or if a lot of data has to be read to find a packet, every
single demuxer blocks.

I really don't understand your thinking here anyway. Didn't you say
yourself that polling is bad?

I'd also like to hear from you how an application is supposed not to
block its GUI without running the demuxer in a separate thread? (Please
answer with a solution that does _not_ require rewriting every single
demuxer and AVIO protocol.)

And what exactly warrants handling flv differently, but not, say,
Matroska or AVI?

Also, I'm not blocking your patch. I'm just suggesting that flvdec.c
should handle this internally.

> > 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?  
> 
> Unrelated.
> 
> > 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.  
> 
> This block is fairly unclear, but the way I understand it, it is another
> "slippery slope" fallacy.

This is not about "slippery slopes", it's about consistency. I.e.
avoiding unnecessary special-cases, which is always good for an API.