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-requ...@ffmpeg.org with subject "unsubscribe".
