Hi On Fri, Nov 17, 2006 at 10:33:20AM +0100, Baptiste Coudurier wrote:

Hi

Oded Shimon wrote:

...

This specification is normative to demuxers, informative to muxers. It does not need to be actively maintained, because it does NOT list all legal fourcc's, only the ones noted by the specification. I'd like to commit it to nut/docs/fourcc.txt .

- ods15

Demuxers which support the codec listed MUST support the fourcc listed here. Muxers SHOULD use the fourcc listed here for codecs.

Video: "mp4s" MPEG-4 Part 2

NO PLEASE ! "mp4v" mp4s is used in mov/mp4/3gp to specify data/subs/whatever.

...

"h263" H.263 "h264" MPEG-4 Part 10/H.264 "snow" Snow "drac" Dirac/Schroedinger "vc1 " VC-1

Audio: "vrbs" Xiph.org Vorbis "mp2 " MP2 "mp3 " MP3 "ac3 " AC3 "aac " AAC/MPEG-4 Part 3 "eac3" EAC3 "flac" Free Lossless Audio Codec "wavp" WavPack

Ok but please do not put them in riff.c ;)

no, and add a syntax element to the stream headers which says which type of codec id is used avi style or nut style (or qt style) hmm i do think you can copy and paste the text from matroska that will save some time if this gets accepted we have surpassed avi and mov in brokenness several seperate codec id systems [...] -- 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

On Fri, Nov 17, 2006 at 02:04:48PM +0100, Baptiste Coudurier wrote:

Why doesn't nut use twocc like in avi ? it's the most spread format. And it will avoid duplicating tables.

Unlike fourcc, they're not sane, in that: - they're not actually unique. conflicting ones have already been assigned by idiots. - non-uniqueness stems from having too small of a namespace for numerous parties to be able to individually assign ids and from the lack of any logical (e.g. human-language) correspondence between the numbers and the codecs. - how the hell is an ungoverned community supposed to arrive at consensus on a meaningless number? Quicktime and other formats already have fourcc for audio so it's best to just pull from there. Then the fourcc's can be shared just like with video. Rich

Oded Shimon wrote:

...

...

...

[...]

Ok but please do not put them in riff.c ;) no, and add a syntax element to the stream headers which says which type of codec id is used avi style or nut style (or qt style) hmm i do think you can copy and paste the text from matroska that will save some time

if this gets accepted we have surpassed avi and mov in brokenness several seperate codec id systems

I really really don't care what the actual values are, for all I care they can be this list below, which AFAIK are all AVI values (except "vrbs"). The point is to have some kind of fourcc spec which is normative for demuxers, and informative for muxers. As we saw the confusion of me and you not knowing what fourcc should be used for mp3 in NUT...

Yes, priority to twocc values. Can a guideline be added like, use avi video fourcc if it does not collide to other containers, and twocc for audio if it exists ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312

On Fri, Nov 17, 2006 at 01:57:35PM +0100, Michael Niedermayer wrote:

Hi

On Fri, Nov 17, 2006 at 10:33:20AM +0100, Baptiste Coudurier wrote:

...

Hi

Oded Shimon wrote:

...

This specification is normative to demuxers, informative to muxers. It does not need to be actively maintained, because it does NOT list all legal fourcc's, only the ones noted by the specification. I'd like to commit it to nut/docs/fourcc.txt .

- ods15

Demuxers which support the codec listed MUST support the fourcc listed here. Muxers SHOULD use the fourcc listed here for codecs.

Video: "mp4s" MPEG-4 Part 2

NO PLEASE ! "mp4v" mp4s is used in mov/mp4/3gp to specify data/subs/whatever.

...

"h263" H.263 "h264" MPEG-4 Part 10/H.264 "snow" Snow "drac" Dirac/Schroedinger "vc1 " VC-1

Audio: "vrbs" Xiph.org Vorbis "mp2 " MP2 "mp3 " MP3 "ac3 " AC3 "aac " AAC/MPEG-4 Part 3 "eac3" EAC3 "flac" Free Lossless Audio Codec "wavp" WavPack

Ok but please do not put them in riff.c ;)

no, and add a syntax element to the stream headers which says which type of codec id is used avi style or nut style (or qt style) hmm i do think you can copy and paste the text from matroska that will save some time

if this gets accepted we have surpassed avi and mov in brokenness several seperate codec id systems

