[FFmpeg-devel] Understanding lavfi's permissions system (was: lavfi/audio: fix size of copied samples.)
michaelni at gmx.at
Mon Jul 30 03:42:03 CEST 2012
On Sun, Jul 29, 2012 at 09:06:03PM +0200, Nicolas George wrote:
> 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.
maybe, ive not thought about the reuse flags much ATM
> Or maybe this is the way you want to use the permissions:
> - a (normal) buffer has initially all four permissions: READ+WRITE+PRESERVE+
> - 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.
yes this sounds like how i interpret the permissions
> ? 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.
consider a grafik card with enough memory to store whats on the
screen twice. it can provide the previous filter through the video
outs get_video_buffer() with one of these 2 buffers
the previous filter can then draw into the buffer and pass it back
to the video out which checks that its really its own video memory
and then just flip during vsync between the 2 buffers
Now the video out (which is a video sink in libavfilter terminology)
has just these 2 buffers and it can just display them so it depends
on getting them back quickly or it would be stuck.
The best i can see that can be done in the current API in this case
is for the video sink to not give these buffers any preserve or reuse*
flags. This way the previous filter(s) could not sensably keep the
buffers and would either have to return them in to the video out
through start_frame or free them.
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
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel