[FFmpeg-devel] [PATCH] filter_design: document ownership and permissions.

[Nicolas George]

Le septidi 27 thermidor, an CCXX, Stefano Sabatini a écrit :
> > +    * AV_PERM_PRESERVE: the owner can rely on the fact that the buffer data
> > +      will not be modified by previous filters.
> I'm not sure about this. When a filter receives a filter with
> PRESERVE, I interpret this like "this buffer should be preserved",
> that is the current filter is not allowed to write on it, other
> filters (e.g. the filter which marked it with "PRESERVE"), may be
> modifying it.

That was main the object of the discussion with Michael, and it convinced me
it did not work, for at least two reasons: this is a negative permission, it
tells you something that you are not allowed to do with the buffer, and it
is completely redundant with removing the WRITE permission.

This interpretation actually brings useful information (no previous filter
has kept a WRITE reference and intend to use it) and is a positive
permission.

Of course, all filters that were written according to the other
interpretation will need to be fixed, but git gep will find them easily.

> My understanding is that REUSE/REUSE2 are mostly useful when
> *requesting* the buffer, and possibly used by the allocator, but are
> ignored by filtering operations.
> 

Well... yes and no. These flags are clearly there to deal with special
allocators, but the permission may be required for input frames. Think about
split of fps, for example: they require REUSE but do not normally create a
new buffer.

> I suppose it is "READ permission on input". 

Yes, of course. I fixed it after Michael's mail.

> About: "and WRITE permission on the new buffer"
> maybe a more explicit equivalent:
> and must request a buffer with WRITE permission

I'll fix the other points you made and wait comments on the question of
PRESERVE and REUSE.

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/20120813/677c794c/attachment.asc>