On Fri, 25 Sep 2015 09:18:38 +0200 Luca Barbato <[email protected]> wrote:
> 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/ Honestly, I think always keeping the queue would be better. Callbacks should be used for notification only (IMHO). This way we could define that the callbacks must only wake up another thread, and cause this other thread to use the normal API. So in terms of your blog post, the callbacks would have only the priv parameter. Anyway, here's what I think needs to be done: - add API stubs for the m:n API (push packets, pull frames) - make the API stubs use the old API - implement a thread-safe queue for packets/frames - add internal entrypoints for the new API (should this use the thread-safe queues for simplicity, or mirror the public API directly?) - add internal async entrypoints (these would definitely just read/write from the thread-safe queues) - think of a way to emulate the new API from the old one, or define that some decoders can be used only with the new API - change generic frame threading to the new async entrypoints (maybe) There are some finer points. For example, avcodec_decode_have_data() could change its return value over time with an asynchronous API, while a synchronous API implies that the call waits until the result is known. This needs to be sorted out. I'd tend to say that avcodec_decode_pull() should block, while avcodec_decode_have_data() would purely poll. The blocking variant should not lead to deadlocks, so if there's no new frame without new input, it should return. (So it can't just wait on one of those thread-safe queues.) Just putting this up for discussion. I can try to help writing some real code too, once we know how it should work. Also, this should probably be a separate thread. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
