[FFmpeg-devel] v4l2: bug #1570 and possible solution

[Giorgio Vazzana]

2013/2/13 Giorgio Vazzana <mywing81 at gmail.com>:
> 2013/2/13 Michael Niedermayer <michaelni at gmx.at>:
>> On Wed, Feb 13, 2013 at 04:53:43PM +0100, Michael Niedermayer wrote:
>>> consider the buffer at index i
>>>
>>> Initially its "owned" by v4l2, no other thread can interfere here
>>> because nothing else has this buffer and any other buffers use a
>>> different index than i
>>>
>>> now v4l2 sets up a AVPacket with this buffer and sets the array[i] = 1
>>> still nothing else knows about this packet yet so no interference
>>> possible.
>>> the AVPacket is then returned from read_packet
>>>
>>> now from the point of view of the read packet function as long as
>>> array[i] == 1 the buffer is in use and wont be (re)used in any way
>>> the only thing that can set it to 0 is the packets destructor which
>>> is only called once and only once the buffer is no longer in use.
>>> so if array[i] == 0 in read_packet then this implies that the
>>> destructor has been called and the buffer is free to be reused
>>> it also implies there is nothing else left that could temper with it
>>> anymore except read_packet itself
>
> Okay, thanks for the explanation, it's a clever technique but I think
> I understand how it works now, I can try to implement it in the
> following days.

Here we go, fix for bug #1570, round 4.

>> one thing i forgot, if you try to implement this you need to be
>> carefull with deallocating the array as the destruct callbacks if any
>> is left can still access it.

The behaviour is not changed in this respect, compared to the current code.

> This should not be an issue, if we deallocate the array in v4l2_read_close().
> Note that the current code has this problem too: the user/application
> needs to call av_free_packet() (which will in turn call the packet
> destructor) on all packets before calling v4l2_read_close(), otherwise
> pkt->data will be invalid and a call to the packet destructor will use
> a closed fd.
> To solve this issue we could set fd=-1 on close, add a check for fd>0
> in the destruct callback.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lavd-v4l2-copy-frames-into-normally-allocated-packet.patch
Type: application/octet-stream
Size: 6017 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130214/f3ed961c/attachment.obj>