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

[Michael Niedermayer]

On Thu, Jul 19, 2012 at 05:48:33PM +0200, Nicolas George wrote:
> L'octidi 28 prairial, an CCXX, Michael Niedermayer a écrit :
> > all permissions should be about references, there can be multiple
> > references with different permissions on the same buffer.
> > 2 references to a buffer could but dont have to overlap in storage
> > space, for example there could be a top and a bottom field reference
> > in a single physical frame buffer. Or a 16:9 and 4:3 view of a frame
> > 
> > anyway the way i interpret WRITE and PRESERVE is that
> > write allows writing, preserve disallows everyone else writing
> > if you have a reference with AV_PERM_PRESERVE, you can drop 
> > AV_PERM_PRESERVE and this should never break anything, you just droped
> > the gurantee that noone else can change the buffer.
> > 
> > a reference without AV_PERM_PRESERVE can be changed by others, for
> > example it might be a static internal buffer of a codec that will
> > change with each frame.
> > 
> > anyway the handling of AV_PERM_PRESERVE is not consistent in the code
> > so above is not the only option there is
> > Also maybe it should be renamed to AV_PERM_EXCLUSIVE
> 
> I think I finally understand bufref permissions. Please correct me if I am
> wrong:
> 
> From lavfi's framework point of view, permissions are just abstract labels.
> There are a few places where PERM_READ is added, and once where
> PERM_NEG_LINESIZES is added, but except for that, the glue and algorithms
> between the filters does not care at all about PRESERVE or REUSE2, etc.
> 
> The part that makes the permissions acquire their own semantic is the
> min_perms / rej_perms system. For reference: when ff_start_frame /
> ff_filter_samples is called with a reference without a permission in
> min_perms or with a permission in rej_perms, the buffer is copied. For
> things to work, all filters must get their rej_perms consistent with their
> min_perms.
>

> For PRESERVE in particular: if a filter has WRITE in min_perms, then it must
> necessarily have PRESERVE in rej_perms.

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


> 
> Also, any filter that keeps a reference after the previous filter has
> finished transmitting it should reject REUSE2.



> 
> Also, considering the first sentence:
> 
> > all permissions should be about references, there can be multiple
> > references with different permissions on the same buffer.
> 
> I would like to reword it:
> 
> The permissions of a reference explain what the part of the code that is
> currently owning the reference is allowed to do with the underlying buffer.

sounds good


> 
> As references can only be owned by one part of the code at once, their
> fields (including the fields in the indirect video/audio parts) can be
> modified at will.
> 
> I'll push a change to af_amerge to remove PRESERVE from min_perms and add
> REUSE2 to rej_perms.
> 
> Regards,
> 
> -- 
>   Nicolas George



> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20120719/2319e2fa/attachment.asc>