I don't follow. There is no "several different codec id systems" proposed here. This is intended as a normative list of names. For video the established, sane, implementation-independent fourcc should be used. What a spec like Oded has proposed should be interpreted as meaning is: 1. If you're making a NUT player and it supports one of the codecs listed here, it MUST accept the codec_id listed if it accepts any codec_id at all. 2. If you're writing a NUT file using a common codec listed here, then you had better use the listed codec_id or there's no reason to expect that any conformant NUT player will be able to play it. 3. If the codec was not popular/not listed before, you might have previously used another codec_id for it for whatever reason, e.g. because two parties independently were the first to put the codec in a container and didn't know what the other was using. There's no reason to forbid players from accepting this alternate codec_id (since a multi-format player will already have other names in its tables anyway, and since such files may be useful). But such codec_id values should be considered as deprecated. Again there is absolutely no "multiple systems" concept being proposed. The intended use of avi-like fourcc has always stemmed from the (correct!) assumption that any multi-format player will already have a large table of four-byte codec identifiers that can be unified across the vast majority of container formats (since they don't use conflicting identifiers). IMO it's much like the MIME or iconv charset identifier situation, where popular iconv implementations support: 1. preferred MIME name 2. any alternate/legacy MIME names 3. various other legacy names even though the intent is that new applications and data should use only the preferred MIME name. Rich

On Fri, Nov 17, 2006 at 06:42:19PM +0100, Michael Niedermayer wrote:

...

...

if this gets accepted we have surpassed avi and mov in brokenness several seperate codec id systems

I don't follow. There is no "several different codec id systems" proposed here. This is intended as a normative list of names. For video the established, sane, implementation-independent fourcc should be used. What a spec like Oded has proposed should be interpreted as meaning is:

1. If you're making a NUT player and it supports one of the codecs listed here, it MUST accept the codec_id listed if it accepts any codec_id at all.

2. If you're writing a NUT file using a common codec listed here, then you had better use the listed codec_id or there's no reason to expect that any conformant NUT player will be able to play it.

3. If the codec was not popular/not listed before, you might have previously used another codec_id for it for whatever reason, e.g. because two parties independently were the first to put the codec in a container and didn't know what the other was using. There's no reason to forbid players from accepting this alternate codec_id (since a multi-format player will already have other names in its tables anyway, and since such files may be useful). But such codec_id values should be considered as deprecated.

Again there is absolutely no "multiple systems" concept being proposed. The intended use of avi-like fourcc has always stemmed from the (correct!) assumption that any multi-format player will already have a large table of four-byte codec identifiers that can be unified across the vast majority of container formats (since they don't use conflicting identifiers).

you can unify such a table for demuxing/decoding but if we accpet odeds first proposal then we need 2 lists for muxing as mp4s/mp4v, mp3 and so on are not good choices for avi, while they would be the best choice for nut -> you end up with 2 tables / 2 systems

Yes but this will always be the case unless you propose using "DX50" for mpeg4 video... Certainly "DX50" is the preferred fourcc for avi since many shitty settop players only support 'divx'... If you don't care about them then the preferred fourcc would probably be "FMP4" or "XVID", which are equally nonsensical for NUT. IMO the point of Oded's and my design is to avoid the "broken monopoly-enforcing settop player" problem by making the mandated codec_id an implementation-neutral one. This seems to be what we agreed upon all along.. I don't see what's changed by Oded writing this document; can you explain?

first look in the nut table if nothing is found look in the riff table for muxing, same for demuxing

IMO the best is probably for the user to manually select the fourcc for NUT muxing when it's not one of the standardized codecs. But I don't really mind if you prefer something different.

this also breaks my idea of simply exporting fourcc-codec_id as an array in AVCodec, as for nut the thing suddenly would be 2 tables ...

??? I don't follow. No one ever said muxing could be done with a unified table. Still, a next-gen media app might support playing all formats but writing only NUT, in which case a single table would be fine. Obviously a library like libavformat will have to go through some trouble to ensure that the correct/preferred codec_id for each container is used... There's no way around this without dropping support for legacy formats. Rich

On Sat, Nov 18, 2006 at 01:43:33AM +0100, Michael Niedermayer wrote:

On Fri, Nov 17, 2006 at 01:36:59PM -0500, Rich Felker wrote:

...

On Fri, Nov 17, 2006 at 06:42:19PM +0100, Michael Niedermayer wrote:

...

first look in the nut table if nothing is found look in the riff table for muxing, same for demuxing

IMO the best is probably for the user to manually select the fourcc for NUT muxing when it's not one of the standardized codecs. But I don't really mind if you prefer something different.

...

this also breaks my idea of simply exporting fourcc-codec_id as an array in AVCodec, as for nut the thing suddenly would be 2 tables ...

??? I don't follow. No one ever said muxing could be done with a unified table. Still, a next-gen media app might support playing all formats but writing only NUT, in which case a single table would be fine. Obviously a library like libavformat will have to go through some trouble to ensure that the correct/preferred codec_id for each container is used... There's no way around this without dropping support for legacy formats.

well, before all the idiocity from mans and co, we simply added a fourcc to riff.c (avidec or enc or whatever it was back then) and that format could be muxed and demuxed in avi and every other format using the riff table, my idea was that nut would use that and only that table, sure it was my idea and not yours or odeds, but all the table split madness leaves me already with a longer todo list,

Personally I don't see this as a big issue. I already started making an (extremely minimal) table in lavf/libnut.c - and it should be a very easy table to maintain as it is defined by spec in fourcc.txt . It adds about 1 or 2 lines of code in checking this table first before checking the riff table. I'd hate to join mans's side of the flaming ;) - But I fail to see the big advantage of using a single, large table in riff.c for several almost obviously incompatible formats.

[..] it practically means nuts codec id is seperate and we have to add an entry for every codec, and with your deep sense for sanity, no seriously i agree that the fourccs you and oded select are more sane then whats in avi but it will cause nut and avi to use very different fourccs, and that ends the common codec id or common table, i mean how much of the table matches avi? none of the audio tags, mp4v no h263 no match at fourcc.org, ...

When I sent my second proposal, I meant to use 'DX50' or 'XVID' or 'FMP4', but I couldn't decide which to use which wouldn't make us look like idiots... (With 'FMP4' we sound elitist, forcing our codec tag to our container, and with any other we just sound stupid...) What would the correct one be for 'h263' btw? It's what I found in mplayer etc/codecs.conf ... - ods15

On Sat, Nov 18, 2006 at 12:45:35PM +0000, Måns Rullgård wrote:

Oded Shimon <ods15@ods15.dyndns.org> writes:

...

What would the correct one be for 'h263' btw? It's what I found in mplayer etc/codecs.conf ...

FWIW, H263 (uppercase) is in the official Microsoft AVI list.

"MP3 " (uppercase) is already in the MPlayer list because of NSV or something. IMO there's no reason to force lowercase if the existing is uppercase. I'd almost suggest making it case-insensitive but that's probably stupid.. :) Rich

Hi On Sat, Nov 18, 2006 at 02:13:37PM -0500, Rich Felker wrote: [...]

...

...

This seems to be what we agreed upon all along..

yes probably, i cant remember all the details of the fourcc flames :)

...

I don't see what's changed by Oded writing this document; can you explain?

it changes what is currently written in the spec ...

how so? all it does is add a requirement that a compliant player

spec say use riff avi fourcc, the proposed tags arent really riff avi tags ... [...]

...

if the user has to manually select fourccs for codecs not in the nut table then it will cause an incredible mess as everyone will choose a different fourccs

are you sure? yes maybe this is a bad idea; it was just a random suggestion.

yes i think its a bad idea, there should be some sort of protection either something like a "X-" prefix, though X- itself probably is a bad choice if we limit it to 4 chars total ... or there should be a default suggested fourcc like whatever is in the riff table (that could be with a -strict -1 like parameter being required)

...

it practically means nuts codec id is seperate and we have to add an entry for every codec, and with your deep sense for sanity, no seriously i agree that the fourccs you and oded select are more sane then whats in avi but it will cause nut and avi to use very different fourccs, and that ends the common codec id or common table, i mean how much of the table matches avi? none of the audio tags, mp4v no h263 no match at fourcc.org, ...

yet they're already in the fourcc table of mplayer and any other player that uses a common table, presumably.

as for audio, what's used in quicktime? can we adopt that without introducing stupidity?

does the following look stupid to you? { CODEC_ID_PCM_S16BE, MKTAG('t', 'w', 'o', 's') }, { CODEC_ID_PCM_S16LE, MKTAG('s', 'o', 'w', 't') }, { CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') }, { CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') }, { CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') }, { CODEC_ID_PCM_S32LE, MKTAG('i', 'n', '3', '2') },

...

so at that point i really think we should rethink about what we want to do, if we make our own table then so be it if not then AVI should be used and only avi,

imo it's no problem to derive from the union of all 32bit alphanumeric codec id tables.

...

if we dislike something then it should be added to the avi table thats just IMHO ... avi doesnt have any "you may not add your sane fourcc rule" ...

agree, we should ignore the flames by måns and baptiste and add the sane names to the riff/avi tables, and encourage their use in avi as well... :)

