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

Michael Niedermayer michaelni at gmx.at
Sat Mar 2 02:28:43 CET 2013


On Thu, Feb 14, 2013 at 12:46:32PM +0100, Giorgio Vazzana wrote:
> 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.

>  v4l2.c |   87 +++++++++++++++++++++++++++++++++++++++++++++++------------------
>  1 file changed, 64 insertions(+), 23 deletions(-)
> b1ebebea206816b3835a90f9b73c78988feb8e83  0001-lavd-v4l2-copy-frames-into-normally-allocated-packet.patch
> From 88c99609184449c32f46de09eb8590875ae8abcf Mon Sep 17 00:00:00 2001
> From: Giorgio Vazzana <mywing81 at gmail.com>
> Date: Thu, 14 Feb 2013 12:33:49 +0100
> Subject: [PATCH] lavd/v4l2: copy frames into normally allocated packets whenever there is just one buffer left available
> 
> This will avoid the possibility that we dequeue more buffers than we
> have obtained from the v4l2 driver.
> 
> Fixes ticket #1570

applied

thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130302/3682437b/attachment.asc>


More information about the ffmpeg-devel mailing list