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 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
On Thu, Jun 01, 2006 at 06:37:10PM +0300, Oded Shimon wrote: 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