We are getting closer to a new release and you can see it is an even release by the amount of old and crufty code we are dropping. This usually is welcomed by some people and hated by others. This post is trying to explain what we do and why we are doing it.
New API and old API
Since the start of Libav we tried to address the painful shortcomings of the previous management, here the short list:
- No leaders or dictators, there are rules agreed by consensus and nobody bends them.
- No territoriality, nobody “owns” a specific area of the codebase nor has special rights on it.
- No unreviewed changes in the tree, all the patches must receive an Ok by somebody else before they can be pushed in the tree.
- No “cvs is the release”, major releases at least twice per year, bugfix-only point releases as often as needed.
- No flames and trollfests, some basic code of conduct is enforced.
What’s so bad regarding the old API?
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.
To expand a bit on that you can break down the issues with the old API in three groups:
- Unnamespaced common names (e.g.
CODEC_ID_NONE), those may or might not clash with other libraries.
- Now-internal-only fields previously exposed that were expected to be something that are not really are (e.g.
- Functionality not really working well (e.g. the old audio resampler) for which a replacement got provided eventually (
The worst result of API misuse could be a crash in specific situations (e.g. if you use the
AVCodecContext dimension when you should use the
AVFrame dimensions to allocate your screen surface you get quite an ugly crash since the former represent the decoding time dimension while the latter the dimensions of the frame you are going to present and they can vary a LOT).
But Compatibility ?!
In Libav we try our best to give migration paths and in the past years we even went over the extra mile by providing patches for quite a bit of software Debian was distributing at the time. (Since nobody even thanked for the effort, I doubt the people involved would do that again…)
Keeping backwards compatibility forever is not really feasible:
- You do want to remove a clashing symbol from your API
- You do want to not have application crashing because of wrong assumptions
- You do want people to use the new API and not keep compatibility wrappers that might not work in certain
The current consensus is to try to keep an API deprecated for about 2 major releases, with release 12 we are dropping code that had been deprecated since 2-3 years ago.
I had been busy with my dayjob deadlines so I couldn’t progress on the new api for avformat and avcodec I described before, probably the next blogpost will be longer and a bit more technical again.