[FFmpeg-devel] [PATCH 3/3] lavc: remove Libav ABI compat hacks

[Ronald S. Bultje]

Hi,

On Sat, Sep 5, 2015 at 2:58 PM, Nicolas George <george at nsup.org> wrote:

> Le nonidi 19 fructidor, an CCXXIII, James Almer a écrit :
> > Without this option, the AVPixelFormat enum values in libavutil/pixfmt.h
> > don't match between projects. It's absolutely needed for abi
> > compatibility, so knowing if anyone used it is important because it will
> > show if said compatibility was ever used/needed or not.
>
> I believe that Ronald, Paul and you miss the point that I am making. I will
> re-state the problem clearly, please read carefully, and if you do not
> agree
> with a particular point, please answer with precision.
>
> Until now, it has been a project policy to ensure API and ABI compatibility
> with the fork as much as possible.
>
> One of the constraints caused by that policy is this: codec-id values added
> in FFmpeg must not conflict with codec-id values added later by libav.
>
> This is done by using 4cc values, which is not an issue at all.
>
> Along the way, a few cases were missed. It causes minor ABI
> incompatibilities, negligible in real situations. See "as much as possible"
> in the policy statement above.
>
> Since there is a major bump going on, there is an occasion to fix the
> incompatibilities. Very good.
>
> But fixing the present incompatibilities does not prevent future
> incompatibilities.
>
> To continue maintaining compatibility, the 4cc values must stay.
>
> The current patch removes the 4cc values, replacing them with normal
> enumerated order, that will conflict with the first addition in libav.
>
> In short: with the bump, we can clean-up and restart with perfect ABI
> compatibility, now and in the future. This patch breaks it. Do you support
> it?


I don't know what "it" is, but I don't believe we have ABI compat until I
see a fate station continuously testing it.

So, that said, given that we don't have (proven) ABI compat, I don't see
any reason to keep code related to it. API compat is good enough. Yes, the
fourcc "enums" can go.

Ronald