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....
Hi On Sat, Jun 03, 2006 at 04:07:12PM +0300, Ivan Kalvachev wrote: [...]
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' "
you can google fourccs
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
yes, do you belive that this range will be insufficient in the future? i dont think so
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;)
yes, noone proposed that so its not relevant ...
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.
people will use their selfinvented codec names anyway if nut becomes popular, no matter if we have a list, if their codec is in the list or anything, this happened with avi (see (ms)mpeg4 stuff) it will happen again, hell IIRC even for things like mpeg-ps there are several codec ids for many formats (ac3 and such i think)
3.3. Even now the avi4cc is causing problems. Same format occupies many 4cc.
true, but not related to 4cc vs. variable length
Same 4cc are used for different codecs. Worse, in time
i dont think so
codecs will try to use any available combination that even may not have anything in common with codec name. "Unknown fourcc 'JQWZ' "
and with variable length idiots will use md5 or M$ GUID as id ...
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).
slightly better is still better, not that i agree that its just slightly
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.
you convert from nut to mp4/mov/avi you have to convert variable len to 4cc
5.1. We cannot know what 4cc the player knows.
neither can we know which variable length id it knows ...
5.2. We are going to use our own nut4cc codes.
not really
We even started making a list.
if a codec has a commonly used sane fourcc that should be used
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.
sorry i cant make sense of what you write ...
5.3. Burdening the demuxer with code matching tables is counter effective. These tables should be updated on regular basis....
yes thats why the variable length system is bad it will need more tables, then reusing 4ccs dont you agree? [...] -- 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
Before continuing flame, I would like to know if we are going to use fourcc, will we create our own list or just use the avi one?
"Ivan Kalvachev" <ikalvachev@gmail.com> writes:
Before continuing flame, I would like to know if we are going to use fourcc, will we create our own list or just use the avi one?
I believe the idea was to use a reduced avi 4cc list, that is with only one code per codec. On a side note, I still think there is way to much fixation on the 4cc thing in the first place, but that's probably just me... -- Måns Rullgård mru@inprovide.com
On Sat, Jun 03, 2006 at 08:16:03PM +0100, Måns Rullgård wrote:
"Ivan Kalvachev" <ikalvachev@gmail.com> writes:
Before continuing flame, I would like to know if we are going to use fourcc, will we create our own list or just use the avi one?
I believe the idea was to use a reduced avi 4cc list, that is with only one code per codec.
On a side note, I still think there is way to much fixation on the 4cc thing in the first place, but that's probably just me...
Resuming bikeshed topic. Warning, no replies within 7 days is taken as no complaints. - ods15
Hi On Fri, Jun 16, 2006 at 05:41:54AM +0300, Oded Shimon wrote:
On Sat, Jun 03, 2006 at 08:16:03PM +0100, Måns Rullgård wrote:
"Ivan Kalvachev" <ikalvachev@gmail.com> writes:
Before continuing flame, I would like to know if we are going to use fourcc, will we create our own list or just use the avi one?
I believe the idea was to use a reduced avi 4cc list, that is with only one code per codec.
On a side note, I still think there is way to much fixation on the 4cc thing in the first place, but that's probably just me...
Resuming bikeshed topic. Warning, no replies within 7 days is taken as no complaints.
alternative suggestion: fourcc identification for the codec MUST be <=4 bytes long SHOULD be made of alphanumerical chars the exact values are outside of the scope this spec if a codec specifies a prefered identifer which fits within the constraints of this syntax element then it SHOULD be used, if a codec is commonly using a identifer which fits within the constraints of this syntax element in another container format then that identifer SHOULD be used if there are several possible values to choose from then the one used in the source file if any SHOULD be prefered, if there are still several options left then the one with the most descriptive name SHOULD be preferred [...] -- 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
Michael Niedermayer wrote:
alternative suggestion: s/alternative/integrative
I'd add it before the list (that could be used as example) once it's revised accordingly. Once 64bit system will be common I'd move the limit to 8 bytes... lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Fri, Jun 16, 2006 at 04:12:50PM +0200, Luca Barbato wrote:
Michael Niedermayer wrote:
alternative suggestion: s/alternative/integrative
I'd add it before the list (that could be used as example) once it's revised accordingly.
Once 64bit system will be common I'd move the limit to 8 bytes...
I would not unless it has any practical benefits. We're not running out of unique human-readable 4-byte names anytime soon.. Rich
2006/6/16, Michael Niedermayer <michaelni@gmx.at>:
Hi
On Fri, Jun 16, 2006 at 05:41:54AM +0300, Oded Shimon wrote:
On Sat, Jun 03, 2006 at 08:16:03PM +0100, Måns Rullgård wrote:
"Ivan Kalvachev" <ikalvachev@gmail.com> writes:
Before continuing flame, I would like to know if we are going to use fourcc, will we create our own list or just use the avi one?
I believe the idea was to use a reduced avi 4cc list, that is with only one code per codec.
On a side note, I still think there is way to much fixation on the 4cc thing in the first place, but that's probably just me...
Resuming bikeshed topic. Warning, no replies within 7 days is taken as no complaints.
alternative suggestion:
fourcc identification for the codec MUST be <=4 bytes long SHOULD be made of alphanumerical chars the exact values are outside of the scope this spec if a codec specifies a prefered identifer which fits within the constraints of this syntax element then it SHOULD be used, if a codec is commonly using a identifer which fits within the constraints of this syntax element in another container format then that identifer SHOULD be used if there are several possible values to choose from then the one used in the source file if any SHOULD be prefered, if there are still several options left then the one with the most descriptive name SHOULD be preferred
I would accept anything that doesn't cripple the container artificially. This meaning that as long as fourcc is vb not byte[4] I'll accept it. You'd better make fourcc of all audio formats/codecs that are supported by mplayer (codecs.conf). I'll soon make another attempt to explain why strind_id are better... The previous got into flames too early. Oded, please don't use the bikeshred word. It implies that the thing is not really important.
On Fri, Jun 16, 2006 at 03:45:09PM +0200, Michael Niedermayer wrote:
Hi
On Fri, Jun 16, 2006 at 05:41:54AM +0300, Oded Shimon wrote:
On Sat, Jun 03, 2006 at 08:16:03PM +0100, Måns Rullgård wrote:
"Ivan Kalvachev" <ikalvachev@gmail.com> writes:
Before continuing flame, I would like to know if we are going to use fourcc, will we create our own list or just use the avi one?
I believe the idea was to use a reduced avi 4cc list, that is with only one code per codec.
On a side note, I still think there is way to much fixation on the 4cc thing in the first place, but that's probably just me...
Resuming bikeshed topic. Warning, no replies within 7 days is taken as no complaints.
alternative suggestion:
fourcc identification for the codec MUST be <=4 bytes long
Since we seem to be padding with spaces, I would s/<=/=/.
SHOULD be made of alphanumerical chars
s/alphanumeric/printable ascii/ (dash, plus, etc. are ok)
if there are several possible values to choose from then the one used in the source file if any SHOULD be prefered, if there are still several options left then the one with the most descriptive name SHOULD be preferred
I don't like this. The idea of "source file" does not belong in the spec, and source files are full of disgusting nonsense fourcc's like "DIVX" anyway. Rich
Here is my second attempt to prove why string_id is better. (read my question in "Freeze NUT" thread" First codec_id-s have been numbers. (e.g. mpeg-ps, wav and audio in avi). It saves space (and i doubt there are 256 different standard formats even now). However there is one problem, you need main authority that assignees codes. This means that you cannot just take a number and use it for your own codec, because it may collide with somebody else codec. Now, why FourCC are so much better? It is because it allows using codes that have some meaning, this way decreasing the possibility of 2 different entitles creating same code. 4 char are usually long enough for most acronyms. Why string id are better? Simply we don't have to use acronyms at all, just whole names. It avoids possibility of naming different things with same name. It prevents calling same thing with different names. (unless doing it intentionally). It is impossible to give technical reasons for using string_id, because for the computer program it doesn't really matter. It is the meaning that human put into these codes that makes the difference. And I think having UNAMBIGUOUS codec naming is more important than any implementation details. (and it is good looking too;) I'm proposing scheme in another mail.
participants (6)
-
Ivan Kalvachev -
Luca Barbato -
Michael Niedermayer -
Måns Rullgård -
Oded Shimon -
Rich Felker