[NUT-devel] Fourcc spec

[Rich Felker]

On Fri, Nov 17, 2006 at 01:57:35PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Nov 17, 2006 at 10:33:20AM +0100, Baptiste Coudurier wrote:
> > Hi
> > 
> > Oded Shimon wrote:
> > > This specification is normative to demuxers, informative to muxers. It 
> > > does not need to be actively maintained, because it does NOT list all 
> > > legal fourcc's, only the ones noted by the specification. I'd like to 
> > > commit it to nut/docs/fourcc.txt .
> > > 
> > > - ods15
> > > 
> > > Demuxers which support the codec listed MUST support the fourcc listed
> > > here.
> > > Muxers SHOULD use the fourcc listed here for codecs.
> > > 
> > > Video:
> > > "mp4s"        MPEG-4 Part 2
> > 
> > NO PLEASE ! "mp4v"
> > mp4s is used in mov/mp4/3gp to specify data/subs/whatever.
> >
> > > "h263"        H.263
> > > "h264"        MPEG-4 Part 10/H.264
> > > "snow"        Snow
> > > "drac"        Dirac/Schroedinger
> > > "vc1 "        VC-1
> > > 
> > > Audio:
> > > "vrbs"        Xiph.org Vorbis
> > > "mp2 "        MP2
> > > "mp3 "        MP3
> > > "ac3 "        AC3
> > > "aac "        AAC/MPEG-4 Part 3
> > > "eac3"        EAC3
> > > "flac"        Free Lossless Audio Codec
> > > "wavp"        WavPack
> > > 
> > 
> > Ok but please do not put them in riff.c ;)
> 
> no, and add a syntax element to the stream headers which says which
> type of codec id is used avi style or nut style (or qt style) hmm
> i do think you can copy and paste the text from matroska that will
> save some time
> 
> if this gets accepted we have surpassed avi and mov in brokenness
> several seperate codec id systems

I don't follow. There is no "several different codec id systems"
proposed here. This is intended as a normative list of names. For
video the established, sane, implementation-independent fourcc should
be used. What a spec like Oded has proposed should be interpreted as
meaning is:

1. If you're making a NUT player and it supports one of the codecs
   listed here, it MUST accept the codec_id listed if it accepts any
   codec_id at all.

2. If you're writing a NUT file using a common codec listed here, then
   you had better use the listed codec_id or there's no reason to
   expect that any conformant NUT player will be able to play it.

3. If the codec was not popular/not listed before, you might have
   previously used another codec_id for it for whatever reason, e.g.
   because two parties independently were the first to put the codec
   in a container and didn't know what the other was using. There's no
   reason to forbid players from accepting this alternate codec_id
   (since a multi-format player will already have other names in its
   tables anyway, and since such files may be useful). But such
   codec_id values should be considered as deprecated.

Again there is absolutely no "multiple systems" concept being
proposed. The intended use of avi-like fourcc has always stemmed from
the (correct!) assumption that any multi-format player will already
have a large table of four-byte codec identifiers that can be unified
across the vast majority of container formats (since they don't use
conflicting identifiers). IMO it's much like the MIME or iconv charset
identifier situation, where popular iconv implementations support:

1. preferred MIME name
2. any alternate/legacy MIME names
3. various other legacy names

even though the intent is that new applications and data should use
only the preferred MIME name.

Rich