[FFmpeg-devel] v4l2: bug #1570 and possible solution
michaelni at gmx.at
Fri Mar 1 15:56:25 CET 2013
On Thu, Feb 28, 2013 at 12:00:03PM +0100, Giorgio Vazzana wrote:
> 2013/2/14 Giorgio Vazzana <mywing81 at gmail.com>:
> > 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.
ive gotten some v4l2 hw to run here with the patch (it doesnt work
before the patch)
but if i run the following command 10 times or so then once in a while
ffmpeg_g -y -f video4linux2 -i /dev/video0 -t 1 file.yuv
it gets somehow stuck in a loop printing
[rawvideo @ #] st:0 PTS: # DTS: # < # invalid, clipping
and only stopping once it runs out of diskspace
i dont know if this is caused by the patch or was there before as it
seems not to work before at all with the device i tried
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel