Change of AV_CODEC_ID_SNOW renumbered other AVCodec_ID enum values

[Matt Wolenetz]

Summary of the bug:

In commit feccf2f6, AV_CODEC_ID_SNOW was moved in enum AVCodecID to be a MKBETAG value. Values for subsequent IDs such as AV_CODEC_ID_TSCC changed. This violates the rule:
"1. no value of a existing codec ID changes (that would break ABI)", and impacts users of FFmpeg such as Chromium that have some dependency on this rule.

How to reproduce:

% git diff 5b802cf567a0ee7a2990e08d08f8aa0abffbb7d2 -- libavcodec/avcodec.h
...
@@ -154,7 +156,6 @@ enum AVCodecID {
     AV_CODEC_ID_MSZH,
     AV_CODEC_ID_ZLIB,
     AV_CODEC_ID_QTRLE,
-    AV_CODEC_ID_SNOW,
     AV_CODEC_ID_TSCC,
     AV_CODEC_ID_ULTI,
     AV_CODEC_ID_QDRAW,
...

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[Michael Niedermayer]

Replying to wolenetz:

In commit feccf2f6, AV_CODEC_ID_SNOW was moved in enum AVCodecID to be a MKBETAG value. Values for subsequent IDs such as AV_CODEC_ID_TSCC changed. This violates the rule:
"1. no value of a existing codec ID changes (that would break ABI)", and impacts users of FFmpeg such as Chromium that have some dependency on this rule.

The soname and major version of libavcodec was changed a few days prior to this change. And there where other changes that required this soname/major bump.
Users of libraries should not expect binary compatibility over major version changes.

Yes we could have left the codec ids unchanged and i would have preferred that but it would have broken compatibility with the FFmpeg fork (libav) which did remove the snow codec id from the middle of the list.
If everyone would be working together instead of being split between ffmpeg and libav then such things would not happen at least not so often. Iam sure a combined project would not have removed snow in the first place.
What can i do except saying that all libav developers are welcome in ffmpeg. Some people simply prefer to be hostile and fight instead of cooperating. And trying to stay compatible then leads to this kind of issues. Ignoring compatibility with libav OTOH would surely not make our users happy either as some would then have to support 2 different APIs.