alternatively we could make a bitfield for each fourcc to flag that it's illegal in certain formats, with the default being legal in all formats. but this is an implementation issue, not an issue of nut design.

...

OTOH maybe simply making our own table would be simpler (not technically but in the flameability sense) we start with whats on fourcc.org and you and oded change what you dont like (iam fine with anything no matter if its dx50 for mpeg4 or mp4v or fmp4, iam not fine mp4s as thats not standard compliant mpeg4 AFAIK but MS shit)

iirc mp4s was supposed to mean standards-compliant, as opposed to mpg4, mp42, mp43, etc. which were ms crap. however i think it got bastardized somewhere along the time and quicktime uses it for something else. so i agree a different name should be chosen. i'm

mp4s is AFAIK some early attempt of MS to write a ISO-mpeg4 codec, i think its based on some early draft, after that they tried again with M4S2 which is AFAIK mpeg4 simple profile if we would use it, it probably couldnt be played on windows (if stored in AVI) as microsofts simple profile decoder would not be able to decode advanced simple profile, just guessing though

strongly opposed to any of the implementation-specific names though. as soon as you go down that path, you wind up with the trouble of players omitting support for certain implementations and then implementations must lie that they're actually a different implementation...

ok, i really dont mind how the codec tag issue is solved, as long as it is so lets checkin the sane fourcc table from oded and use that with a fallback to the avi-riff tags for muxing and demuxing? [...] -- 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 On Tue, Nov 21, 2006 at 09:12:14AM +0200, Oded Shimon wrote:

