Re: [FFmpeg-devel] [PATCH v2 1/6] fflcms2: move to libavcodec

From: Niklas Haas <ffmpeg@haasn.xyz>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v2 1/6] fflcms2: move to libavcodec
Date: Tue, 12 Jul 2022 14:09:04 +0200
Message-ID: <20220712140904.GB21507@haasn.xyz> (raw)
In-Reply-To: <DB6PR0101MB22148B86B73B83AFF8D2EB548F809@DB6PR0101MB2214.eurprd01.prod.exchangelabs.com>

On Wed, 06 Jul 2022 16:18:21 +0200 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> Niklas Haas:
> > From: Niklas Haas <git@haasn.dev>
> > 
> > We will need this helper inside libavcodec in the future, so move it
> > there, leaving behind an #include to the raw source file in its old
> > location in libvfilter. This approach is inspired by the handling of
> > vulkan.c, and avoids us needing to expose any of it publicly (or
> > semi-publicly) in e.g. libavutil, thus avoiding any ABI headaches.
> 
> This is only correct if you work under the assumption that when building
> with static libraries, all the static libraries come from the same
> commit. If you e.g. allow to build with an older libavfilter and a newer
> libavcodec (like with shared libs), this assumption breaks down: if the
> newer version of this file exports another function, you get linker
> (ODR) errors because both versions might be pulled in.
> Behaviour/signature changes by any function or modifications to any of
> the structs would be similarly catastrophic.
> 
> A way out of this mess would be to version everything in the header like so:
> #define FFLCMS2_VERSION 1
> 
> void AV_JOIN(ff_icc_context_uninit, FFLCMS2_VERSION)(FFIccContext *s);
> 
> (of course, there should be a dedicated macro for this to reduce typing.)
> 
> A patch that makes any of the "catastrophic" modifications described
> above would need to bump the version. If one uses compatible versions,
> the files would be deduplicated for static builds.
> It would of course have the downside that these macros would be
> everywhere where it is used, not only in fflcms2.[ch].

I suppose you could also version this API on a symbol-by-symbol basis,
with v1 being the current version (and then v2 getting a 2 suffix, and
so on).

In that case, we don't need to do anything currently, rather the first
patch to modify this API would have to worry about making sure the new
symbol doesn't conflict.

> 
> > 
> > It's debatable whether the actual code belongs in libavcodec or
> > libavfilter, but I decided to put it into libavcodec because it
> > conceptually deals with encoding and decoding ICC profiles, and will be
> > used to decode embedded ICC profiles in image files.
> > 
> > Signed-off-by: Niklas Haas <git@haasn.dev>
> > ---
> >  libavcodec/Makefile   |   1 +
> >  libavcodec/fflcms2.c  | 311 ++++++++++++++++++++++++++++++++++++++++++
> >  libavcodec/fflcms2.h  |  87 ++++++++++++
> >  libavfilter/fflcms2.c | 294 +--------------------------------------
> >  libavfilter/fflcms2.h |  65 +--------
> >  5 files changed, 401 insertions(+), 357 deletions(-)
> >  create mode 100644 libavcodec/fflcms2.c
> >  create mode 100644 libavcodec/fflcms2.h
> > 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".