[FFmpeg-devel] [PATCH] ffprobe: do not exit in case the demuxer returns AVERROR(EAGAIN)

[wm4]

On Fri, 20 Nov 2015 16:44:56 +0100
Nicolas George <george at nsup.org> wrote:

> Le decadi 30 brumaire, an CCXXIV, Stefano Sabatini a écrit :
> > Please elaborate, what does it means that "it is not possible"?  
> 
> It is no longer busy-waiting, but it is still polling: ffprobe will wake up
> a hundred times per second waiting for network packets that may not come for
> several minutes or hours, preventing the processor from going into deep
> sleep, reducing the battery life, consuming energy and speeding up the
> climate change.
> 
> And the other way around, in one hundredth of second the kernel buffer for
> the stream may fill up, causing the peer to discard data or other bad
> behaviours.
> 
> So, no, it is definitely not good.
> 
> But FFmpeg does not have a better API for that yet, so the best we can do
> for now is to use polling, make a wet-finger estimate of a good sleep time,
> and hope for the best. I would have gone for 10 milliseconds too.
> 
> (The bit about climate change was exaggeration, but the rest is really
> relevant: a friend of mine used to work on lightweight embedded systems, and
> useless polling wakeups did reduce the battery life by a huge amount. And we
> had to add a thread on the UDP protocol reader to avoid packets from being
> discarded, amongst other things while the process was sleeping.)
> 
> > Or in other words, are you fine with the patch? If not, what fix do
> > you suggest instead?  
> 
> I can not comment on the loop and the setting of the return value, because I
> do not know the code of ffprobe well enough and this part seems a bit
> convoluted (probably out of necessity), so I can not comment the patch as a
> whole. The part that I know seems ok, as well as can be with the current
> API.
> 
> Regards,
> 

Not sure why you argue for a better API. The semantics are to block
until there's a new packet, or EOF. That's it. There is no room for
EAGAIN with "waiting". (EAGAIN that doesn't imply that the caller
should "wait", but can happen immediately, is ok, but makes not much
sense.)