[FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Thu Jul 30 19:10:12 CEST 2015

On 30.07.2015 18:26, Anton Khirnov wrote:
> Quoting Andreas Cadhalpun (2015-07-30 17:49:51)
>> I think that keeping some of these APIs "forever" is much less of a problem
>> then breaking the majority of reverse dependencies.
> The API breaks are not done for the fun of it.

I hope so. ;)

> There's a bunch of reasons why I think keeping them is a bad idea:
> - some of the changes involve adding prefixes for proper namespacing, so
>   libav does not randomly conflict with other libraries. Here, keeping
>   the old names pretty much negates the whole point.

However, it works without namespace clashes so far.

> - the less trivial changes are mostly done because the old API was
>   inadequate. Many of the old APIs were not designed at all, but just
>   randomly added because mplayer or ffmpeg.c happened to need some
>   feature at the time. The result was usually un(der)documented, hard to
>   use correctly and often not well defined in some cases. Most users of
>   the old API that I've seen actually used it wrong and would at best
>   occasionally fail to work, at worst crash randomly. So keeping those
>   APIs is not really in anyone's interest IMO.
> - finally there's of course the maintenance burden of keeping
>   compatibility layers, sometimes of rather large complexity. They are
>   also often poorly tested and not very much maintained so, again, they
>   might fail to work in some less common cases.

Removing these APIs causes compile failures, which are more severe than
occasional runtime failures. It means people have to use old versions of
the libav* libraries.

>>> Most of then, unfortunately, have to be forced into adopting the new APIs.
>> Have you tried sending them patches before breaking compatibility?
> I actually did fix a huge number of packages during the last two API
> breaks. But it's not really reasonable to expect me to do it all the
> time.

Certainly. But someone has to do the work, if you want to remove widely
used APIs.

Best regards,

More information about the ffmpeg-devel mailing list