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

[Nicolas George]

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

I am very surprised to read that. I do not see any filter checking the
permissions, they just assume they have what they asked for.

> and it causes issues as you yourself describe below

Any solution with the current data structures will cause the same problems,
I'll explain below.

> my question is still open, where is the problem with the permissions
> as i interpret them ?

After more careful examination, I believe we are both right: the thing is
that PRESERVE and WRITE are currently completely redundant, because all
non-buggy filters that want PRESERVE also do not give WRITE to the next and
all non-buggy filters that need WRITE reject PRESERVE.

>		       Permissions should only be droped when theres
> need to drop them.

Why? My intuition with permissions is quite the contrary: permissions should
be kept at minimum and dropped as soon as conveniently possible.

> heres a patch to fix this

That will not work, as  you pointed out.

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

The problem I am thinking of is not there. Consider this filter graph:

fps needs to be sure that the frame it is currently duplicating is not being
written by anyone; in other words, it needs a writer's lock. Now, let us
look at the bigger picture:

                  ,-> showinfo -> X -> out1
    in -> split -<
                  `-> showinfo -> fps -> showinfo -> drawtext -> out2

We already know that a copy will happen in drawtext (except for the last
copy of a frame, but that is an optimisation), so the question is: what does
X? If X writes in the buffer (maybe ass), a copy is necessary, if not (maybe
scale), it is not necessary.

The problem is that fps can not know what X does: they have each a reference
on the same buffer, but the references themselves are totally unrelated.
Since the permissions live in the reference, there is no communication
possible.

And you are right, the solution would certainly involve counting the number
of read and write references.

Thanks for the discussion, it was a great help in understanding how this
works.