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

[Jorge Ramirez]

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)