Last patch left is this fourcc thing, which I can't commit yet due to no cvs/svn... In the meanwhile, asking if anyone has objections on freezing? - ods15
Oded Shimon wrote:
Last patch left is this fourcc thing, which I can't commit yet due to no cvs/svn... In the meanwhile, asking if anyone has objections on freezing?
Looks ok, in the mean time we could continue with fourcc.txt adding the codecs we expect to work on shortly like: 4, "snow" Snow 4, "flac" Flac 4, "shro" Dirac/Schroedinger 4, "VC-1" VC-1 4, "EAC3" EAC3 lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Hi,
Looks ok, in the mean time we could continue with fourcc.txt adding the codecs we expect to work on shortly
like:
4, "snow" Snow
4, "flac" Flac
4, "shro" Dirac/Schroedinger
why not drac?
4, "VC-1" VC-1
4, "EAC3" EAC3
never try mixing cases! take lower case for all imho. also using a dash is a good idea? -- Alex Beregszaszi email: alex@fsn.hu Free Software Network cell: +36 70 3144424
On Sat, May 27, 2006 at 01:46:32PM +0200, Luca Barbato wrote:
Alex Beregszaszi wrote:
4, "shro" Dirac/Schroedinger
why not drac?
the first 4 letter that came to my mind.
'drac' sounds much more sensible
4, "VC-1" VC-1
4, "EAC3" EAC3
s/VC-1/vc1 / s/EAC/eac/
so, "eac3" ? - od15
On Sat, May 27, 2006 at 02:30:49PM +0300, Oded Shimon wrote:
On Sat, May 27, 2006 at 01:46:32PM +0200, Luca Barbato wrote:
Alex Beregszaszi wrote:
4, "shro" Dirac/Schroedinger
why not drac?
the first 4 letter that came to my mind.
'drac' sounds much more sensible
4, "VC-1" VC-1
4, "EAC3" EAC3
s/VC-1/vc1 / s/EAC/eac/
so, "eac3" ?
BTW, whats EAC3?... (as opposed to AC3? cause we have entries for both...) Nag no. 2. Be warned, when SVN comes up I'll commit both these patches. (unless someone complains now..) - ods15
Oded Shimon wrote:
+Appendix, Fourcc Spec +===================== +length,string + +Video +4,"h263" H.263 +4,"mp4v" MPEG-4 Part 2 +4,"h264" MPEG-4 Part 10/H.264 +4,"snow" Snow
+4,"flac" Flac
Flac is lossless audio add also WavPack fourcc wv Yet another lossless/hybrid codec that is slightly better than flac lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Thursday 01 June 2006 12:07, Oded Shimon wrote:
Nag no. 2. Be warned, when SVN comes up I'll commit both these patches. (unless someone complains now..)
I re-read the previous discussion on fourcc's and I don't want to restart it or anything if the main nut devs agree on sticking to four bytes, but what is the reason for not using a wider field? I agree that all sorts of implementation specific names should be avoided, but I always found fourcc's rather limited. Examples are 'drac' and 'vrbs' where 'dirac' and 'vorbis' are a lot clearer. Plus: +4,"mp2 " MP3 +4,"mp3 " MP2 :-) Also: + identification for the codec, must comply to fourcc.txt I would write "MUST comply" to emphasize that non-complying strings should be rejected by the muxer. --Ivo
On Thu, Jun 01, 2006 at 01:13:09PM +0200, Ivo wrote:
On Thursday 01 June 2006 12:07, Oded Shimon wrote:
Nag no. 2. Be warned, when SVN comes up I'll commit both these patches. (unless someone complains now..)
I re-read the previous discussion on fourcc's and I don't want to restart it or anything if the main nut devs agree on sticking to four bytes, but what is the reason for not using a wider field? I agree that all sorts of implementation specific names should be avoided, but I always found fourcc's rather limited. Examples are 'drac' and 'vrbs' where 'dirac' and 'vorbis' are a lot clearer.
I actually considered it after sending this mail, I think the only advantage of 4-char fourcc is saying explictly in the spec all fourcc must be 4 bytes (even ommit the 'length' field for it). If we decide we don't want that, then IMO you are right and we should use more sane/readable names like 'vorbis' and 'dirac'. (But not stuff like "ISO/ITU 14496-3" which is even less readable)
Plus:
+4,"mp2 " MP3 +4,"mp3 " MP2
:-)
Also:
+ identification for the codec, must comply to fourcc.txt
I would write "MUST comply" to emphasize that non-complying strings should be rejected by the muxer.
Both fixed in local patch. - ods15
Oded Shimon wrote:
I actually considered it after sending this mail, I think the only advantage of 4-char fourcc is saying explictly in the spec all fourcc must be 4 bytes (even ommit the 'length' field for it). If we decide we don't want that, then IMO you are right and we should use more sane/readable names like 'vorbis' and 'dirac'. (But not stuff like "ISO/ITU 14496-3" which is even less readable)
I like "vorbis" and "dirac" too. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Luca Barbato said:
Oded Shimon wrote:
I actually considered it after sending this mail, I think the only advantage of 4-char fourcc is saying explictly in the spec all fourcc must be 4 bytes (even ommit the 'length' field for it). If we decide we don't want that, then IMO you are right and we should use more sane/readable names like 'vorbis' and 'dirac'. (But not stuff like "ISO/ITU 14496-3" which is even less readable)
I like "vorbis" and "dirac" too.
I'll second that as well. -- Måns Rullgård mru@inprovide.com
On Thu, Jun 01, 2006 at 01:46:46PM +0100, Måns Rullgård wrote:
Luca Barbato said:
Oded Shimon wrote:
I actually considered it after sending this mail, I think the only advantage of 4-char fourcc is saying explictly in the spec all fourcc must be 4 bytes (even ommit the 'length' field for it). If we decide we don't want that, then IMO you are right and we should use more sane/readable names like 'vorbis' and 'dirac'. (But not stuff like "ISO/ITU 14496-3" which is even less readable)
I like "vorbis" and "dirac" too.
I'll second that as well.
OK then. New rough draft, please correct me in cases where I am blantantly false/stupid:
+4,"h263" H.263 5,"h.263" +4,"mp4v" MPEG-4 Part 2 6,"mpeg-4" +4,"h264" MPEG-4 Part 10/H.264 5,"h.264" +4,"snow" Snow 4,"snow" +4,"drac" Dirac/Schroedinger 6,"dirac" +4,"vc1 " VC-1 4,"vc-1"
+Audio +4,"vrbs" Xiph.org Vorbis 6,"vorbis" +4,"mp2 " MP2 3,"mp2" +4,"mp3 " MP3 3,"mp3" +4,"ac3 " AC3 3,"ac3" +4,"aac " AAC/MPEG-4 Part 3 3,"aac" +4,"eac3" EAC3 4,"eac3" +4,"flac" Flac 4,"flac"
in conclusion: 5,"h.263" 6,"mpeg-4" 5,"h.264" 4,"snow" 6,"dirac" 4,"vc-1" 6,"vorbis" 3,"mp2" 3,"mp3" 3,"ac3" 3,"aac" 4,"eac3" 4,"flac" - ods15
On Thu, Jun 01, 2006 at 01:46:46PM +0100, Måns Rullgård wrote:
Luca Barbato said:
Oded Shimon wrote:
I actually considered it after sending this mail, I think the only advantage of 4-char fourcc is saying explictly in the spec all fourcc must be 4 bytes (even ommit the 'length' field for it). If we decide we don't want that, then IMO you are right and we should use more sane/readable names like 'vorbis' and 'dirac'. (But not stuff like "ISO/ITU 14496-3" which is even less readable)
I like "vorbis" and "dirac" too.
I'll second that as well.
Opposed. The only reasons for using something "fourcc"-like at all are 1) compatibility and 2) fits in 32bit int so easy to compare/pass in apis. If we're willing to abandon that we should do something more ambitious, but IMO it's a pain to abandon that and not useful. As someone (? :) said, the best standards processes codify existing practice when it's sane rather than inventing new things unnecessarily. If you look in the earlier fourcc threads, the goal in choosing some of the names is that they match the "most sane" fourcc already found in other file formats. Rich
Hi On Thu, Jun 01, 2006 at 10:06:24AM -0400, Rich Felker wrote:
On Thu, Jun 01, 2006 at 01:46:46PM +0100, Måns Rullgård wrote:
Luca Barbato said:
Oded Shimon wrote:
I actually considered it after sending this mail, I think the only advantage of 4-char fourcc is saying explictly in the spec all fourcc must be 4 bytes (even ommit the 'length' field for it). If we decide we don't want that, then IMO you are right and we should use more sane/readable names like 'vorbis' and 'dirac'. (But not stuff like "ISO/ITU 14496-3" which is even less readable)
I like "vorbis" and "dirac" too.
I'll second that as well.
Opposed. The only reasons for using something "fourcc"-like at all are
i second your opposal also things like "h.264" where proposed, while thats neither exactly what the standard is called ("H.264") nor whats used anywhere else AFAIK: (h264,avc) another thing which hasnt been mentioned? is that the fourcc is in some cases used to detect needed bug workarounds, iam not sure if thats important enough for us to care about ... then theres the remuxing thingy foobar->nut->foobar 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 [...] -- 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:
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? lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
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... - ods15
Oded Shimon wrote:
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...
hm, using the string to int is a BAD hack and could be quite enjoyable if you have the right endianess... how many time you have to do this comparison? lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Thu, Jun 01, 2006 at 06:19:32PM +0200, Luca Barbato wrote:
Oded Shimon wrote:
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...
hm, using the string to int is a BAD hack and could be quite enjoyable if you have the right endianess...
how many time you have to do this comparison?
Doesn't really have anything to do with the int hack, just code complexity. int fourcc_len; char * fourcc; where fourcc is malloced is much annoying/harder to handle than simply char fourcc[4]; If we decide we are only going to use 4 bytes, then I can use the latter for implementation, and to prevent a redundant sanity check seeing that the fourcc is indeed 4 bytes, the length can be remove from the file. - ods15
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 ... [...] -- 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
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... P.S. Please don't try to change things in thread with name "freeze".. its just the opposite.
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:
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.
I'm against too. Could we stick to strings please? lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
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
Michael Niedermayer wrote:
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
so 0x1 mp3 0x2 mpeg4 0x3 theora 0x4 vorbis 0x5 pick one as you wish You'll have to convert, you need to have the codec table handy when manually inspecting a file, first come first served applies, you need to parse this information once at load so having simple int compare or multiple byte compare doesn't mean much. You may suggest to keep the code to the least number of bytes and within a certain limit (8,16?). "vorbis" "theora" "dirac" "mp3" "mpeg4" "h264" etc etc etc looks too insane? lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Hi On Sat, Jun 03, 2006 at 02:44:01PM +0200, Luca Barbato wrote:
Michael Niedermayer wrote:
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
so
0x1 mp3 0x2 mpeg4 0x3 theora 0x4 vorbis 0x5 pick one as you wish
You'll have to convert, you need to have the codec table handy when
no, 32bit fourcc is used since ages and it didnt need such mess until you just invented it here to support your suggestion, normal fourcc/32bit: mp3 mp3 m4v mpeg4 theo theora vrbs vorbis ... variable vs 32bit length is completely independant from intentionally choosing silly codec names, the variable length system can also be made to look bad by giving each a random number as name [...] -- 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
2006/6/3, Michael Niedermayer <michaelni@gmx.at>:
Hi
On Sat, Jun 03, 2006 at 02:44:01PM +0200, Luca Barbato wrote:
Michael Niedermayer wrote:
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
so
0x1 mp3 0x2 mpeg4 0x3 theora 0x4 vorbis 0x5 pick one as you wish
You'll have to convert, you need to have the codec table handy when
no, 32bit fourcc is used since ages and it didnt need such mess until you just invented it here to support your suggestion,
Why is it mess? Why do you think that FourCharacterCodes are better than using 32bit integer?
participants (8)
-
Alex Beregszaszi -
Ivan Kalvachev -
Ivo -
Luca Barbato -
Michael Niedermayer -
Måns Rullgård -
Oded Shimon -
Rich Felker