On Sat, Nov 18, 2006 at 10:13:46PM +0100, Michael Niedermayer wrote:

...

On Sat, Nov 18, 2006 at 02:13:37PM -0500, Rich Felker wrote:

...

strongly opposed to any of the implementation-specific names though. as soon as you go down that path, you wind up with the trouble of players omitting support for certain implementations and then implementations must lie that they're actually a different implementation...

ok, i really dont mind how the codec tag issue is solved, as long as it is so lets checkin the sane fourcc table from oded and use that with a fallback to the avi-riff tags for muxing and demuxing?

So whats the decision? We commit this table?

i abstain from voting on this, if rich says ok or abstains too and you dont vote against your own table :) then commit it (after dealing with the nitpicking below) [...]

======================================================= NUT Open Container Format fourcc specification 20061117 =======================================================

Demuxers which support the codec listed MUST support the fourcc listed here. Muxers SHOULD use the fourcc listed here for codecs.

Video: "mp4v" MPEG-4 Part 2

may i suggest to add mp2v and mp1v ...

"h263" H.263 "h264" MPEG-4 Part 10/H.264

may i suggest to add h262 and h261 ...

"snow" Snow "drac" Dirac/Schroedinger "vc1 " VC-1

also hfyu (huffyuv), ffv1 and jpeg or mjpg should be added then rawvideo formats yv12,rgb32, ... also should be added and theora and jpeg2000 ...

Audio: "vrbs" Xiph.org Vorbis "mp2 " MP2 "mp3 " MP3 "ac3 " AC3 "aac " AAC/MPEG-4 Part 3 "eac3" EAC3

i dunno eac3 well enough, but is it more different from ac3 then h.263 is from h.263+ ? if not why does it get its own fourcc while h.263+ does not?

"flac" Free Lossless Audio Codec

"wavp" WavPack

to quote David Bryant <david@wavpack.com> ---- [commit to riff.c] I am the developer of WavPack, but I'm very new to ffmpeg and I don't really understand what this does. It is in a list of format ids for the wav container but WavPack in wav is not supported. Also, in the wav header those ids are only 16-bit so WVPK can't fit. I assume that this table means something else in the ffmpeg context, but I could not figure out what (especially since I did not see FLAC in there and I know that's supported). I haven't made it through all the docs yet (or built the code) but any light shed on this would be appreciated. As was mentioned, the signature for WavPack blocks is "wvpk", so that would be a fine choice by me for this (assuming it's not really a wav format_id). ----- and pcm*, alaw, ylaw, and some common adpcm variants should be added then theres gsm and ... [...] -- 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

On Tue, Nov 21, 2006 at 08:31:46PM +0200, Oded Shimon wrote:

Updated list below. Rich, waiting for your OK (or abstain) on this.

My inclination is to reject in its current form since there are plenty of gratuitous incompatibilities with RIFF (or other) fourccs in existing use. For instance existing usage for h.263 is H263, not h263, and similar for "MP3 " vs. "mp3 ". Rich

Hi On Fri, Dec 22, 2006 at 12:56:26PM +0200, Oded Shimon wrote:

Hi Time to kick a dead horse.... Or set it on fire or something.

On Sat, Nov 18, 2006 at 01:43:33AM +0100, Michael Niedermayer wrote:

...

well, before all the idiocity from mans and co, we simply added a fourcc to riff.c (avidec or enc or whatever it was back then) and that format could be muxed and demuxed in avi and every other format using the riff table, my idea was that nut would use that and only that table, sure it was my idea and not yours or odeds, but all the table split madness leaves me already with a longer todo list, or more specifically i now need to go through all codecs in lavc and add fourccs to riff.c for the ones which can be stored in avi as everyone who touches the table gets flamed by either mans or baptiste and nut seems to be on the way to double that work, if its table is split off sufficiently

I absoloutely understand your argument of not wanting to split the fourcc table you have currently for AVI and other containers. However, I also understand Mans' argument of the NUT spec having absoloutely no specification of fourcc's/codec_id's. Unfortunatly, the only solution I see that pleases the both of you is the silliest one - having "DX50" and "\x55\x00" as official NUT fourcc's. - This is actually the current situation, it is simply not explicitly official.

What solution do you propose for this? Ignore Mans' argument altogether and leave the situation as it is? In a very simple example I saw where his argument was useful - in my framecode generator for libnut based on codecs. I would actually have to maintain complete lists to pick the codec instead of a simple single test.

The general NUT habit so far was to ignore existing implementation limitations...

