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: Wed, 09 Nov 2022 12:53:39 +0100
Message-ID: <166799481927.1198.11220834405656083251@lain.khirnov.net> (raw)
In-Reply-To: <Y2uD3D9IxPIRdqWL@phare.normalesup.org>

Quoting Nicolas George (2022-11-09 11:41:32)
> Anton Khirnov (12022-11-09):
> > If your concern with busy-waiting is pointless energy consumption, then
> > the correct thing to do is change all busy-waiting devices to sleep
> > internally if AVFMT_FLAG_NONBLOCK is not specified. I just checked, and
> > almost all of them actually do exactly this, the only exception is
> > avfoundation.
> 
> Yes, devices currently do the right thing as much as our framework
> permits.
> 
> Breaking that is one of the two ways merging EAGAIN and REDO can break
> our code.

I have no idea what you mean by this. What is being broken and how?

> > Furthermore this claim is not supported by development history. mpegts
> > will currently return EAGAIN on failed resyncs, specifically to give the
> > caller the opportunity to decide what to do next.
> 
> IIRC, this is precisely what REDO was introduced to fix. If the bug was
> introduced again or incompletely fixed, this it is an issue. Indeed, the
> two uses of EAGAIN in libavformat/mpegts.c seems highly dubious.
> 
> But as I explained, REDO and EAGAIN have a very different semantic with
> regard to when the caller needs to retry and cannot be merged.

Maybe more context will clarify the motivation here. What became this
patchset started as an attempt to make all uses of EAGAIN/REDO in
lavf/lavd consistent. While doing that I gradually came to the
conclusion that the distinction is arbitrary - e.g. multiple demuxers
deliberately return EAGAIN as context switch method. Now we could
declare this practice invalid, but as this has been done in multiple
demuxers independently, and has been in the tree for over 10 years, so
this should not be done lightly.

The question then is - what should be the effective rule for deciding
whether a demuxer returns EAGAIN or REDO in any given case?
Opinions on this are very much welcome.

-- 
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".