On Tue, 5 Sep 2017 10:03:49 +0200 Jorge Ramirez <jorge.ramirez-or...@linaro.org> wrote:
> On 09/05/2017 09:16 AM, Jorge Ramirez wrote: > > On 09/05/2017 12:16 AM, Mark Thompson wrote: > >> On 04/09/17 22:55, Jorge Ramirez wrote: > >>> On 09/04/2017 11:29 PM, Mark Thompson wrote: > >>>>> ... stuff ... > >>>> So the sequence of calls is: > >>>> > >>>> send_frame(frame 0) -> success > >>>> receive_packet() -> EAGAIN > >>>> send_frame(frame 1) -> success > >>>> receive_packet() -> EAGAIN > >>>> ... > >>>> send_frame(frame 15) -> success > >>>> receive_packet() -> EAGAIN > >>>> send_frame(frame 16) -> success > >>>> receive_packet() -> packet 0 > >>>> receive_packet() -> packet 1 > >>>> ... > >>>> receive_packet() -> packet 15 > >>>> receive_packet() -> packet 16 > >>>> receive_packet() -> blocks > >>>> > >>>> This appears correct to me - since EAGAIN has not been returned by > >>>> a receive_packet() call, it can be called again repeatedly (as > >>>> documented in avcodec.h). Do you disagree? > >>> I would have expected that after a packet is received, a new frame > >>> is enqueued instead of executing again receive_packet (why do we > >>> that? what is the benefit?) > >>> under these circumsntances I can't block in receive_packet blindly, > >>> I have to track in user-space what the driver has in its guts and > >>> predict how much it needs to keep working....I dont think it is a > >>> good idea. > >> Feel free to submit a patch to avcodec.h which changes the definition > >> of the API. > > > > no, that is ok. I can work around it easily (maybe v4l2 has special > > needs compared to the rest of ffmpeg) > > > >> > >>>> I think that the problem is that you are only polling on the frame > >>>> buffer queue when blocking, so you don't see the packet buffers > >>>> becoming free in the packet buffer queue - if you did see and > >>>> dequeue them, you would then return EAGAIN to indicate that more > >>>> input is needed. (See comments in > >>>> <e4c6a8d7-798a-dfdb-b748-42936e944...@jkqxz.net>.) > >>> I could manually track it that way with additional counters - so > >>> before blocking I could see count many frames are enqueued in the > >>> input and if there is not at least one I could just return EAGAIN. > >>> but the behaviour differs from encoding. > >> The behaviour is identical. You return the output buffer if there is > >> one available on the output queue, otherwise you return EAGAIN if > >> there is any space on the input queue, otherwise you block waiting > >> for either of those to become possible. > > > > > I made some modifications to the way I was dequeuing buffers so now it > polls for both input and output queues. you were right, things work much > smoother this way...thanks. > > having said that I still I find the encoding API wrongly defined (no > need for two calls that are in fact highly couple to each other in my > opinion) The encoding API works exactly the same way as the decoding API, just that the decoding API has an helper internally that makes it easier to merge send/receive into 1 function. You could do the same on the encoding side. Other than that, the API is meant for single-threaded use, so we can't do things like randomly blocking calls and requiring reentrant calls from other threads to unblock them. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