its easy to find arguments against any solution, but unless you compare 2 possible solutions this is meaningless question is not if solution X has a flaw, question is which solution has the fewest flaws the only way to avoid a list of fourccs per codec in a framecode generator is to convert all mpeg4 like codecs to a single fourcc, and similarly for other standard codecs, this first will break bug workarounds for some rare and old files if libavcodec is used as decoder, it will cause xvid and divx to be played by the same decoder on windows, is xvid capable to decode all divx? is divx capable to decode all xvid? divx definitly doesnt decode standard mpeg4 correctly, there are plenty of bugs B before I and such IIRC additionally any solution which doesnt need a fourcc list in the framecode generator needs it in the demuxer-muxer so i dont see how that simplifies anything? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus

On Sat, Dec 23, 2006 at 01:15:39PM +0200, Oded Shimon wrote:

OK, my best attempt:

Option 1: Keep the current situation: The spec explicitly says to use AVI fourcc's, is vague on what to do if there is no AVI fourcc. Pros: Use the same codec tables as AVI for both muxing and demuxing Keep fourcc's of old codecs for bug workarounds Cons: Several fourcc's per codec No defined fourcc's for codecs which are not contained in AVI No defined fourcc's for any codec really

Option 2: Make an explicit list, using only existing and popular fourcc's from AVI for codecs which exist in AVI, allowing several fourcc's per codec. (DX50, XVID, \x55\x00, ..) Pros: Use the same codec tables as AVI for both muxing and demuxing Keep fourcc's of old codecs for bug workarounds Defined fourcc's for all codecs Cons: Several fourcc's per codec "Looks silly" (I'm personally not really against this, but I bet Rich is...)

Option 3: Make an explicit list, similar to the list I originally proposed Pros: Defined fourcc's for all codecs Single fourcc per codec "Clean" in sane codec names Cons: Different tables for AVI and NUT (for muxing, demuxing can still use common table) Loss of bug workarounds

Summary: A - Defined explicit codecs forucc's B - bug workarounds ability C - single fourcc per codec D - Single table in implementation for muxer E - "Sane" codec names

Option A B C D E 1 X X (x) - since it is not explicit in spec, it doesn't matter as much 2 X X X 3 X X X

P.S. Since the lists are informative and not normative for muxers, they do not necessarily require constant updating and upkeep, so I did not consider this as an advantage or disadvantage. - ods15

On Sat, Dec 23, 2006 at 01:56:29PM +0100, Michael Niedermayer wrote:

On Sat, Dec 23, 2006 at 01:21:07PM +0200, Oded Shimon wrote:

...

On Sat, Dec 23, 2006 at 01:15:39PM +0200, Oded Shimon wrote:

...

OK, my best attempt:

Option 1: Keep the current situation: The spec explicitly says to use AVI fourcc's, is vague on what to do if there is no AVI fourcc. Pros: Use the same codec tables as AVI for both muxing and demuxing Keep fourcc's of old codecs for bug workarounds Cons: Several fourcc's per codec No defined fourcc's for codecs which are not contained in AVI No defined fourcc's for any codec really

Option 2: Make an explicit list, using only existing and popular fourcc's from AVI for codecs which exist in AVI, allowing several fourcc's per codec. (DX50, XVID, \x55\x00, ..) Pros: Use the same codec tables as AVI for both muxing and demuxing Keep fourcc's of old codecs for bug workarounds Defined fourcc's for all codecs Cons: Several fourcc's per codec "Looks silly" (I'm personally not really against this, but I bet Rich is...)

Option 3: Make an explicit list, similar to the list I originally proposed Pros: Defined fourcc's for all codecs Single fourcc per codec "Clean" in sane codec names Cons: Different tables for AVI and NUT (for muxing, demuxing can still use common table) Loss of bug workarounds

Summary: A - Defined explicit codecs forucc's B - bug workarounds ability C - single fourcc per codec D - Single table in implementation for muxer E - "Sane" codec names

Option A B C D E 1 X X (x) - since it is not explicit in spec, it doesn't matter as much 2 X X X 3 X X X

P.S. Since the lists are informative and not normative for muxers, they do not necessarily require constant updating and upkeep, so I did not consider this as an advantage or disadvantage.

if the lists are not normative that i bet every commercial company will use their own fourcc divx, 3ivx, ... why? 1. the company can better claim that its their own supperior technology 2. they dont need to bother to implement the standard correctly, its enough if their decoder matches their encoder, this is what has happened with codecs in avi and as its less work = less money it will happen again. It didnt happen with mpeg-ps/ts just because there are too many hw decoders around which cant be updated that easily all IMHO

if my hypothesis turns out to be true then 3. would loose the "single fourcc per codec" and ""Sane" codec names" as in practice the majority of videos would not use the recommanded fourccs

so that brings us to option 4 which would require a player to only support a codec if the one and only standard fourcc where used, if a unknown fourcc is used demuxing it would be a violation of the spec ...

if that would prevent the issue iam not sure though ...

The list IS normative for demuxers, not for muxers. This was already in my original proposal, I forgot to re-mention it here. I did not quite understand your hypothesis, so I am not sure if being normative for demuxers fixes what you said. Regardless, I'm leaning to 2. - ods15

