[FFmpeg-devel] [PATCH 3/6] avutil: delay removal of the PIX_FMT_* flags
floemker at gmx.de
Tue Aug 11 06:11:21 CEST 2015
On 08/10/2015 01:18 PM, Ronald S. Bultje wrote:
> Hi Frank,
> On Sun, Aug 9, 2015 at 2:28 PM, Frank Lömker <floemker at gmx.de> wrote:
> I think there's a pretty big misunderstanding here: you think we're just
> frivolously changing API to annoy you. That's not the case. We're
> changing/adding API to expose new features, fix namespacing conflicts or
> allow for better quality or new types of optimizations.
No, there is no misunderstanding. The problem are not that much these
changes per see, but the extreme short deprecation phase. Of course less
changes to begin with would be nice as well.
> If you don't want
> any of these, there's no need for you to update to new versions of ffmpeg,
> and you can just stick to older ffmpeg releases, we have release branches
> for that very purpose.
That would mean to have an own copy of FFmpeg in the project. And no, that
is definitely not what one wants to have. Even more so for small tools.
> We're not keeping old and new APIs around for longer than the originally
> guaranteed compatibility period (~2 years). This would just mean half of
> our users get the good experience and the other half gets the bad,
> depending on which API the version of their app uses. We don't want that.
> We want everyone to have the very best experience that we can provide.
Adding a FF_ENABLE_BROKEN or something like that, which would enable
compatibility wrapper for the last four++ years would really help.
And if a program uses PIX_FMT_xxx instead of AV_PIX_FMT_xxx is for an
end user completely unimportant. The same is true for most of these
> In one of my earlier emails, I already offered to help Debian out with
> patches related to ffmpeg API changes in apps in their repos. I hereby
> repeat that offer to non-Debian opensource applications, hopefully that
> mutes the rest of the sentiment in that blog post, so we can move on and do
> what's right for our users. As for what venue to use for such questions,
> I'd recommend stackoverflow, but feel free to use this mailinglist of IRC
> if you so prefer.
What really would be nice is preventing the following in a user program:
#if LIBAVUTIL_VERSION_INT > ((50<<16)+(200<<8))
# define AVERROR_NOFMT AVERROR_INVALIDDATA
#if LIBAVUTIL_VERSION_INT < ((50<<16)+(14<<8))
# define AVMEDIA_TYPE_VIDEO CODEC_TYPE_VIDEO
#if LIBAVUTIL_VERSION_INT < ((49<<16)+2)
# define PIX_FMT_GRAY16 (PIX_FMT_NB+100)
# define PIX_FMT_GRAY16LE PIX_FMT_GRAY16
# define PIX_FMT_GRAY16BE PIX_FMT_GRAY16
#if LIBAVCODEC_VERSION_INT < ((55<<16))
# define AVCodecID CodecID
#if LIBAVCODEC_VERSION_INT < ((53<<16)+(8<<8))
# define avcodec_open2(cc,c,o) avcodec_open(cc,c)
#if LIBAVCODEC_VERSION_INT < ((52<<16)+(30<<8)+2)
# define AV_PKT_FLAG_KEY PKT_FLAG_KEY
just to be able to to compile it with slightly older versions.
And yes, I know, you would call that useless and advice to use
a copy of FFmpeg.
But supporting older distributions out of the box is IMHO
More information about the ffmpeg-devel