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

[Michael Niedermayer]

On Fri, Jul 27, 2012 at 03:09:27AM +0200, Michael Niedermayer wrote:
> On Fri, Jul 27, 2012 at 12:39:41AM +0200, Nicolas George wrote:
> > Le sextidi 6 thermidor, an CCXX, Michael Niedermayer a écrit :
> > > I think we maybe have a different understaning of "my permissions" vs.
> > > "the previous filters permissions"
> > > 
> > > if the previous filter holds a PRESERVE+WRITE (random example) ref
> > > then this is kind of a exclusive locked write buffer. If now the
> > > previous filter passes this to us it becomes our reference and our
> > > lock. so rej_perms= PRESERVE would be quite odd.
> > > 
> > > maybe theres a problem with my view above but i dont see any ATM ...
> > 
> > Maybe stating it like that can work:
> > 
> > The permissions that a filter has on the buffer pointed by a reference are
> > exactly the permissions it asked for: the value of min_perms if the buffer
> > comes from an input, the second argument of ff_get_<type>_buffer if the
> > buffer is just created. The perms field in the structure are only there to
> > help lavfi keep track of when a copy is needed.
> 
> this is not how the API was or is supposed to work nor is it what
> is implemented even with all the bugs that are there
> and it causes issues as you yourself describe below
> my question is still open, where is the problem with the permissions
> as i interpret them ?
> 
> 
> [...]
> > there are not-so-corner cases that will not work, i.e. require a copy where,
> > in fact, no copy was needed.
> > 
> > Take vf_fps, for example: it requires a reader's lock, otherwise, a drawtext
> > after it used to draw a scrolling banner would leave a sludge¹. But a
> > reader's lock, aka PRESERVE, can not be acquired on an existing buffer.
> > 
> > The core of the problem resides in the fact that the lock is in the
> > reference, and so can only be acquired when no parallelism is possible, i.e.
> > when the buffer is created. I do not think we can go around this without
> > altering the API.
> 
> when a buffer with permissions X is requested one gets a buffer with X
> or more permissions. Permissions should only be droped when theres
> need to drop them. Code currently seem to drop more than needed

rereading and rethinking this, i see a shortcomming of the current API
(any interpretation of it probably) with fps+fifo+drawtext
fps would have to drop write because it keeps a preserve buffer for
duplication while after fifo there may be individual references
that are unshared and could be drawn into saftely by drawtext while
they lost the write rights
This would indeed need a API change (write reference counting for
example)
without the fifo though at the time drawtext gets the buffer, either
theres a reference still in fps so a copy will be needed or if no
reference is kept in fps then theres also no need for fps to have
droped write rights.

[....]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/20120727/25704242/attachment.asc>