[FFmpeg-devel] [PATCH] lavfi/audio: fix size of copied samples.
Michael Niedermayer
michaelni at gmx.at
Fri Jun 15 18:40:33 CEST 2012
On Fri, Jun 15, 2012 at 04:18:39PM +0200, Nicolas George wrote:
> Le duodi 22 prairial, an CCXX, Stefano Sabatini a écrit :
> > The question is, why AV_PERM_PRESERVE is needed on the amerge input
> > min_perms? Note that I don't know (I asked when the patch was reviewed
> > IIRC but can't remember any reply), but looks just wrong to me.
>
> My reasoning for that is this: amerge keeps the reference for later, but has
> already examined part of it, it would be catastrophic if someone else were
> to alter it in the meantime.
>
> In this particular case, the part that was already examined is the
> audio->nb_samples field (the total number of samples in queue is kept for
> each input), so I realize it probably can not be changed at all.
>
> > I believe AV_PERM_PRESERVE should stay in rej_perms, meaning that it
> > won't accept a buffer which must be preserved, while the filter will
> > write over it, asking for a buffer *which can't be modified* doesn't
> > make much sense to me.
>
> There are several things that are a bit unclear to me about permissions:
>
> - Does the permission apply to the buffer or to the reference?
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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Avoid a single point of failure, be that a person or equipment.
-------------- 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/20120615/eeb240af/attachment.asc>
More information about the ffmpeg-devel
mailing list