[FFmpeg-devel] [PATCH] LucasArts-SMUSH playback

[Clément Bœsch]

On Mon, May 07, 2012 at 09:17:22AM +0000, Paul B Mahol wrote:
[...]
> >>+++ b/libavcodec/avcodec.h
> >>@@ -257,6 +257,7 @@ enum CodecID {
> >>     CODEC_ID_CDXL,
> >>     CODEC_ID_XBM,
> >>     CODEC_ID_ZEROCODEC,
> >>+    CODEC_ID_SANM,
> >>     CODEC_ID_Y41P       = MKBETAG('Y','4','1','P'),
> >>     CODEC_ID_ESCAPE130  = MKBETAG('E','1','3','0'),
> >>     CODEC_ID_EXR        = MKBETAG('0','E','X','R'),
> >
> >
> > this list is in order to keep backwards compatable with api.
> > you have to follow these rules, at the top of the enum in avcodec.h:
> >
> >  * If you add a codec ID to this list, add it so that
> >  * 1. no value of a existing codec ID changes (that would break ABI),
> >  * 2. Give it a value which when taken as ASCII is recognized uniquely
> > by a human as this specific codec.
> >  *    This ensures that 2 forks can independently add CodecIDs without
> > producing conflicts.
> 
> Not really. Nothing stops libav to add codec with same number as
> already one available in ffmpeg.

We should assume they won't, because it is likely they will not want to
clutter their purified code base with an explicit codec id to keep
compatibility with an evil fork. They are the upstream after all, they
decide.

Sarcasm aside, I'd be happy if some compatibility cooperation occurs at
some point. But unfortunately it's not likely to happen soon. Feel free to
prove me wrong anytime :)

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120507/0a51addd/attachment.asc>