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

[wm4]

On Fri, 27 Nov 2015 13:53:33 +0100
Nicolas George <george at nsup.org> wrote:

> Le septidi 7 frimaire, an CCXXIV, wm4 a écrit :
> > I might not be familiar with flvdec in particular. Can you explain me
> > how Matroska could be switched to non-blocking?  
> 
> It can not, and this has NOTHING to do with the current discussion.
> Non-blocking mode requires the demuxer to be able to stop at ANY position in
> the octet stream, it is very hard to achieve.
> 
> What was evoked here was a low-latency mode, where the demuxer returns as
> soon as CONVENIENTLY possible.

Oh, ok.

I still do not see how a potential flag to make the API user to be able
to use this is better than running the demuxer in a thread. I'm talking
about practice, not theory. Such a flag would work _sometimes_, with
_some_ demuxers in _some_ very specific situations, and which will only
be low latency if the AVIO behind it is also low-latency.

On the contrary, I see this (proposed, not even realized) feature,
which will be half-broken at the moment of its inception, become yet
another feature that nobody uses and that bitrots as time goes.

Note that I'm not stopping you. I only questioned that the fix to the
flvdec issue was not minimal.

> I am not familiar enough with the Matroska demuxer, which seems rather
> convoluted, to tell how it could be changed.
> 
> > I'm trying to prevent that people add more complex special cases
> > libavformat/utils.c. One special case is not a tragedy, but millions of
> > special-cases interacting are an unmaintainable mess.  
> 
> I am not trying to add millions of special-cases, just one. Since you
> pretend you are not making a "slippery slope" fallacy, explain what these
> millions are about.

utils.c is full of special conditions that barely anyone knows what
they are about. This is not just my opinion.