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
signature.asc
Description: PGP signature
_______________________________________________ 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".
