[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/
consistency


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