[FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

Nicolas George george at nsup.org
Mon Nov 14 18:42:51 EET 2016


Le quartidi 24 brumaire, an CCXXV, Clement Boesch a écrit :
> You could also make a local copy of the fields you need; it is -in my
> opinion- not that much noise to add one or a few more lines of
> declaration.

When the fields are used read-only, probably. Still more code for no
good reason.

When the fields are used read-write, it would require also storing them
at the end.

And of course it does not work in more complex cases, such as when one
of the field is accessed concurrently by threads.

> Some tool parsing the public header for analyzing structure layout changes
> in public structure to detect ABI and API breakage would not be able to
> make a difference in which fields are public or private.

Ok. Obviously you are speaking about third-party tools. These tools must
rely on the public headers. And, of course, they have to use the
preprocessor correctly, otherwise all matter of libraries, not just
ffmpeg, will not work.

> BTW, it also means you're showing all the internals and their doc to the
> users, which is a lot of noise for them.

I agree, it is not ideal. I can see a few ways of mitigating that, not
very elegant. But I think even that way it is still acceptable.

> Then I guess I'm a bad contributor.

That is not what I meant, and obviously you were not disgusted to the
point of leaving.

> Your private ifdefery suggestion is probably the least worst, but I still
> prefer the common paradigm for previously said reasons that IMO still
> stand.

What about:

struct AVFilterLink {
    ...
#ifdef FF_INTERNAL_API
#inclde "avfilterlink_internal.h"
#endif

That avoids your objection about showing the internal fields to the
users, while avoiding multiline macro definitions and Doxygen trouble.

As a side note, I notice that I have quite a few "defined(__KERNEL__)"
lying around in /usr/include/.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161114/37454c2b/attachment.sig>


More information about the ffmpeg-devel mailing list