[NUT-devel] Freeze NUT, Flame FourCC

Michael Niedermayer michaelni at gmx.at
Sat Jun 3 15:44:53 CEST 2006


On Sat, Jun 03, 2006 at 04:07:12PM +0300, Ivan Kalvachev wrote:
> >1. store as 32bit or store as variable length but limit to 32bit in the 
> >spec
> >    fits in int
> >    "only" 1<<32 codecs
> >    if the codec/source/destination stream doesnt support a 32bit id then
> >        we must convert
> >
> >2. store arbitrary length
> >    needs malloc()/free()/memcmp(), wont fit in int
> >    unlimited number of codecs
> >    if the codec/destination stream doesnt support variable length id then
> >        we must convert
> >
> >there are further possibilities like storing both or requireing the first 4
> >letters to uniquely identify the codec but these seem to be silly somehow 
> >...
> >
> >theres no doubt that 2. is much more complex, so i vote for 1. if you
> >dissagree id like to hear _technical_ arguments (not hackish, var size is
> >better then fixed philosophy with no explanation why this applies here)
> I'll try.
> 1. We don't need limit on the codecs that could be used with nut.
> 2. It is generally good idea the codec_id to have some human
> understandable and google-able meaning, like codec name. e.g. "Unknown
> format 'vorbis' "

you can google fourccs

> 3. We won't use the full range of 32bit. This means we have more like
> 26^4 (or 36^4 or 40^4). We are also colliding with AVI FourCC

yes, do you belive that this range will be insufficient in the future?
i dont think so

> 3.1 Using full range means something like 0x0001->mpeg1,
> 0x0002->mpeg2. It would be entirely cryptic if player reports "Unknown
> fourcc 0xFAC0" (hum... i've seen this somewhere;)

yes, noone proposed that so its not relevant ...

> 3.2. We could cause mass confusion with defining our own 4cc. If
> somebody can't find his codec in our list, he will just use the same
> 4cc as in avi. Then they will start using avi4cc even for formats that
> we have different codecs. The real fun would come when/if same 4cc is
> used for different codecs in the different containers.

people will use their selfinvented codec names anyway if nut becomes
popular, no matter if we have a list, if their codec is in the list
or anything, this happened with avi (see (ms)mpeg4 stuff) it will
happen again, hell IIRC even for things like mpeg-ps
there are several codec ids for many formats (ac3 and such i think)

> 3.3. Even now the avi4cc is causing problems. Same format occupies
> many 4cc. 

true, but not related to 4cc vs. variable length

> Same 4cc are used for different codecs. Worse, in time

i dont think so

> codecs will try to use any available combination that even may not
> have anything in common with codec name. "Unknown fourcc 'JQWZ' "

and with variable length idiots will use md5 or M$ GUID as id ...

> 4. malloc/free memcpy/memcmp is not really an issue. It is not time
> critical, nor it allocates megabytes of memory. Comparing speed isn't
> issue here, as it is done only once. (not even talking about realloc
> or stream_header raw buffer hacks).

slightly better is still better, not that i agree that its just slightly

> 5.
> >    if the codec/destination stream doesnt support variable length id then
> >        we must convert
> I'm really having problem understanding that.
> I'll assume you mean that if player doesn't know the codec_id string
> we will have to convert to 4cc it knows.
> Well this logic is totally flawed.

you convert from nut to mp4/mov/avi you have to convert variable len to 4cc

> 5.1. We cannot know what 4cc the player knows.

neither can we know which variable length id it knows ...

> 5.2. We are going to use our own nut4cc codes.

not really

> We even started making
> a list. 

if a codec has a commonly used sane fourcc that should be used

> If player doesn't know our codec_id then it won't know and our
> nut4cc. Making nut4cc->avi4cc totally beats the reason of having
> nut4cc.

sorry i cant make sense of what you write ...

> 5.3. Burdening the demuxer with code matching tables is counter
> effective. These tables should be updated on regular basis....

yes thats why the variable length system is bad it will need more
tables, then reusing 4ccs dont you agree?

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

More information about the NUT-devel mailing list