[FFmpeg-devel] Understanding lavfi's permissions system (was: lavfi/audio: fix size of copied samples.)

[Michael Niedermayer]

On Sat, Jul 28, 2012 at 11:09:56PM +0200, Nicolas George wrote:
> (I am snipping a lot to try to recenter on what I think is the core of the
> problem.)
> 
> Le decadi 10 thermidor, an CCXX, Michael Niedermayer a écrit :
> > You seem to assume that split has the right to pass a 2
> > read+write+preserve refs pointing to the same buffer to the 2 outputs
> > thats not allowed, it would be a direct violation of the definition
> > of the permissions, namely that Preserve on A implicates no other
> > reference with write permission exists.
> 
> Forget about preserve: if split has READ+WRITE and give them to both
> drawtext and X, then drawtext and X will write in the same buffer, which is
> wrong. Even if X is read-only, if drawtext acts first, X will read the
> modified buffer, which is wrong too.
> 
> split solves it by removing WRITE, and I think this is more or less the only
> sane solution.

yes, ive thought about the RW issue too and came to the same
conclusion
That is if one consideres that split passes the buffer first to A and
then to B (both outputs from split) then if the first had write the
buffer could change and split would no longer do its "promissed" job
of passing the same data on. Thus it has to remove write from the
first in this sequential case.
If it passes the frame to both at the same time really the same issue
applies as the buffer could change and split would no longer do what
it per its own definition is supposed to namely passing the same to
both, thus it has to remove write from both here too.


> 
> The point I am at now is: I do not see any situation where PRESERVE would
> serve and removing WRITE would not be enough.

iam not sure i understand this statement fully.
but a filter may contain a static buffer that it updates and outputs
each time (examples would be some conditional replenishment decoder)
the frames from it could be read but not preserve beyond "this call"
OTOH a normal mpeg1 decoder with reference frames would have
I/P frames as read+preserve while its b frame output would be
read+write+preserve
and a video output device may have buffers that are write+preserve
or if we assume there are 1 or 2 such hardware buffers only, then
there would be need to reuse them and so their useability beyond
the current call could not be guranteed, this would then be
(read+)write (without preserve as the next frame the buffer has to be
reused for the next frame)

above is a quick list of use cases i could think of
these cover 6 of the 8 flag combination possibilities
the 2 left are no rights and just preserve alone

[...]

-- 
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/20120729/f715a1b4/attachment.asc>