[FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Mark Thompson]

On 04/08/17 14:06, Jorge Ramirez wrote:
> On 08/04/2017 01:51 PM, Mark Thompson wrote:
>>> +    if (ret)
>>> +        return 0;
>>> +
>>> +    return avpriv_v4l_dequeue(cap_pool, frame, NULL, timeout);
>>> +}
>> What happens to the decoder if some parameters like resolution change mid-stream?  (Try the stream h264/reinit-large_420_8-to-small_420_8.h264 in the fate samples.)
> 
> yes, it breaks - the player still shows and image but it is corrupted.
> I am not sure how to handle this situation to be honest...so need to look into this.

There should be some way to detect it from the decoder, I think?  (I don't actually know how this works in V4L2.)

To compare, if you look at MMAL (perhaps the most similar API in current lavc) there is a special FORMAT_CHANGED return when dequeuing a frame, and the decoder is reconfigured with new buffers when that happens: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mmaldec.c;h=0b1195dc3e6f09beb74e3e47404456114596c499;hb=HEAD#l713>.

>>
>> Also, are the frames returned here actually still used by the decoder internally as reference frames, or is the reference frame copied somewhere else? 
> 
> I think once the buffers are dequeued, the v4l2 decoder doesnt keep any references to it.
>>  (Seems slightly unlikely that they would be copied given the additional memory requirements, but I know discrete desktop GPUs (which admittedly have 9001x the memory bandwidth and power budget) do do this to hide the possible issues.)  I think, though I'm not entirely sure because I haven't run it, that the returned buffers will only have the user reference, so will appear to be writable to following filters - if that ends up writing on reference frames then the decoder will break.
> 
> ack

Ok.  I'm a bit surprised because of the performance implications of writing everything twice, but if we don't have to think about it at all then whatever.

- Mark