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

Jorge Ramirez jorge.ramirez-ortiz at linaro.org
Tue Sep 5 15:37:03 EEST 2017


On 09/05/2017 10:27 AM, wm4 wrote:
> 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.

I see. But doesnt the helper makes the API confusing?
I quite liked the way Mark described the operation:

" 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 now think that having a single function "muds" the behavioral 
definition above since we can just queue many packets on input and then 
be sure that on each dequeue we will be given the chance to enqueue 
again _even_ if there is another processed buffer ready to be read.


>
> 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.

ok, understood.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



More information about the ffmpeg-devel mailing list