[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