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

Michael Niedermayer michaelni at gmx.at
Fri Jul 20 15:57:08 CEST 2012

On Fri, Jul 20, 2012 at 03:18:48PM +0200, Nicolas George wrote:
> Le duodi 2 thermidor, an CCXX, Michael Niedermayer a écrit :
> > avfilter.h says:
> > #define AV_PERM_WRITE    0x02   ///< can write to the buffer
> > #define AV_PERM_PRESERVE 0x04   ///< nobody else can overwrite the buffer
> > 
> > I interpret this as:
> > 
> > 0 -> We are not allowed to write to the buffer and there is no
> >      gurantee that the buffer content stays as it is.
> > AV_PERM_WRITE -> we can write to the buffer, so can other filters, we
> >                  cannot assume that the buffer content stays unchanged
> > AV_PERM_PRESERVE -> noone can write to the buffer, its content is
> >                     guranteed to stay unchanged
> > AV_PERM_WRITE|AV_PERM_PRESERVE -> we can write to the buffer but noone
> >                                   else is allowed to, so it wont change
> >                                   unless we change it.
> > 
> > From this inerpretation i dont see why write implicates not preserve
> That is not what I meant, sorry if I was not clear. What I mean is that the
> semantic of PRESERVE is implemented by adding it to rej_perms always when
> WRITE is requested. Let me take an example to make things more clear:
> movie_dr=some_file , showinfo , drawtext=options , sink
> movie_dr is a version of movie with direct-rendering implemented. The
> buffers it uses must not be overwritten by others, because they may be
> reference frames.
> showinfo only reads the frame, it can operate on the frame from movie_dr
> without copy.
> drawtext writes in the frame, it requires a copy. Since decisions are local,
> the copy is between showinfo and drawtext.
> What happens is:
> movie_dr has READ|WRITE|PRESERVE.
> It gives gives a new reference for the same buffer to showinfo; the
> reference still has READ|WRITE|PRESERVE, showinfo only cares about READ.

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.

> showinfo gives a new reference to the same buffer to drawtext. But drawtext
> has PRESERVE in rej_perms: lavfi makes a copy before sending it to drawtext.
> In other words, PRESERVE on a reference means: someone wants to be the only
> one tinkering with the contents of the buffer. If it's me (some filter),
> fine. If it is someone else, and I intend to write (min_perms = WRITE), I
> need a copy: thus rej_perms = PRESERVE.

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


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20120720/eddca768/attachment.asc>

More information about the ffmpeg-devel mailing list