Hi, With the increasing number of hardware accelerated API, the need for a proper M:N asynchronous API is growing. We've observed that with MMAL and VideoToolBox accelerations typically. Similarly, the incoming MediaCodec hwaccel is going to suffer from the same limitations.
Some Libav developers started discussing API evolution in that regard, see https://blogs.gentoo.org/lu_zero/2015/03/23/decoupling-an-api/ A few FFmpeg developers are already interested in cooperating with Libav on that topic. #ffmpeg-devel <@ubitux> just curious, anyone aside from wm4 & myself willing to work with libav for the m:n async api model? BBB maybe (not here :()? <@nevcairiel> i am <@ubitux> any suggestion on how to approach this? <@ubitux> i mean, from the cooperation aspect, not technical one <+wm4> (rcombs also seemed to be interested) <+wm4> ubitux: well, we need to decide on a mailing list? <+wm4> where the discussion happens, and maybe patches <@ubitux> do you think it's possible/overkill to have a temporary 3rd mailing list to avoid butthurts? <@nevcairiel> just use theirs and dont think too much about it <@ubitux> okay <@ubitux> could be nice to send to both though <@ubitux> with the fear that it might degenerate fast <@nevcairiel> that always ends up silly for people that are not subbed to both, since people often forget to hit reply all <+wm4> cross-ML posts are icky <+wm4> they get broken really quick <@saste> ubitux, or you set up a new common mailing-list, but that might now work <@saste> so the safe bet is to use libav-devel <@ubitux> yeah, i can deal with it, but it might be nice to keep ffdev up-to-date; maybe some summaries should be sent on a regular schedule <+wm4> just send a mail to ffmpeg-devel that the new API is discussed on this and that thread <@ubitux> yeah, that was what i had in mind #libav-devel <ubitux> lu_zero: aside from your blog post, what's the state of the m:n async api model? <+nevcairiel> on that note, I'm not convinced using the decoder as the primary loop is the best design, if you consider network sources or some de-coupled models, you might want the demuxer to still push data primarily <ubitux> we have some additional potential hwaccel that would benefit from it <ubitux> typically videotoolbox and incoming mediacodec <ubitux> so a bunch of ppl from ffmpeg are interested in following & helping the design of this api <@lu_zero> nevcairiel: In fact the loop driver must be different depending on the specific purpose <@lu_zero> I was more focused on being able to have the encoder drive the loop but yes, the network would be also a good candidate for other usages <@lu_zero> ubitux: Nice to know, I had been busy with my dayjob for a while but I'll try to get a prototype out soon, I would appreciate having videotoolbox in my tree btw. -- Clément B.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
