[FFmpeg-devel] [PATCH] avutil/WIP: add AVAsync API

Nicolas George george at nsup.org
Fri Nov 13 15:57:22 CET 2015

Le primidi 21 brumaire, an CCXXIV, Clement Boesch a écrit :
> You construct something like this:
>   AVAsyncContext(
>     AVAsyncReader(
>       AVAsyncDecoder(...),
>       AVAsyncDecoder(...),
>       AVAsyncDecoder(...),
>       ...
>     ),
>     AVAsyncReader(
>       AVAsyncDecoder(...),
>       AVAsyncDecoder(...),
>       ...
>     ),
>     ....
>   )

Is there a specific reason you use a different type for decoders and
readers? If I understand correctly, readers would be demuxers, and
basically, if you look from high enough, demuxers and decoders are basically
the same.

Actually, I think we already have the framework for a high-level
optionally-asynchronous API: libavfilter. Of course it is far from ready for
it, but the basic principles are sound.

The big step it would require is support for AVMEDIA_TYPE_DATA frames. There
was some talk on libav-devel of merging AVPacket into AVFrame, that would be
a big first step. With this, decoders are just DATA->VIDEO or DATA->AUDIO
filters, demuxers are sources with multiple DATA streams (or filters with
one DATA input, with protocols the sources), and of course the symmetric for
encoders and muxers.

Libavfilter already supports n:m schemes (if I understand correctly what you
mean by that: n input frames produce m output frames?), and allows automatic
conversion to supported formats. My current work on de-recursiving intends,
amongst other things, to make parallelism possible, and I have a later
project of adding a callback to the sinks to get the frames immediately
instead of polling.

Also, not related to libavfilter but relevant to the discussion: amongst the
projects that I am slowly maturing is the implementation of an I/O even loop
API that would allow to clean up all the inconsistent uses of poll() with
subprotocols, and also to get rid of pthread_cancel() for the UDP thread.

> - first, in threadmessage it seems I can't yet flush the fifo properly
>   (for example by calling av_frame_free() on each entry of the frame
>   queue): should I extend the API? Nicolas, maybe you have a suggestion?

Not really. IIUC, you need a function for the sender to tell "all queued
messages are useless, discard them"? Or maybe more generic out-of-band /
prioritized messages?


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151113/c5e1af04/attachment.sig>

More information about the ffmpeg-devel mailing list