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. > First, this would be an incredibly strong claim - given how many > possible usage patterns there are Mostly true nonetheless. > 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). It is not a correct way, only slightly less broken. > 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. Now, if you want me to take from my time to explain it again with more details and more clarity for your benefit… I suggest you tone done the condescension towards me. -- Nicolas George _______________________________________________ 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".
