[NUT-devel] Freeze NUT, Flame FourCC

[Michael Niedermayer]

Hi

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