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