[FFmpeg-devel] [RFC] Event loop

[Paul B Mahol]

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".