[FFmpeg-devel] [PATCH] lavfi/audio: fix size of copied samples.

Nicolas George nicolas.george at normalesup.org
Sat Jul 21 12:39:13 CEST 2012


Le quartidi 4 thermidor, an CCXX, Michael Niedermayer a écrit :
> i dont think access permissions have been considered/implemented
> very well in most filters. So some existing filters are
> maybe not a good example and work more by luck than correctness/
> consistency

That may be so, and indeed I can spot a few inconsistencies. But do you
agree the mechanism I described works? For reference:

* If a filter wants WRITE, it rejects PRESERVE; if a frame with PRESERVE
  arrives, it is copied because of that.

Also, if the filters that want PRESERVE just remove WRITE when sending the
frame, I do not see the point of the PRESERVE at all: removing WRITE is
enough.

> The problem i see is that the permissions no longer are well
> defined as in that they are no longer sufficient on their own to say
> what can be done with a reference
> But maybe iam misunderstanding 

That is absolutely true, but I do not think this is a problem. Permissions
in lavfi must not be seen as an access control mechanism:

[ drawtext @ 0xdeadbeef ] No WRITE permissions, too bad

Permissions in lavfi are a mechanism to ensure that filters have always what
they need without walking on each other's feet.

The only problem I see with that is that it is very surprising and
counterintuitive, and as such requires careful documentation and will
confuse beginners even so. That would probably a good reason to redesign it
if it were not for the compatibility issues (both backward and with the
fork).

> PRESERVE|READ and PRESERVE|WRITE have different meanings.
> The first is a reference that cannot be changed by anyone but can be
> read by us. the second is a reference that cannot be changed by others
> but can be changed by us.

Yes, exactly. But after some thought, REUSE2 gives more information. Forget
I told anything about it.

> you can drop the "implicitly or otherwise" from the sentance. I just
> meant that a decoder could keep a reference by means different from
> libavfilter API. This detail probably is irrelevant here ...

Ok. I believe, in that case, the glue between the decoder and lavfi should
keep a reference to let lavfi know it is there.

> A filter may receive a "PRESERVE" reference without requesting one.

I do not see a case where it would be useful.

> also a filter might request one and later no longer need it
> (for example a decoder might have used it as reference frame but
> knows it wont be used as reference frame again) In this case
> it could pass the reference on with PRESERVE attribute.

It could also downgrade the permissions to remove PRESERVE, in that case.

Regards,

-- 
  Nicolas George
-------------- 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/20120721/3e2a40ae/attachment.asc>


More information about the ffmpeg-devel mailing list