This is mainly for Libav 13, read [here][1] for the first drafting of
it. I'll get a second post about it to explain better the whole deal
about `yield`.
On 25/09/15 10:42, wm4 wrote:
> 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)
I can do that probably during the weekend.
> - make the API stubs use the old API
I didn't want to do that, but it won't take long to do.
> - implement a thread-safe queue for packets/frames
I'm thinking about making it really stupid first and then rice/tweak it.
(volunteers welcome if you have anything better than a fifo + a muxer or
the PacketQueue I use in bmdtools)
> - 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)
I'd use the thread-safe queues always.
> - 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
Providing a capability would work to signal it.
> - change generic frame threading to the new async entrypoints (maybe)
Yes (and here there is one of the most annoying details about the queue
and reordering).
> 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.
Yes and gets even funnier since in theory you'd want to decide what's
the driver depending on the situation, sometimes it would be the decoder
loop, sometimes the encoder loop, sometimes the muxer loop, hardly the
demuxer loop.
> 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.)
We can start from there, generalizing later is always possible.
> 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.
Spun and thank you for the help it is really appreciated =)
[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
