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? Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
