we were on the verge of finishing nut entirely when this whole flamewar started and i'd like to see it end. while i agree with ivan's sentiment that we do not want the huge mess of random nonsensical fourcc's creeping into nut, i'm also quite confident that ivan's proposal will not solve the problems he claims it will. as long as a "new style" codec id is required (and if it's not required it's useless and stupid like matroska's dual system) then whenever users want to use a codec that's not in the official list they'll just copy a random fourcc or other string to use as the codec identifier. on the other hand, the disadvantages of making a new codec id system are significant. most importantly, it requires every player that wants to support nut to either switch to using the new codec id system (nut-centric) and map all old fourcc's from other containers to the new system, or to map all nut codec ids to fourccs. both of these procedures require pointless large conversion tables. while the fourcc situation historically is ugly, the proposal i've been mostly agreeing with (i don't call it mine because iirc it was put together from the ideas of many people) seems the best to remedy the situation. like all legitimate standardization processes in which the party making the standard is providing rules whose influence extend outside their scope, our process for standardizing codec ids should: 1. abstract common characteristics of historical implementations 2. eliminate characteristics which are vendor-specific and/or provide duplicate or ambiguous functionality 3. only as a last resort, fill in new definitions where steps 1 and 2 have left any gaps. in our case, this means looking at existing fourcc values and other fourcc-compatible codec identifiers used in avi, quicktime, nsv, etc. and choosing among them the ones which are sane (human-readable and vendor-neutral). this resulted in a list like "mp4v", "mp3 ", "h264", "mpg1", ... the benefit of using existing fourcc's is significant because any multi-format player can lookup a working decoder for a stream with its existing fourcc->decoder tables rather than requiring a whole new set of tables. while designing a new codec id system could be useful, it is beyond the scope of a container format simply because of big-O considerations. if each universal (any-codec) container has its own nonsense codec id system, then the size of the tables grows as O(num_containers*num_codecs) instead of just O(num_codecs). i do not object at all to commenting in the nut spec that, in the event of a new future codec id standard that's well-designed, a future nut version may support using the new id system instead of fourcc. however, making a new codec id system and getting all containers to adopt it is WAAAY to ambitious of a project right now and WAAAAY outside the scope of what nut is trying to do. as for ivan's concern that lamers will just use crap fourccs (like DIVX, XVID, X264, ...) instead of the correct/standardized ones, there are lots of other things lamers can do too, and nutlint and/or the reference demuxer should warn about or discourage their stupidity. actually i would like to see a list of "illegal fourccs" in the reference muxer so it knows all the classic vendor-specific/ambiguous fourccs and rejects them as permenantly invalid. this would be a fairly small table, just 4 bytes per fourcc. other ideas welcome, but i really hope we can put this issue aside asap and get on with release.. rich
Rich Felker <dalias@aerifal.cx> writes:
on the other hand, the disadvantages of making a new codec id system are significant. most importantly, it requires every player that wants to support nut to either switch to using the new codec id system (nut-centric) and map all old fourcc's from other containers to the new system, or to map all nut codec ids to fourccs. both of these procedures require pointless large conversion tables.
There is *nothing* universal about so-called fourccs. They just happen to be used by AVI, and AVI is unfortunately the most wide-spread format. Quicktime also uses 32-bit codes, but they are *different* from those used in AVI for many codecs. It is most obvious for audio, where quicktime uses four printable chars, as for video, while AVI uses a 16-bit number. Any player capable of playing more than one file format will need tables to convert from whatever the input files use to something internal, whether or not the internal codes are equal to those used by one format or another.
while the fourcc situation historically is ugly, the proposal i've been mostly agreeing with (i don't call it mine because iirc it was put together from the ideas of many people) seems the best to remedy the situation. like all legitimate standardization processes in which the party making the standard is providing rules whose influence extend outside their scope, our process for standardizing codec ids should:
1. abstract common characteristics of historical implementations
2. eliminate characteristics which are vendor-specific and/or provide duplicate or ambiguous functionality
3. only as a last resort, fill in new definitions where steps 1 and 2 have left any gaps.
in our case, this means looking at existing fourcc values and other fourcc-compatible codec identifiers used in avi, quicktime, nsv, etc. and choosing among them the ones which are sane (human-readable and vendor-neutral). this resulted in a list like "mp4v", "mp3 ", "h264", "mpg1", ...
the benefit of using existing fourcc's is significant because any multi-format player can lookup a working decoder for a stream with its existing fourcc->decoder tables rather than requiring a whole new set of tables. while designing a new codec id system could be useful, it is beyond the scope of a container format simply because of big-O considerations. if each universal (any-codec) container has its own nonsense codec id system, then the size of the tables grows as O(num_containers*num_codecs) instead of just O(num_codecs).
That is *already* the case.
i do not object at all to commenting in the nut spec that, in the event of a new future codec id standard that's well-designed, a future nut version may support using the new id system instead of fourcc.
To that end, it makes sense making the field syntactically variable-sized. If a player wants to treat 4-byte identifiers as a number, it may do so now. If a later standard uses longer identifiers, such players will have to change, but they will need updating anyway if the codec identifications change. -- Måns Rullgård mru@inprovide.com
On Tue, Jun 20, 2006 at 08:22:03PM +0100, Måns Rullgård wrote:
Rich Felker <dalias@aerifal.cx> writes:
on the other hand, the disadvantages of making a new codec id system are significant. most importantly, it requires every player that wants to support nut to either switch to using the new codec id system (nut-centric) and map all old fourcc's from other containers to the new system, or to map all nut codec ids to fourccs. both of these procedures require pointless large conversion tables.
There is *nothing* universal about so-called fourccs. They just happen to be used by AVI, and AVI is unfortunately the most wide-spread format. Quicktime also uses 32-bit codes, but they are *different* from those used in AVI for many codecs. It is most obvious for audio, where quicktime uses four printable chars, as for video, while AVI uses a 16-bit number.
Any player capable of playing more than one file format will need tables to convert from whatever the input files use to something internal, whether or not the internal codes are equal to those used by one format or another.
This is incorrect. The quicktime, avi, and other id numbers do not overlap, so no table of conversions is needed. All that's needed is a list of 32bit ids mapping to decoders, and this list can be shared among all formats. If you had bothered to read the earlier threads this was already addressed.
the benefit of using existing fourcc's is significant because any multi-format player can lookup a working decoder for a stream with its existing fourcc->decoder tables rather than requiring a whole new set of tables. while designing a new codec id system could be useful, it is beyond the scope of a container format simply because of big-O considerations. if each universal (any-codec) container has its own nonsense codec id system, then the size of the tables grows as O(num_containers*num_codecs) instead of just O(num_codecs).
That is *already* the case.
No it's not.
i do not object at all to commenting in the nut spec that, in the event of a new future codec id standard that's well-designed, a future nut version may support using the new id system instead of fourcc.
To that end, it makes sense making the field syntactically variable-sized.
Absolutely everything in NUT is syntactically variable-sized, except the index pointer at EOF which would just be difficult to parse if it were. The question is not of syntax and never has been. The question is semantics.
If a player wants to treat 4-byte identifiers as a number, it may do so now. If a later standard uses longer identifiers, such players will have to change, but they will need updating anyway if the codec identifications change.
Yes, with the added stipulations that, currently, identifiers are required (semantically, not syntactically) to be 4-byte, and that existing identifiers are reused whenever possible to avoid senselessly bloating up the table or clashing with existing table entries from other container formats. Rich
Rich Felker wrote: [postpone discussion later, just complete version 1 now, fourcc is the simplest solution.] Ok, looks sane that way, BUT [O(), tables, complexity, nobody will use our codecs] No, having a codec table for nut isn't any different than what we have already (see ogg, qt/mov, avi, mkv). So I'd like to have what iive proposed for the next nut revision and that means that the fourcc field should be changed now as codec_id and it should stay vb. The next revision will add the options about encoder/producer and so on. I know that doesn't sound fine, but - somebody will bitch about complexity and bloat while it doesn't matter at all and a month is needed to convince them to move from their position (from past experience) - avi fourcc and mov aren't that nice about tags as the proposed long term solution. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Tue, Jun 20, 2006 at 10:10:30PM +0200, Luca Barbato wrote:
Rich Felker wrote: [postpone discussion later, just complete version 1 now, fourcc is the simplest solution.]
Ok, looks sane that way, BUT
[O(), tables, complexity, nobody will use our codecs]
No, having a codec table for nut isn't any different than what we have already (see ogg, qt/mov, avi, mkv).
Yes it is. The only formats that need their own special tables right now are the ones with small restricted sets of codecs and new specs for each additional codec they support, i.e. ogg and mkv. Everything else uses a common list of fourcc-compatible identifiers.
So I'd like to have what iive proposed for the next nut revision and that means that the fourcc field should be changed now as codec_id and it should stay vb.
Of course all fields will stay variable-length even if the semantic requirements demand a specific size. This has NEVER been questioned.
The next revision will add the options about encoder/producer and so on.
This useless info can go in the info packet.
I know that doesn't sound fine, but
- somebody will bitch about complexity and bloat while it doesn't matter at all and a month is needed to convince them to move from their position (from past experience)
More than that.
- avi fourcc and mov aren't that nice about tags as the proposed long term solution.
Yes they are. The more small/restricted the set of identifiers is, the less likely people are to make stupid "equivalent" names. Consider for example iso language codes versus ogg language crap. "eng" is very simple and standard and no one will make variants on it. "English" could easily become "english", "eng", "English(US)", "English with some foreign words", "ENGLISH", "eNgLiSh", etc. Rich
2006/6/20, Rich Felker <dalias@aerifal.cx>:
we were on the verge of finishing nut entirely when this whole flamewar started and i'd like to see it end. while i agree with ivan's sentiment that we do not want the huge mess of random nonsensical fourcc's creeping into nut, i'm also quite confident that ivan's proposal will not solve the problems he claims it will. as long as a "new style" codec id is required (and if it's not required it's useless and stupid like matroska's dual system) then whenever users want to use a codec that's not in the official list they'll just copy a random fourcc or other string to use as the codec identifier.
It's not user job to create format_id, it is codec maintainer person. Users changing fourcc is part of the problem.
on the other hand, the disadvantages of making a new codec id system are significant. most importantly, it requires every player that wants to support nut to either switch to using the new codec id system (nut-centric) and map all old fourcc's from other containers to the new system, or to map all nut codec ids to fourccs. both of these procedures require pointless large conversion tables.
I don't have problem with world domination. I'm sick of this mythical table nonsense. There is ALWAYS a table. It could be distributed - each codec/module/demuxer knows fourcc it can play and how to map them (ffmpeg?) It could be centralized - one table that contains all codecs. It is like codecs.conf in mplayer that atm is 56k big in source (text) form. This is the biggest known table mapping of all possible fourcc to all possible codecs. (it's 14kb gzip-ed). A player that support more than one format - avi ,wmv, mov/qt. mkv does need some kind of table for interoperability, adding few new entries is not huge issue. Should I remind you that current proposal is mixture of avi and qt ? This means that if player supports only one of these we still need special mapping table, no matter how compatible codecs we've chosen. So tables are unavoidable. And even doubling the size of the biggest know would not make more than 32kb....
while the fourcc situation historically is ugly, the proposal i've been mostly agreeing with (i don't call it mine because iirc it was put together from the ideas of many people) seems the best to remedy the situation. like all legitimate standardization processes in which the party making the standard is providing rules whose influence extend outside their scope, our process for standardizing codec ids should:
1. abstract common characteristics of historical implementations
2. eliminate characteristics which are vendor-specific and/or provide duplicate or ambiguous functionality
3. only as a last resort, fill in new definitions where steps 1 and 2 have left any gaps.
in our case, this means looking at existing fourcc values and other fourcc-compatible codec identifiers used in avi, quicktime, nsv, etc. and choosing among them the ones which are sane (human-readable and vendor-neutral). this resulted in a list like "mp4v", "mp3 ", "h264", "mpg1", ...
I'm happy we haven't created nut using this method.
the benefit of using existing fourcc's is significant because any multi-format player can lookup a working decoder for a stream with its existing fourcc->decoder tables rather than requiring a whole new set of tables. while designing a new codec id system could be useful, it is beyond the scope of a container format simply because of big-O considerations. if each universal (any-codec) container has its own nonsense codec id system, then the size of the tables grows as O(num_containers*num_codecs) instead of just O(num_codecs).
i do not object at all to commenting in the nut spec that, in the event of a new future codec id standard that's well-designed, a future nut version may support using the new id system instead of fourcc. however, making a new codec id system and getting all containers to adopt it is WAAAY to ambitious of a project right now and WAAAAY outside the scope of what nut is trying to do.
Why don't you give it a shot? A new codec_id standard cannot come out of thin air, somebody must invent it, implement it and use it. Nut have the potential to make a difference. If you had put at least half of the effort you made for backward_ptr in developing new format_id system, NUT would have been compleated already.
as for ivan's concern that lamers will just use crap fourccs (like DIVX, XVID, X264, ...) instead of the correct/standardized ones, there are lots of other things lamers can do too, and nutlint and/or the reference demuxer should warn about or discourage their stupidity. actually i would like to see a list of "illegal fourccs" in the reference muxer so it knows all the classic vendor-specific/ambiguous fourccs and rejects them as permenantly invalid. this would be a fairly small table, just 4 bytes per fourcc.
((2^32) - number_of_legetime_fourcc)*4
other ideas welcome, but i really hope we can put this issue aside asap and get on with release..
I know one thing. If I neglect something, it will come to bite me at later point. NUT is well polished format. Every aspect have been flamed, hammered, tuned and tempered. I don't want to neglect the probably most important at user point of view aspect because you are hurrying for the release.
Ivan Kalvachev wrote:
NUT is well polished format. Every aspect have been flamed, hammered, tuned and tempered. I don't want to neglect the probably most important at user point of view aspect because you are hurrying for the release.
Do you have the time to add a little proof of concept using libnut and mplayer? Sticking to the current situation could help finding issues. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Tue, Jun 20, 2006 at 11:28:36PM +0300, Ivan Kalvachev wrote:
i do not object at all to commenting in the nut spec that, in the event of a new future codec id standard that's well-designed, a future nut version may support using the new id system instead of fourcc. however, making a new codec id system and getting all containers to adopt it is WAAAY to ambitious of a project right now and WAAAAY outside the scope of what nut is trying to do.
Why don't you give it a shot?
Because it has no benefits. None of the problem of current container formats is due to fourcc. It's due to missing or incorrect data about the stored frames, inefficiency, lack of robustness, etc.
If you had put at least half of the effort you made for backward_ptr in developing new format_id system, NUT would have been compleated already.
As far as I'm concerned NUT is completed already.
NUT is well polished format. Every aspect have been flamed, hammered, tuned and tempered. I don't want to neglect the probably most important at user point of view aspect because you are hurrying for the release.
This is not an important point. Anyway... here let's use a new codec id system. In the new system all names will be exactly 4 characters, and here are the first 6 entries: mp4v - mpeg4 video aac - aac audio mp3 - mp3 audio mp2 - mp2 audio h264 - h264 video vrbs - voris audio Any correspondence to historically used names from fourcc or qt identifier is purely coincidental. :))) Rich
Hi,
This is not an important point. Anyway... here let's use a new codec id system. In the new system all names will be exactly 4 characters, and here are the first 6 entries:
mp4v - mpeg4 video aac - aac audio mp3 - mp3 audio mp2 - mp2 audio
What about mp2a / mp3a? So mp2v could exist (and not mpg2). Otoh aaca would look crazy :) Also I would restrict the available character set from your proposed ascii-printable to alphanumeric+space, everything else is making it more complicated. The dash (-) is the only symbol I could be convienced if too much ppl cry. -- Alex Beregszaszi email: alex@fsn.hu Free Software Network cell: +36 70 3144424
On Tue, Jun 20, 2006 at 11:39:41PM +0200, Alex Beregszaszi wrote:
Hi,
This is not an important point. Anyway... here let's use a new codec id system. In the new system all names will be exactly 4 characters, and here are the first 6 entries:
mp4v - mpeg4 video aac - aac audio mp3 - mp3 audio mp2 - mp2 audio
What about mp2a / mp3a? So mp2v could exist (and not mpg2). Otoh aaca would look crazy :)
The idea was to use existing sane names when they exist to avoid pointlessly enlarging tables. Also mp2a and mp3a are NOT analogous to mp4v. mp2 does not mean mpeg-2 audio. It means mpeg-1 audio, layer 2. Similarly for mp3.
Also I would restrict the available character set from your proposed ascii-printable to alphanumeric+space, everything else is making it more complicated. The dash (-) is the only symbol I could be convienced if too much ppl cry.
Plus is also useful, e.g. 263+, mp3+, etc. crap. :) Rich
Hi,
What about mp2a / mp3a? So mp2v could exist (and not mpg2). Otoh aaca would look crazy :)
The idea was to use existing sane names when they exist to avoid pointlessly enlarging tables. Also mp2a and mp3a are NOT analogous to mp4v. mp2 does not mean mpeg-2 audio. It means mpeg-1 audio, layer 2. Similarly for mp3.
What about mpl1, mpl2 and mpl3 then? :) Also how would you store MPEG2? mpg2? mp2v? mp4v are ES or PR packets?
Also I would restrict the available character set from your proposed ascii-printable to alphanumeric+space, everything else is making it more complicated. The dash (-) is the only symbol I could be convienced if too much ppl cry.
Plus is also useful, e.g. 263+, mp3+, etc. crap. :)
My proposal character set: * english alphabet - lower case only! * numbers 0-9 * space * minus sign / dash * plus sign -- Alex Beregszaszi email: alex@fsn.hu Free Software Network cell: +36 70 3144424
Hi On Wed, Jun 21, 2006 at 12:05:26AM +0200, Alex Beregszaszi wrote:
Hi,
What about mp2a / mp3a? So mp2v could exist (and not mpg2). Otoh aaca would look crazy :)
The idea was to use existing sane names when they exist to avoid pointlessly enlarging tables. Also mp2a and mp3a are NOT analogous to mp4v. mp2 does not mean mpeg-2 audio. It means mpeg-1 audio, layer 2. Similarly for mp3.
What about mpl1, mpl2 and mpl3 then? :) Also how would you store MPEG2? mpg2? mp2v?
mp4v are ES or PR packets?
PR? you mean PS? of course not PS, double layer muxing is not allowed in nut
Also I would restrict the available character set from your proposed ascii-printable to alphanumeric+space, everything else is making it more complicated. The dash (-) is the only symbol I could be convienced if too much ppl cry.
Plus is also useful, e.g. 263+, mp3+, etc. crap. :)
My proposal character set: * english alphabet - lower case only! * numbers 0-9 * space * minus sign / dash * plus sign
i agree if we need a allowed charset then the above is plenty, actually i would say 'p' is fine and + isnt really needed [...] -- 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
Hi,
mp4v are ES or PR packets?
PR? you mean PS? of course not PS, double layer muxing is not allowed in nut
A typo only.
i agree if we need a allowed charset then the above is plenty, actually i would say 'p' is fine and + isnt really needed
Me too, but Rich likes the fancy plus/minus signs. -- Alex Beregszaszi | alex@fsn.hu | +36 70 3144424
participants (6)
-
Alex Beregszaszi -
Ivan Kalvachev -
Luca Barbato -
Michael Niedermayer -
Måns Rullgård -
Rich Felker