Hi On Sat, Dec 23, 2006 at 03:26:42PM +0200, Oded Shimon wrote:

On Sat, Dec 23, 2006 at 03:09:24PM +0200, Oded Shimon wrote:

...

On Sat, Dec 23, 2006 at 01:56:29PM +0100, Michael Niedermayer wrote:

...

if the lists are not normative that i bet every commercial company will use their own fourcc divx, 3ivx, ... why? 1. the company can better claim that its their own supperior technology 2. they dont need to bother to implement the standard correctly, its enough if their decoder matches their encoder, this is what has happened with codecs in avi and as its less work = less money it will happen again. It didnt happen with mpeg-ps/ts just because there are too many hw decoders around which cant be updated that easily all IMHO

if my hypothesis turns out to be true then 3. would loose the "single fourcc per codec" and ""Sane" codec names" as in practice the majority of videos would not use the recommanded fourccs

so that brings us to option 4 which would require a player to only support a codec if the one and only standard fourcc where used, if a unknown fourcc is used demuxing it would be a violation of the spec ...

if that would prevent the issue iam not sure though ...

The list IS normative for demuxers, not for muxers. This was already in my original proposal, I forgot to re-mention it here.

To spell it out again:

A muxer SHOULD use the fourcc from the codec list A demuxer MUST support the fourcc from the codec list if it supports the codec at all

ive no problem with this its pure bikeshed after all

Which means demuxers can have additional fourcc's to the ones in the official list, and a muxer can do whatever it wants. But obviously, both are better off using the official list.

well a demuxer is better off if it uses a complete list with as many fourccs as possible and a muxer is normally best off if its files look best on as many players as possible, this may or may not achieved with the official fourcc, most of the time though the standard fourcc will be the best choice additionally there is the capitalistic scum which will always use their own fourcc as it gives them more control, lets them claim that their codec is not just standard mpeg4/h264 (keep in mind that their buisness model might not be to sell encoders/muxers but rather to sell decoders/demuxer in which case it is not in their interrest that the files can be played by as many other decoders/demuxers as possible ...) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle

On Sat, Dec 23, 2006 at 09:13:59PM +0000, M?ns Rullg?rd wrote:

Oded Shimon <ods15@ods15.dyndns.org> writes:

...

On Sat, Dec 23, 2006 at 03:09:24PM +0200, Oded Shimon wrote:

...

On Sat, Dec 23, 2006 at 01:56:29PM +0100, Michael Niedermayer wrote:

...

if the lists are not normative that i bet every commercial company will use their own fourcc divx, 3ivx, ... why? 1. the company can better claim that its their own supperior technology 2. they dont need to bother to implement the standard correctly, its enough if their decoder matches their encoder, this is what has happened with codecs in avi and as its less work = less money it will happen again. It didnt happen with mpeg-ps/ts just because there are too many hw decoders around which cant be updated that easily all IMHO

if my hypothesis turns out to be true then 3. would loose the "single fourcc per codec" and ""Sane" codec names" as in practice the majority of videos would not use the recommanded fourccs

so that brings us to option 4 which would require a player to only support a codec if the one and only standard fourcc where used, if a unknown fourcc is used demuxing it would be a violation of the spec ...

if that would prevent the issue iam not sure though ...

The list IS normative for demuxers, not for muxers. This was already in my original proposal, I forgot to re-mention it here.

To spell it out again:

A muxer SHOULD use the fourcc from the codec list A demuxer MUST support the fourcc from the codec list if it supports the codec at all

Which means demuxers can have additional fourcc's to the ones in the official list, and a muxer can do whatever it wants. But obviously, both are better off using the official list.

This makes no sense at all, but I think you already knew my opinion...

Actually, no, I'm confused by your reply... I was slightly off - the demuxer is better off using as many fourcc's as it wants, but it MUST include also the official list. The muxer, in most cases, is better off using only fourcc's from the official list, so it has garuntee of demuxers supporting it. I fail to see how this does not make sense. I don't know if you noticed, but I'm going through this entire thing only because of you, I personally do not care. So please, present your arguments. In the case of a company _intentionally_ not using an official fourcc, then I don't really care, because if they are doing it intentionally they will always do it regardless of what we ask. (Even if we say MPEG-4 ASP MUST have this fourcc, they can claim their codec is something else/superior and has another fourcc) - ods15

Hi On Sun, Dec 24, 2006 at 09:03:00AM +0000, Måns Rullgård wrote:

Oded Shimon <ods15@ods15.dyndns.org> writes:

...

On Sat, Dec 23, 2006 at 09:13:59PM +0000, M?ns Rullg?rd wrote:

...

Oded Shimon <ods15@ods15.dyndns.org> writes:

...

On Sat, Dec 23, 2006 at 03:09:24PM +0200, Oded Shimon wrote:

...

On Sat, Dec 23, 2006 at 01:56:29PM +0100, Michael Niedermayer wrote:

