2006/6/3, Michael Niedermayer <michaelni(a)gmx.at>:
> Hi
>
> On Sat, Jun 03, 2006 at 10:00:02AM +0300, Ivan Kalvachev wrote:
> > 2006/6/1, Michael Niedermayer <michaelni(a)gmx.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....
