Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)

From: Anton Khirnov <anton@khirnov.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Date: Tue, 08 Nov 2022 15:07:31 +0100
Message-ID: <166791645128.20155.3271115273476016820@lain.khirnov.net> (raw)
In-Reply-To: <Y2pRnfUTJ5b4/F24@phare.normalesup.org>

Quoting Nicolas George (2022-11-08 13:54:53)
> Anton Khirnov (12022-11-08):
> > There is no meaningful distinction between them, both mean "the demuxer
> > did some work, but did not produce a packet - should be called again".
> 
> NAK, there a difference in semantics: AVEROR(EAGAIN) is for when data is
> not available for external reasons, typically network blocking,

This is false - there are zero demuxers returning EAGAIN due to network
blocking. Furthermore, lavf architecture fundamentally does not allow
generic non-blocking operations, so the most any demuxer can do is
return at a few specific points. And since demuxers are supposed to be
independent of the underlying IO protocol, they fundamentally cannot
know anything about network state.

So there really is no meaningful difference between REDO and EAGAIN.
Both are just an opportunity for the caller to do something else before
trying again. If we believe giving the caller this option is valuable,
then it's valuable in both these cases and it makes no sense to
distinguish between them.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".