...

if the lists are not normative that i bet every commercial company will use their own fourcc divx, 3ivx, ... why? 1. the company can better claim that its their own supperior technology 2. they dont need to bother to implement the standard correctly, its enough if their decoder matches their encoder, this is what has happened with codecs in avi and as its less work = less money it will happen again. It didnt happen with mpeg-ps/ts just because there are too many hw decoders around which cant be updated that easily all IMHO

if my hypothesis turns out to be true then 3. would loose the "single fourcc per codec" and ""Sane" codec names" as in practice the majority of videos would not use the recommanded fourccs

so that brings us to option 4 which would require a player to only support a codec if the one and only standard fourcc where used, if a unknown fourcc is used demuxing it would be a violation of the spec ...

if that would prevent the issue iam not sure though ...

The list IS normative for demuxers, not for muxers. This was already in my original proposal, I forgot to re-mention it here.

To spell it out again:

A muxer SHOULD use the fourcc from the codec list A demuxer MUST support the fourcc from the codec list if it supports the codec at all

Which means demuxers can have additional fourcc's to the ones in the official list, and a muxer can do whatever it wants. But obviously, both are better off using the official list.

This makes no sense at all, but I think you already knew my opinion...

Actually, no, I'm confused by your reply... I was slightly off - the demuxer is better off using as many fourcc's as it wants, but it MUST include also the official list. The muxer, in most cases, is better off using only fourcc's from the official list, so it has garuntee of demuxers supporting it. I fail to see how this does not make sense. I don't know if you noticed, but I'm going through this entire thing only because of you, I personally do not care. So please, present your arguments.

Having a list makes no sense unless it's normative for both sides.

