L'octidi 28 frimaire, an CCXXV, James Almer a écrit : > Is this to make AVFilterLink a fully internal struct?
As you can see in patch 6/6 in this series.
> What's the reason
> to do that in that case, instead of simply making its private fields
> actually internal and private?
Can you suggest a method?
> The idea for next bump was to clean all this mess for once and for all by
Good: after this patch, there is no mess, everything is accessed through
the buffersink API.
> deprecating all accessors, removing all the "no direct access" notes and
> moving all the private fields in public structs (Marked with a big "not
> part of the public API" warning like in the case of with AVFilterLink)
> into actual internal structs.
By "actual internal structs", I suspect you mean something similar to
this:
typedef struct AVFormatContext {
...
AVFormatInternal *internal;
...
};
Introducing these structures was a big mistake. For the reasons, see the
recent discussion about making filter_frame() non-recursive (short of
it: it makes the actual code unreadable), plus another discussion I did
not take part about using options on these structure (short of it: a lot
of work if even possible).
I do not intend to extend that mistake in libavfilter. If possible, I
would rather like to kick it out, but fortunately the current uses are
very limited.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
