2006/6/3, Michael Niedermayer <michaelni@gmx.at>:
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
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....