agree though thats a statement and not a argument the argument ("proof" by contradction) is that if the muxer can choose any fourcc for standard mpeg4 (not buggy near mpeg4 ...) then a demuxer cannot support mpeg4 in nut with 100% certainity, theres the very small possibility that mpeg4 would be stored with another new and unknown fourcc ... btw, one interresting goal of the codec id system should be: the system must be generic so that 2 users who otherwise cannot communicate can mux and demux a codec X in nut with high propability of success, without manual intervention and assuming the codec has a de-facto standard fourcc in avi [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle

Hi from Linuxtag! On Wed, Dec 27, 2006 at 11:54:40PM -0500, Rich Felker wrote:

On Sun, Dec 24, 2006 at 01:21:00PM +0100, Michael Niedermayer wrote:

...

...

Having a list makes no sense unless it's normative for both sides.

agree though thats a statement and not a argument the argument ("proof" by contradction) is that if the muxer can choose any fourcc for standard mpeg4 (not buggy near mpeg4 ...) then a demuxer cannot support mpeg4 in nut with 100% certainity, theres the very small possibility that mpeg4 would be stored with another new and unknown fourcc ...

Does this mean that we want a spec after all which is normative both for muxers and demuxers? This would mean, there would be a single table in the nut muxer implementation, and if muxing a codec which does not have an entry in the table is attempted, muxing would fail. - The resolution would be to contact us and the codec would be officially added to the list, and then it could be muxed, until then it would be impossible. I am not against this, as - this is a bikeshed issue... What are your opinions on this? Rich, Michael, please reply...

...

btw, one interresting goal of the codec id system should be: the system must be generic so that 2 users who otherwise cannot communicate can mux and demux a codec X in nut with high propability of success, without manual intervention and assuming the codec has a de-facto standard fourcc in avi

agree. some thoughts...

- we cannot stop people from inventing their own nonstandard id's for their bad implementations of (mostly) standard codecs, regardless of what id system we use.

- aside from such malicious parties, people making nut files will generally be interested in having their files be playable on as many players as possible.

- if we provide a list of officially sanctioned codec id's for standard codecs, and require any conformant player to support these id's if it supports the codec in question at all, then (1) we can officially flame anyone making a player that omits support for the standard name, and (2) people intending for their files to be widely playable will use the standard name since other names might not be supported by settop devices, etc.

- players wanting to provide maximum compatibility will also support various broken names for codecs, but this provides no significant implementation difficulty in complexity, size, or performance.

it's for these reasons that i want to stick with what oded has been saying. the only question in my mind is _which_ names should we agree upon as the standard ones????

If we do the above suggestion - spec is normative for muxers, then the answer is fairly easy - use our own new "clean" fourcc list. I would see no argument against this, as NUT would have its own completely fixed and seperate table... - ods15

On Thu, May 31, 2007 at 03:20:38AM +0200, Michael Niedermayer wrote:

On Wed, May 30, 2007 at 06:47:47PM +0300, Oded Shimon wrote:

...

On Wed, Dec 27, 2006 at 11:54:40PM -0500, Rich Felker wrote:

...

On Sun, Dec 24, 2006 at 01:21:00PM +0100, Michael Niedermayer wrote:

...

...

Having a list makes no sense unless it's normative for both sides.

agree though thats a statement and not a argument the argument ("proof" by contradction) is that if the muxer can choose any fourcc for standard mpeg4 (not buggy near mpeg4 ...) then a demuxer cannot support mpeg4 in nut with 100% certainity, theres the very small possibility that mpeg4 would be stored with another new and unknown fourcc ...

Does this mean that we want a spec after all which is normative both for muxers and demuxers? This would mean, there would be a single table in the nut muxer implementation, and if muxing a codec which does not have an entry in the table is attempted, muxing would fail. - The resolution would be to contact us and the codec would be officially added to the list, and then it could be muxed, until then it would be impossible.

I am not against this, as - this is a bikeshed issue... What are your opinions on this? Rich, Michael, please reply...

[..]

...

If we do the above suggestion - spec is normative for muxers, then the answer is fairly easy - use our own new "clean" fourcc list. I would see no argument against this, as NUT would have its own completely fixed and seperate table...

do we have a list that contains everything from http://www.fourcc.org/ ? do we have at least 2 volunteers who dont mind maintaining that list indefinitly ?

if the awnser is no to either of them then we dont need to disscuss the possibility of a normative list which is centrally controlled as we fail on the basic requirements for it ...

I am willing to make a list for all codecs currently in avocdec.h - that is all that would be relavent for a muxer in ffmpeg anyway. I also talked to Mans here at LT, we agree to maintain this list, "into the forseeable future"... - ods15

Hi On Thu, May 31, 2007 at 09:09:07PM +0200, Michael Niedermayer wrote:

Hi

On Thu, May 31, 2007 at 04:15:32PM +0300, Oded Shimon wrote:

...

On Thu, May 31, 2007 at 03:20:38AM +0200, Michael Niedermayer wrote:

...

On Wed, May 30, 2007 at 06:47:47PM +0300, Oded Shimon wrote:

...

On Wed, Dec 27, 2006 at 11:54:40PM -0500, Rich Felker wrote:

...

On Sun, Dec 24, 2006 at 01:21:00PM +0100, Michael Niedermayer wrote:

...

> Having a list makes no sense unless it's normative for both sides.

agree though thats a statement and not a argument the argument ("proof" by contradction) is that if the muxer can choose any fourcc for standard mpeg4 (not buggy near mpeg4 ...) then a demuxer cannot support mpeg4 in nut with 100% certainity, theres the very small possibility that mpeg4 would be stored with another new and unknown fourcc ...

Does this mean that we want a spec after all which is normative both for muxers and demuxers? This would mean, there would be a single table in the nut muxer implementation, and if muxing a codec which does not have an entry in the table is attempted, muxing would fail. - The resolution would be to contact us and the codec would be officially added to the list, and then it could be muxed, until then it would be impossible.

I am not against this, as - this is a bikeshed issue... What are your opinions on this? Rich, Michael, please reply...

[..]

...

...

If we do the above suggestion - spec is normative for muxers, then the answer is fairly easy - use our own new "clean" fourcc list. I would see no argument against this, as NUT would have its own completely fixed and seperate table...

do we have a list that contains everything from http://www.fourcc.org/ ? do we have at least 2 volunteers who dont mind maintaining that list indefinitly ?

if the awnser is no to either of them then we dont need to disscuss the possibility of a normative list which is centrally controlled as we fail on the basic requirements for it ...

I am willing to make a list for all codecs currently in avocdec.h - that is all that would be relavent for a muxer in ffmpeg anyway. I also talked to Mans here at LT, we agree to maintain this list, "into the forseeable future"...

iam against a list maintained by mans the reason is that he tends to do the things he maintains just halfway (he surely does that half which he does do well but that doesnt help us here ...) that is issues related to the mpeg (de)muxers in ffmpeg often get ignored for a long time also what is with the svn->git switch of ffmpeg? when i first said i wanted to switch ffmpeg to git the mphq roots where all apparently wanting ffmpeg to use mphq instead of another server and whats now, ... yes simple. "no comment" root is silent, sure its not mans alone and surely he is busy but i at least would appreceate a short note on ffmpeg-dev about the status of the move

its not as if adding accounts for the people would be harder than adding codec tags to a list ...

additionally if we do end up agreeing with such a list then ill be one of the people maintaining it (and i know already that in that case i would be the only one really doing the work which is why iam not happy about the whole idea, but at least that will prevent the mess we ended up with root@mphq ...) mans hates avi thats why he volunteers but after nut does no longer use avi fourcc, i very much doubt he will be maintaining the list how would that codec tag - codec registration work? do we choose the tag, does the person who contacted us choose the tag? what about common words, will we give them away to random people? what about random (windows) people who are unrelated to the codec authors, can they register tags? and what about codecs which cant just be stored as is but which need some clarifications like the xiph codecs and their 3 global packets do we insist on a clear spec for each codec for which we assign a tag? do we just say ok if someone want to register tag foo for the foobar codec or do we go and read the foobar spec and check if there might be any unclear parts which might lead to ambiguities when storing it in nut [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus