[FFmpeg-devel] [PATCHv8] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[wm4]

On Tue, 5 Sep 2017 10:03:49 +0200
Jorge Ramirez <jorge.ramirez-ortiz at 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-42936e944829 at 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.