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

[Nicolas George]

Le duodi 12 thermidor, an CCXX, Michael Niedermayer a écrit :
> 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

So, if I understand you correctly, you mean that A giving a ref to B with
PRESERVE+WRITE means: "you know I have write permissions since I am giving
them to you, I promise I will no longer use them, and I promise that no
filter before me will neither". Is that it?

But it seems to me this is redundant with REUSE2: if I understand it
correctly, a filter or source that intends to write again in a ref after it
has sent it to the output is supposed to get the REUSE2 permission on it.

Or maybe this is the way you want to use the permissions:

- a (normal) buffer has initially all four permissions: READ+WRITE+PRESERVE+
  REUSE2.
- If a filter needs to be sure a buffer will still be the same later, it
  must make sure it has PRESERVE (it guarantees that the previous filters do
  not intend to write in it again) and remove WRITE before forwarding it.
- If a filter intend to write again in the buffer later, it must make sure
  it has REUSE2 and remove PRESERVE before forwarding.

? That would work, but when would a buffer not have REUSE2?

> 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)

I am sorry, I was not able to understand that.

Regards,

-- 
  Nicolas George
-------------- 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/8009f2d6/attachment.asc>