On Mon, Feb 1, 2021 at 8:14 PM Nicolas George <geo...@nsup.org> wrote:
> Based on this discussion, I say that the need for an event loop is > confirmed. > > I will now start discussing actual plans for going forward. Since the > coding work will be significant and not incremental, I want the outcome > of this discussion to be binding: if we agree to do it a certain way, > then the code for doing it will be accepted, pending code quality or new > unforeseen issues. If anybody objects to this, please explain your > reasons. > > First, again: Why we need an event loop. > > We need an event loop because we already have several ones. We already > have five protocols and two devices implementing their own event loops. > Factoring this duplicated code and implementing it properly is just the > obvious way forward. > > Plus, it makes implementing new protocols simpler, especially when they > are somewhat complex. And it can make applications simpler. > > So, my plan. Note that a lot of it will need to be ready before anything > can be applied. > > > 1. Add an event loop to libavutil. > > 1.1. Add a simple event loop implementation. > > It needs to be powerful enough to replace all our current needs: > > - watching file descriptors; > - timeouts; > - low-latency I/O threads (for the UDP thread). > > And I will add: > > - threads for bulk tasks > > because it is needed for something later (see below). > > 1.2. Add an event loop API to libavutil. > > It will be mostly made with callbacks, so that applications can use > the event loop of their choice instead of the more limited one we > provide. But by default, it will use our implementation, of course. > > I propose AVScheduler for the root structure of this API, and > av_scheduler as function prefix. > > The API would consist of just a few entry points: > > - allocate, init, free an AVScheduler; > - allocate, add, alter, remove, free events; > - start, run, stop the loop. > > 1.3. Implement a libev wrapper. > > Implement the callbacks of the event loop API with libev as > back-end. > > Make it either an example or a build option. A build option would > have the benefit of more extensive testing. > > > 2. Add a callback-based API for protocols. > > 2.1. Implement the new API. > > To use this, an application will: > > - create an AVScheduler; > - attach its protocols to the AVScheduler; > - set the callbacks; > - if useful, set the buffers; > - run the AVScheduler. > > As soon as the AVScheduler. > > 2.2. Implement a compatibility layer for new protocols. > > Protocols using the new design need to be callable through the old > API. The compatibility layer will need to allocate an AVScheduler > just for this protocol, and start, run, stop it for each read or > write operation. > > 2.3. Port the low-level network protocols. > > To get any benefit from this, at least TCP and UDP need to be > ported. > > 2.4. Implement a compatibility layer for old protocols. > > We need to be able to still use the protocols that have not been > ported to the new design. It will involve reading or writing on them > with a short timeout. It is inefficient, but the same kind as > inefficient as we have now. > > 2.5. Port complex protocols. > > To check that it works as expected, porting at least one of the > protocols that use several sockets is necessary. > > > 3. Use the even loop for running libavfilter. > > The reason I want threads for bulk tasks is that we can then use > them for inter-filter threading. Having a well-designed event loop > in libavutil will give us a better API and parallelism for > libavfilter for very little effort. > Why event loop is needed for filters? libavcodec have frame threads and it does not need it. > > > 4. Use the new API in the fftools. > > This is necessary to prove the API works. > > > This is it, please share your comments. > > Regards, > > -- > 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". _______________________________________________ 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".
