[FFmpeg-devel] [RFC] Event loop
Paul B Mahol
onemda at gmail.com
Mon Feb 1 22:14:35 EET 2021
On Mon, Feb 1, 2021 at 8:14 PM Nicolas George <george at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-devel
mailing list