[NUT-devel] Freeze NUT

[Michael Niedermayer]

Hi

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


> 
> 
> P.S.
> Please don't try to change things in thread with name "freeze".. its
> just the opposite.

start a new thread if you like ...

[...]

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