[FFmpeg-devel] Request for --disable-deprecated configure option

[FFmpeg-devel] Request for --disable-deprecated configure option

[Kacper Michajlow]

Hello,

It would be nice to have configure time ability to disable all
`FF_API_*` for testing purposes.

As we know not all code can be marked to emit Wdeprecated.
Specifically #defines doesn't emit any warning and it's easy to miss
such depreciation before it's actually removed.

The breakage of course is not big, but the main issue is that the
current release version of a ffmpeg user won't be compatible with
ffmpeg after API bump, without any period for transition.

--disable-deprecated could be used for testing and ensuring that
(next) API bump goes smoothly. For both ffmpeg and its users.

We have seen breakage in mpv and libplacebo (only when built as
vf_libpalcebo) recently, which would be prevented if we had better
tools to monitor this. For example mpv builds with ffmpeg master on CI
with Werror and Wdeprecated enabled and yet it's not enough.

Thanks,
Kacper
_______________________________________________
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".

Re: [FFmpeg-devel] Request for --disable-deprecated configure option

[Martin Storsjö]

On Thu, 3 Apr 2025, Kacper Michajlow wrote:

> Hello,
>
> It would be nice to have configure time ability to disable all
> `FF_API_*` for testing purposes.
>
> As we know not all code can be marked to emit Wdeprecated.
> Specifically #defines doesn't emit any warning and it's easy to miss
> such depreciation before it's actually removed.
>
> The breakage of course is not big, but the main issue is that the
> current release version of a ffmpeg user won't be compatible with
> ffmpeg after API bump, without any period for transition.
>
> --disable-deprecated could be used for testing and ensuring that
> (next) API bump goes smoothly. For both ffmpeg and its users.

So essentially to configure a build to use the next major API version 
before doing the actual bump?

I've actually mentioned that we should do that (and that we should have a 
FATE instance that continuously tests this, so that we know beforehand 
that our planned next form of the APIs actually works), and I did try 
making a PoC of it at some point, but unfortunately, I think I concluded 
that it was a bit more messy than I had wanted, so I didn't continue 
on it.

See https://github.com/mstorsjo/ffmpeg/commit/next-abi for my PoC.

// Martin

_______________________________________________
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".

Re: [FFmpeg-devel] Request for --disable-deprecated configure option

[Kacper Michajlow]

On Thu, 3 Apr 2025 at 11:39, Martin Storsjö <martin@martin.st> wrote:
>
> On Thu, 3 Apr 2025, Kacper Michajlow wrote:
>
> > Hello,
> >
> > It would be nice to have configure time ability to disable all
> > `FF_API_*` for testing purposes.
> >
> > As we know not all code can be marked to emit Wdeprecated.
> > Specifically #defines doesn't emit any warning and it's easy to miss
> > such depreciation before it's actually removed.
> >
> > The breakage of course is not big, but the main issue is that the
> > current release version of a ffmpeg user won't be compatible with
> > ffmpeg after API bump, without any period for transition.
> >
> > --disable-deprecated could be used for testing and ensuring that
> > (next) API bump goes smoothly. For both ffmpeg and its users.
>
> So essentially to configure a build to use the next major API version
> before doing the actual bump?
>
> I've actually mentioned that we should do that (and that we should have a
> FATE instance that continuously tests this, so that we know beforehand
> that our planned next form of the APIs actually works), and I did try
> making a PoC of it at some point, but unfortunately, I think I concluded
> that it was a bit more messy than I had wanted, so I didn't continue
> on it.
>
> See https://github.com/mstorsjo/ffmpeg/commit/next-abi for my PoC.

Yes, making the API version configurable would work. But as you
noticed it gets a bit messy with all the conditionals.

I didn't think about it long, I wanted to discuss this first, but was
thinking about a simple DISABLE_DEPRECATED which would be defined by
configure and all `FF_API_*` would depend on that.

#define DISABLE_DEPRECATED 0
#define FOO(c) (c) && !DISABLE_DEPRECATED

#define LIBAVUTIL_VERSION_MAJOR  60
#define FF_API_MOD_UINTP2               FOO(LIBAVUTIL_VERSION_MAJOR < 61)
#define FF_API_RISCV_FD_ZBA             FOO(LIBAVUTIL_VERSION_MAJOR < 61)
...

Also if someone wants to go fancy, the deprecated feature could be
disabled individually, but I don't really see much use for that,
except niche cases where you might still use deprecated things, but
not all... but then just don't disable them.

- Kacper
_______________________________________________
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".

Re: [FFmpeg-devel] Request for --disable-deprecated configure option

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 955 bytes --]

Hi

On Thu, Apr 03, 2025 at 11:02:01AM +0200, Kacper Michajlow wrote:
> Hello,
> 
> It would be nice to have configure time ability to disable all
> `FF_API_*` for testing purposes.
> 
> As we know not all code can be marked to emit Wdeprecated.
> Specifically #defines doesn't emit any warning and it's easy to miss
> such depreciation before it's actually removed.
> 
> The breakage of course is not big, but the main issue is that the
> current release version of a ffmpeg user won't be compatible with
> ffmpeg after API bump, without any period for transition.
> 
> --disable-deprecated could be used for testing and ensuring that
> (next) API bump goes smoothly. For both ffmpeg and its users.

I think such a option (in some form) would be a good idea

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".