[FFmpeg-soc] [soc]: r918 - in libavfilter: avfilter.c avfilter.h defaults.c vf_crop.c vf_fps.c vf_overlay.c vf_passthrough.c vf_slicify.c vf_vflip.c vsrc_dummy.c vsrc_ppm.c

[Michael Niedermayer]

Hi

On Fri, Aug 17, 2007 at 08:21:07PM +0200, koorogi wrote:
> Author: koorogi
> Date: Fri Aug 17 20:21:07 2007
> New Revision: 918
> 
> Log:
> Track the permissions that have been given out to each picture.
> This should make it easier to know what can be done to a buffer once
> it's been passed to your filter without falling back to copying it "just
> to be safe".
[...]
> Modified: libavfilter/avfilter.h
> ==============================================================================
> --- libavfilter/avfilter.h	(original)
> +++ libavfilter/avfilter.h	Fri Aug 17 20:21:07 2007
> @@ -29,6 +29,29 @@ typedef struct AVFilterContext AVFilterC
>  typedef struct AVFilterLink    AVFilterLink;
>  typedef struct AVFilterPad     AVFilterPad;
>  
> +/**
> + * A linked list of filters which reference this picture and the permissions
> + * they each have.  This is needed for the case that filter A requests a buffer
> + * from filter B.  Filter B gives it a buffer to use with the permissions it
> + * requested, while reserving more permissions for itself to use when filter A
> + * eventually passes the buffer to filter B.  However, filter A does not know
> + * what these permissions are to reinsert them in the reference passed to B,
> + * filter B can't assume that any picture it is passed is one that it allocated.
> + *
> + * Rather than have each filter implement their own code to check for this
> + * case, we store all the permissions here in the picture structure.
> + *
> + * Because the number of filters holding references to any one picture should
> + * be rather low, this should not be a major source of performance problems.
> + */

can you please provide an actual example where this complexity is needed
the first problem i see is that your hypothetical filters drop permissions
at random, why should they?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20070817/975aa19c/attachment.pgp>