Freeze NUT, Flame FourCC

2006/6/3, Michael Niedermayer <michaelnigmx.at>:
> Hi
>
> On Sat, Jun 03, 2006 at 10:00:02AM +0300, Ivan
Kalvachev wrote:
> > 2006/6/1, Michael Niedermayer <michaelnigmx.at>:
> > >Hi
> > >
> > >On Thu, Jun 01, 2006 at 06:37:10PM +0300, Oded
Shimon wrote:
> > >> On Thu, Jun 01, 2006 at 05:13:34PM +0200,
Luca Barbato wrote:
> > >> > Michael Niedermayer wrote:
> > >> > >
> > >> > > some random ideas (dunno if
good or not)
> > >> > > allow multiple codec
identifers:
> > >> > > source fourcc (what the source
in case of remuxing had)
> > >> > > long name
("Vorbis", "ITU H.264", ...)
> > >> > > simplifed fourcc
(XVID,DIVX,FFMP4->M4V; ...)
> > >> > > and make one of these mandatory
and put the other 2 in an info
> > >packet maybe

I would really like if we work in this direction.
I think I even proposed something like this in the previous
thread.

> > >> > could be useful in certain case, how
much complex it could become?
> > >>
> > >> ... i don't like it
> > >> I say go back to 4 byte method, and
explicitly say to the spec it must be
> > >> 4 bytes, and even remove the 'length'
field...
> > >
> > >i am not against a 32bit fixed field ...
> >
> > I am against.
> >
> > If we are going to use 32bit fields. If we are
going to use this for
> > compatibility.
> > Then I say to use the AVI fourcc and don't mind
to make our own
> > incompatible with everything fourcc table.
> >
> > However I really would NOT like to criple nut in
such horribly ugly hackish
> > way.
> > Especally when everything else in nut is variable
size...
>
> well almost everything might be variable size but these
things also ensure
> that values stay small if possible
(width/height/sample_rate/...) fit in
> 32bit for videos todays players support, (stream_id,
...) must be a small
> number, having a 2 stream file with 1 stream with id
1<<99 isnt allowed
>
> now with fourcc/codec_id its different, its not that
>32bit can be used if
> we run out of 32bit values while we wouldnt need to
bother today but that
> it must be supported no matter if we ever run out of
32bit values ...
>
> so there are several choices:
> 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' "

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
(avi4cc).

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;)

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.

3.3. Even now the avi4cc is causing problems. Same format
occupies
many 4cc. Same 4cc are used for different codecs. Worse, in
time
codecs will try to use any available combination that even
may not
have anything in common with codec name. "Unknown
fourcc 'JQWZ' "

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).

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.

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

5.2. We are going to use our own nut4cc codes. We even
started making
a list. 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.

5.3. Burdening the demuxer with code matching tables is
counter
effective. These tables should be updated on regular
basis....
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
http://lists.mplayerhq.hu/cgi-bin/mailman/listinfo/n
ut-devel

Freeze NUT, Flame FourCC

Thread: Freeze NUT, Flame FourCC