On Thu, Dec 31, 2020 at 02:37:21PM +0100, Nicolas George wrote: > This mail is about a project I have to make FFmpeg's API and > infrastructure more convenient. For a common introduction, see this thread: > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html > > The API to access our protocols, in particular network protocols, is copied > from the Unix file descriptor API, basically read() and write(). While this > API is very simple and convenient when it works, it works mostly only with > simple applications that do with only one input or output at a time. Extra > features like timeouts or handling several streams simultaneously are > complex to add. > > Furthermore, timeouts and non-blocking mode are currently done with a > periodic polling, which makes the application always active and can prevent > embedded devices from going into deep sleep, draining the battery. > > I want to replace it with an event loop. That means that instead of reading > on a protocol context, we would register a callback for when data is > available, and then let the loop run. > > Of course, a compatibility layer will still allow to read directly.
Majority of our demuxers and muxers assume a blocking model. Will they need to be rewritten (eventually) to use event-based i/o? -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) _______________________________________________ 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".
