[NUT-devel] Fourcc spec

[Michael Niedermayer]

Hi

On Sat, Nov 18, 2006 at 02:13:37PM -0500, Rich Felker wrote:
[...]
> > > This seems to be what we
> > > agreed upon all along.. 
> > 
> > yes probably, i cant remember all the details of the fourcc flames :)
> > 
> > 
> > > I don't see what's changed by Oded writing
> > > this document; can you explain?
> > 
> > it changes what is currently written in the spec ...
> 
> how so? all it does is add a requirement that a compliant player

spec say use riff avi fourcc, the proposed tags arent really riff avi tags
...

[...]
> > if the user has to manually select fourccs for codecs not in the nut 
> > table then it will cause an incredible mess as everyone will
> > choose a different fourccs
> 
> are you sure? yes maybe this is a bad idea; it was just a random
> suggestion.

yes i think its a bad idea, there should be some sort of protection
either something like a "X-" prefix, though X- itself probably is a 
bad choice if we limit it to 4 chars total ...
or there should be a default suggested fourcc like whatever is in the
riff table (that could be with a -strict -1 like parameter being required)


> 
> > it practically means nuts codec id is seperate and we have
> > to add an entry for every codec, and with your deep sense for sanity,
> > no seriously i agree that the fourccs you and oded select are more sane
> > then whats in avi but it will cause nut and avi to use very different
> > fourccs, and that ends the common codec id or common table, i mean
> > how much of the table matches avi? none of the audio tags, mp4v no
> > h263 no match at fourcc.org, ...
> 
> yet they're already in the fourcc table of mplayer and any other
> player that uses a common table, presumably.
> 
> as for audio, what's used in quicktime? can we adopt that without
> introducing stupidity?

does the following look stupid to you?
    { CODEC_ID_PCM_S16BE, MKTAG('t', 'w', 'o', 's') },
    { CODEC_ID_PCM_S16LE, MKTAG('s', 'o', 'w', 't') },
    { CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') },
    { CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') },
    { CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') },
    { CODEC_ID_PCM_S32LE, MKTAG('i', 'n', '3', '2') },


> 
> > so at that point i really think we should rethink about what we want
> > to do, if we make our own table then so be it if not then AVI should
> > be used and only avi,
> 
> imo it's no problem to derive from the union of all 32bit alphanumeric
> codec id tables.
> 
> > if we dislike something then it
> > should be added to the avi table thats just IMHO ... avi doesnt have
> > any "you may not add your sane fourcc rule" ...
> 
> agree, we should ignore the flames by måns and baptiste and add the
> sane names to the riff/avi tables, and encourage their use in avi as
> well... :)
> 
> alternatively we could make a bitfield for each fourcc to flag that
> it's illegal in certain formats, with the default being legal in all
> formats. but this is an implementation issue, not an issue of nut
> design.
> 
> > OTOH maybe simply making our own table would be simpler (not technically
> > but in the flameability sense) we start with whats on fourcc.org and
> > you and oded change what you dont like (iam fine with anything no matter
> > if its dx50 for mpeg4 or mp4v or fmp4, iam not fine mp4s as thats not
> > standard compliant mpeg4 AFAIK but MS shit)
> 
> iirc mp4s was supposed to mean standards-compliant, as opposed to
> mpg4, mp42, mp43, etc. which were ms crap. however i think it got
> bastardized somewhere along the time and quicktime uses it for
> something else. so i agree a different name should be chosen. i'm

mp4s is AFAIK some early attempt of MS to write a ISO-mpeg4 codec, i think
its based on some early draft, after that they tried again with M4S2
which is AFAIK mpeg4 simple profile if we would use it, it probably
couldnt be played on windows (if stored in AVI) as microsofts simple 
profile decoder would not be able to decode advanced simple profile, 
just guessing though


> strongly opposed to any of the implementation-specific names though.
> as soon as you go down that path, you wind up with the trouble of
> players omitting support for certain implementations and then
> implementations must lie that they're actually a different
> implementation...

ok, i really dont mind how the codec tag issue is solved, as long as
it is
so lets checkin the sane fourcc table from oded and use that with a
fallback to the avi-riff tags for muxing and demuxing?


[...]
-- 
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