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, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
