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

Paul B Mahol onemda at gmail.com
Fri Nov 13 16:16:25 CET 2015


On 11/13/15, wm4 <nfxjfg at gmail.com> wrote:
> On Fri, 13 Nov 2015 15:57:22 +0100
> Nicolas George <george at nsup.org> wrote:
>
>> Le primidi 21 brumaire, an CCXXIV, Clement Boesch a ecrit :
>> > 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.
>
> libavfilter is too inflexible, brittle, monolithic. There's nothing
> asynchronous about it either. I also want to see how you'd do global
> format negotiation when you add subtitles, demuxers, muxers etc.

This monolithic is incorrect, it is easy to add support for loading
filters its just that
it never get commited, there is even patch for this.

>
> The basic idea you have is right (and the same thing more general media
> frameworks do, like dshow, gstreamer, etc.), but I suggest you design a
> new sub-library from scratch for this.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list