On 24/09/15 11:33, wm4 wrote: > On Wed, 23 Sep 2015 23:16:24 +0200 > Luca Barbato <[email protected]> wrote: > >> On 23/09/15 20:27, wm4 wrote: >>> I guess trying to implement this wrapper inside of libavcodec was a >>> mistake... >> >> I can try to bake avframe_yield and related machinery as soon as possible... > > So do you have any concrete plans into this direction?
It the result of the first experiments about the [decoupled API][1]. > What would avframe_yield do? My initial idea was to make so the internal decoder would would always queue up the data when it is ready and return once the data provided is consumed. avcodec_decode_have_data() then checks the queue and avcodec_decode_pull() would provide the next frame. But then when doing stuff in asyncronous mode (or actually having to bridge actual hwaccels), I started to think that instead of creating the list of frames and then consuming it, at least in certain cases, you can do something about them directly. avframe_yield basically let the user provide a custom callback if needed and nicely hides the locking that might or might not needed. The default would be the normal enqueue, obviously, but then nothing would prevent you to do something such as blitting the opaque produced directly or feed it immediately to something else. The devil^Wdetail to be sorted out properly is where the reordering happens and if it is needed. That requires a couple of additional caps to signal it at least. Probably I should write more about it and try to get some minimal code complete to see which are the other issues with this approach. [1]: https://blogs.gentoo.org/lu_zero/2015/03/23/decoupling-an-api/ _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
