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 11:17:31 +0100
Message-ID: <166798905198.1198.15926476440641965970@lain.khirnov.net> (raw)
In-Reply-To: <Y2t0/l30CIgWxSf/@phare.normalesup.org>

Quoting Nicolas George (2022-11-09 10:38:06)
> Anton Khirnov (12022-11-09):
> > > Well, it has actionable consequences: if you treat EAGAIN like REDO you
> > > introduce a busy wait,
> > In most devices it's a sleep rather than a busy wait. And in those where
> > it isn't, it should be.
> 
> I do not know how your sentence connects to mine.

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.

> 
> > Furthermore, since the caller has no way of knowing how long to wait,
> > there is little they can do other than sleeping for a random period and
> > hoping for the best.
> 
> This is why I have wanted to fix the design of demuxers and demuxer-like
> components for years, but it is a tremendous work. In the meantime, we
> just do with "av_usleep(1000)" and it is terrible.
> 
> > I highly doubt that returning control back to the caller will cause any
> > slowdown in and of itself, it's more about what the caller will do in
> > response. If they choose to sleep for a random amount of time, then
> > maybe they should stop doing that (which is exactly what this patchset
> > does).
> 
> Sleeping is the only correct reaction to EAGAIN.

First, this would be an incredibly strong claim - given how many
possible usage patterns there are - even if we did have support for
user-side polling. But since we do not, then it's even more dubious,
because the user does not know how long to sleep for. The only truly
correct way to work with arbitrary demuxers currently is run it in
blocking mode in a separate thread (which is exactly what ffmpeg.c does
now).

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. RTSP does something
similar. This has nothing to do with waiting for the network, because
neither of these two demuxers know about the state of the network. And
there is no essential difference between what mpegts does with EAGAIN
and e.g. flvdec with REDO.

The point of this set is giving control to the caller. If the caller
wants blocking operations, they unset AVFMT_FLAG_NONBLOCK and don't have
to deal with EAGAINs. If they want the limited support for context
switching that lavf can provide, they set AVFMT_FLAG_NONBLOCK and decide
what to do.

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