[FFmpeg-devel] [RFC] Event loop

[Nicolas George]

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.


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210201/dc43aea3/attachment.sig>