[FFmpeg-trac] #2575(avcodec:new): Change of AV_CODEC_ID_SNOW renumbered other AVCodec_ID enum values

[FFmpeg]

#2575: Change of AV_CODEC_ID_SNOW renumbered other AVCodec_ID enum values
------------------------------------+-----------------------------------
             Reporter:  wolenetz    |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  avcodec
              Version:  git-master  |               Resolution:
             Keywords:              |               Blocked By:
             Blocking:              |  Reproduced by developer:  1
Analyzed by developer:  0           |
------------------------------------+-----------------------------------
Changes (by michael):

 * reproduced:  0 => 1


Comment:

 Replying to [ticket:2575 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.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2575#comment:1>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker