[NUT-devel] Fourcc spec

[Michael Niedermayer]

Hi

On Fri, Nov 17, 2006 at 11:01:45AM -0500, Rich Felker wrote:
> 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). 

you can unify such a table for demuxing/decoding but if we accpet odeds
first proposal then we need 2 lists for muxing as mp4s/mp4v, mp3 and so
on are not good choices for avi, while they would be the best choice for
nut -> you end up with 2 tables / 2 systems 
first look in the nut table if nothing is found look in the riff table
for muxing, same for demuxing

this also breaks my idea of simply exporting fourcc-codec_id as an array
in AVCodec, as for nut the thing suddenly would be 2 tables ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is