[FFmpeg-devel] Compatibility of different library versions (was: avformat: Add internal flags for AV(In|Out)putFormat)

[Diederick C. Niehorster]

Top-posting on purpose:

Several core developers stated to be in favor of locking lavd<->lavf
together at the minor version, for instance since it solves a lot of
the problems the intimate linking between the two libraries creates.
Should this be turned into a patch somehow (i'm not sure how to do
such linking)? If so, could someone send this patch or guide me
through it, so that the discussion can be finished?
Thanks!

On Thu, Jun 17, 2021 at 12:45 AM James Almer <jamrial at gmail.com> wrote:
>
> On 6/16/2021 7:14 PM, Nicolas George wrote:
> > James Almer (12021-06-16):
> >> I'm not sure what you mean. I would not be against it, it's just that if we
> >> were to merge lavf and lavd, this wouldn't even be something to consider.
> >
> > Have you not read the discussion? The benefits go way beyond the tiny
> > lavf-lavd issues.
> >
> >>> and why you are
> >>> against for other libraries.
> >> Can you be more specific?
> >
> > When I say "I am for X" and you reply "I am not against Y", with Y⊂X and
> > Y≠X, you are implicitly saying that you are against X∖Y. I proposed to
> > restrict to matching versions on all libraries, you replied you were not
> > against restricting for lavf-lavd, stating implicitly that you are
> > against it for the libraries.
>
> Considering this discussion started about lavd and lavf, and at no point
> in your email you said "all libraries" when suggesting version locking
> anything (In fact, you mistakenly wrote "only versions from the same
> version"), i figured it would be obvious i was commenting specifically
> about lavd<->lavf.
>
> >
> > So, I ask explicitly: are you against restricting to matching versions
> > for all the libraries? If so, then why?
>
> Of course i am against doing so for all libraries. They are already
> locked at the major soname level as required, and that's enough.
> Lavd as is is locking certain lavf's public structs and making it
> impossible to add new fields to them, which constricts development
> considerably, so making their locking strict to at least the minor
> soname level is a very good idea. But this isn't an issue at all for
> other libraries.
> I can add new fields to any public lavc struct, compile it and have a
> lavf that was linked to an old lavc use it at runtime, and it will work
> just fine.
> I see no benefit to your suggestion that's worth removing such freedom
> from the end user.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".