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

Nicolas George george at nsup.org
Sun Nov 13 23:57:30 EET 2016

Le tridi 23 brumaire, an CCXXV, James Almer a écrit :
> I don't really like this method. This kind of ifdeffery is very
> uncommon and feels dirty. Just look at avutil/common.h to see how bad
> a public header can get this way.
> I'd prefer if we can stick with the usual internal opaque structs
> instead.

What is the exact solution you would propose instead? Please give a
thought to the drawbacks of any alternative solution compared to this
one, including indirection overhead.

> The plan was to remove as many internal-but-not-really fields across
> the codebase as possible on the next major bump. Ideally, we'd be
> consistent with whatever method we choose to achieve this, and opaque
> structs are already being used everywhere, including avfilter.h

Almost everything in AVFilterLink is internal, but it is still needed
there, it can not be removed.

I think you are confusing with per-codec fields: fields that serve only
for a few codecs are moved in private structures. But fields that are
common to most codecs stay in the context.

To hide private fields from the public API is a different issue
altogether. There are several ways of doing that, the one I used was the
one I found that minimizes first overhead, then brittleness, then
ugliness. But I am open to other suggestions.

> In any case, this is missing the usual header guards.

This is intentional: this is not a normal header, it should not be
included the normal way, and in particular never twice. The absence of
guards is meant as a hint in that direction.

> This shouldn't happen. Guess it's because of the missing guards?

I do not mind adding the guards to avoid that, if that it what people


  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/20161113/462b14c1/attachment.sig>

More information about the ffmpeg-devel mailing list