Hi
On Sat, Jun 03, 2006 at 10:00:02AM +0300, Ivan Kalvachev
wrote:
> 2006/6/1, Michael Niedermayer <michaelni 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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
http://lists.mplayerhq.hu/cgi-bin/mailman/listinfo/n
ut-devel
|