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

Michael Niedermayer michaelni at gmx.at
Sat Jul 21 06:29:08 CEST 2012

On Sat, Jul 21, 2012 at 01:24:57AM +0200, Nicolas George wrote:
> Le tridi 3 thermidor, an CCXX, Michael Niedermayer a écrit :
> > IMHO movie_dr should remove WRITE from the reference before passing it
> > on, also PRESERVE would need to be removed if movie_dr keeps a second
> > reference with WRITE permission, or more precissely if there exists a
> > reference with PRESERVE than no other reference can have WRITE
> > permission, that can be enforced on reference creation.
> I believe it could be done like that, but the more I look at the code the
> more I think this is not how it currently works. And obviously, the current
> code works.

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/

> > this sounds quite problematic to me.
> > movie_dr has a WRITE+PRESERVE reference, so does showinfo, its same
> > flags but the 2 have totally different rights
> > movie_dr can write and has a gurantee that noone else writes
> > showinfo has no write rights nor does it know for sure movie_dr wont
> > change the buffer.
> I do not think this is problematic, as long as it is properly explained. And

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 

> I would not be surprised if someone comes up with a case where
> distinguishing between PRESERVE|READ and PRESERVE|WRITE would be useful.

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.

> > also movie_dr can have a WRITE+PRESERVE reference and no other
> > reference in which case no copy is needed later or it can keep a second
> > reference implicitly or otherwise in which case a copy is needed.
> I do not understand what you mean by "implicitly" here. Concerning the part

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 ...

> I do understand, there is not much point in requesting PRESERVE and then
> giving away the reference.

A filter may receive a "PRESERVE" reference without requesting one.
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.


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/7f9b520f/attachment.asc>

More information about the ffmpeg-devel mailing list