On Fri, 25 Sep 2015 11:38:35 +0200 Luca Barbato <[email protected]> wrote:
> 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: > > 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. Well no, we need to know how the dataflow is supposed to work. This is not something that can be decided later. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
