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

Nicolas George nicolas.george at normalesup.org
Fri Jul 27 00:39:41 CEST 2012


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.

Now, for the rej_perms part. The naïve way of implementing things would have
been:

	if ((dst.min_perms & AV_PERMS_WRITE) &&
	    (incoming_ref->perms & AV_PERMS_PRESERVE))
	    copy_needed = 1;

In other words: if the incoming buffer is locked and the filter wants to
write, a copy is needed. A similar stanza is necessary for REUSE2.

Having AV_PERMS_PRESERVE in rej_perms has the same effect, but requires less
tests.

> > The decoder can request a buffer with PRESERVE and then remove the PRESERVE
> > when it realizes the frame is not a reference frame.
> yes, but considering PRESERVE cannot be added back later (there could
> be others having write references at that point in the general case)

I agree with that.

> it would be preferable not to do that IMHO

I do not see the problem. A filter will release its PRESERVE lock if it is
sure it will never need it again. And indeed, if it does, the contents of
the buffer can become utter garbage. If it needs again a buffer with
PRESERVE later, it can just get another one.

On the other hand, now that I understand what is going on better, I realize
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.

Regards,

-- 
  Nicolas George


1: it does, test this:
./ffmpeg_g -re -f lavfi -i 'testsrc=r=1,fps=fps=25,drawtext=fontfile=/usr/share/fonts/truetype/freefont/FreeSerif.ttf:fontsize=20:fontcolor=red:text=Hello:x=10*t:y=100' -pix_fmt yuv420p -f sdl -
-------------- 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/1125559e/attachment.asc>


More information about the ffmpeg-devel mailing list