Attached is my attempts so far at documenting NUT in English as opposed to Lingua Dei Codicis. :) I'm told that, given good documentation on NUT, Måns is possibly willing to update the lavf implementation. The intent of this document is not to replace the formal spec that already exists, but rather for it to be developed into the "informative" (as opposed to normative) parts of the spec, particularly what one might call a "Usage" section. Rationale and Examples might be other non-normative sections we should consider writing. So far my writing has been somewhat disorganized. I think it could make a much better presentation if it used more itemized lists, tables, etc. Actually I'd be very happy if other people want to work on improving this; what I've set out is just the groundwork I think. Comments? Revisions? Frames? (Pardon my Engrish. :) Ideas for merging this into a nice specification document? Rich
Rich Felker wrote:
So far my writing has been somewhat disorganized. I think it could make a much better presentation if it used more itemized lists, tables, etc. Actually I'd be very happy if other people want to work on improving this; what I've set out is just the groundwork I think.
Looks nice so far.
Comments? Revisions? Frames? (Pardon my Engrish. :) Ideas for merging this into a nice specification document?
I'll think something later. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Fri, Oct 27, 2006 at 03:08:49AM -0400, Rich Felker wrote:
Attached is my attempts so far at documenting NUT in English as opposed to Lingua Dei Codicis. :) I'm told that, given good
BTW, what does "Lingua Dei Codicis" mean...
documentation on NUT, Måns is possibly willing to update the lavf implementation. The intent of this document is not to replace the formal spec that already exists, but rather for it to be developed into the "informative" (as opposed to normative) parts of the spec, particularly what one might call a "Usage" section. Rationale and Examples might be other non-normative sections we should consider writing.
So far my writing has been somewhat disorganized. I think it could make a much better presentation if it used more itemized lists, tables, etc. Actually I'd be very happy if other people want to work on improving this; what I've set out is just the groundwork I think.
Comments? Revisions? Frames? (Pardon my Engrish. :) Ideas for merging this into a nice specification document?
I personally preffer to have a normative terse spec, and an informative explanation document seperate, no need to merge to them...
Header Structure
A NUT file must begin with a magic identification string, followed by the main header and a stream header for each stream, ordered by stream id. No other packets may intervene between these header packets. For
This is actually no longer true with michael's change to the spec... reserved_headers needs to be checked between stream headers.
robustness, a NUT file needs to include backup copies of the headers. In the absence of valid headers at the beginning of the file, processes attempting to read a NUT file are recommended to search for backup headers beginning at each power-of-two byte offset in the file.
And end-of-file.
Simple stop conditions are provided to ensure that this search algorithm is bounded logarithmically in file length.
Which is... seeing a syncpoint or any nut packet...
Metadata - Info Packets
The NUT main header and stream headers may be followed by metadata "info" packets, which contain (mostly textual, but other formats are possible) information on the file, on particular streams, or on particular time intervals ("chapters") of the file, such as: title, author, language, etc. One should not that info packets may occur at
note* that
Index
An index packet to facilitate O(1) seek-to-time operations may follow the headers. If an index packet does exist here, it should be placed after info packets, rather than before. Since the contents of the index depend on knowing the complete contents of the file, most processes generating NUT files are not expected to store an index with the headers. This option is merely provided for applications where it makes sense, to allow the index to be read without any seek operations on the underlying media when it is available.
On the other hand, all NUT files except live streams (which have no concept of "end of file") must include an index at the end of the file, followed by a fixed-size 32-bit integer that is an offset
64-bit
[...]
I like it... You should note vlc's, and obviously a big issue is seeking. (Give a simple, non-optimal implementation for seeking with and without index..) - ods15
Hi On Fri, Oct 27, 2006 at 11:44:21AM +0200, Oded Shimon wrote: [...]
documentation on NUT, Måns is possibly willing to update the lavf implementation. The intent of this document is not to replace the formal spec that already exists, but rather for it to be developed into the "informative" (as opposed to normative) parts of the spec, particularly what one might call a "Usage" section. Rationale and Examples might be other non-normative sections we should consider writing.
So far my writing has been somewhat disorganized. I think it could make a much better presentation if it used more itemized lists, tables, etc. Actually I'd be very happy if other people want to work on improving this; what I've set out is just the groundwork I think.
Comments? Revisions? Frames? (Pardon my Engrish. :) Ideas for merging this into a nice specification document?
I personally preffer to have a normative terse spec, and an informative explanation document seperate, no need to merge to them...
iam happy with either
Header Structure
A NUT file must begin with a magic identification string, followed by the main header and a stream header for each stream, ordered by stream id. No other packets may intervene between these header packets. For
This is actually no longer true with michael's change to the spec... reserved_headers needs to be checked between stream headers.
yes, that allows possible future extension packets between stream headers, i dunno how important that is (i also dont remember if i had any specific uses in mind when i added this possibility...), if rich wants then iam not against removing this possibility (its no problem even now with the frozen spec as muxers arent allowed to inject reserved packets and demuxers would just have 1 requirement less) then again theres no need to hurry with that, we can always remove that possibility later ... [...]
I like it...
me too [...] -- 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, Oct 27, 2006 at 11:44:21AM +0200, Oded Shimon wrote:
On Fri, Oct 27, 2006 at 03:08:49AM -0400, Rich Felker wrote:
Attached is my attempts so far at documenting NUT in English as opposed to Lingua Dei Codicis. :) I'm told that, given good
BTW, what does "Lingua Dei Codicis" mean...
Language of the God of Code. Rich
Rich Felker <dalias@aerifal.cx> writes:
Attached is my attempts so far at documenting NUT in English as opposed to Lingua Dei Codicis. :) I'm told that, given good documentation on NUT, Måns is possibly willing to update the lavf implementation. The intent of this document is not to replace the formal spec that already exists, but rather for it to be developed into the "informative" (as opposed to normative) parts of the spec, particularly what one might call a "Usage" section. Rationale and Examples might be other non-normative sections we should consider writing.
So far my writing has been somewhat disorganized. I think it could make a much better presentation if it used more itemized lists, tables, etc. Actually I'd be very happy if other people want to work on improving this; what I've set out is just the groundwork I think.
Comments? Revisions? Frames? (Pardon my Engrish. :) Ideas for merging this into a nice specification document?
Are you people completely nuts? That text would do fine as a magazine article about a new file format. It tells the reader nothing whatsoever of use for writing a demuxer, let alone a muxer. What I'm asking for is a NORMATIVE description of the MEANING of each syntax element. There is some hint at such a section in the so-called spec. This should be expanded considerably. Also needed is a detailed explanation of the interactions between different syntax elements, particularly frame_code and timestamp related things. Some notes on rationale are welcome too, but not strictly necessary. Now you may as well forget all this anyway. Without a defined way of determining the codec for a stream, the format is useless. As you have previously refused to do anything about this, I'm not pursuing it further. -- Måns Rullgård mru@inprovide.com
On Fri, Oct 27, 2006 at 07:41:47PM +0100, Måns Rullgård wrote:
Rich Felker <dalias@aerifal.cx> writes:
Attached is my attempts so far at documenting NUT in English as opposed to Lingua Dei Codicis. :) I'm told that, given good documentation on NUT, Måns is possibly willing to update the lavf implementation. The intent of this document is not to replace the formal spec that already exists, but rather for it to be developed into the "informative" (as opposed to normative) parts of the spec, particularly what one might call a "Usage" section. Rationale and Examples might be other non-normative sections we should consider writing.
So far my writing has been somewhat disorganized. I think it could make a much better presentation if it used more itemized lists, tables, etc. Actually I'd be very happy if other people want to work on improving this; what I've set out is just the groundwork I think.
Comments? Revisions? Frames? (Pardon my Engrish. :) Ideas for merging this into a nice specification document?
Are you people completely nuts? That text would do fine as a magazine article about a new file format. It tells the reader nothing whatsoever of use for writing a demuxer, let alone a muxer.
What I'm asking for is a NORMATIVE description of the MEANING of each syntax element. There is some hint at such a section in the so-called spec. This should be expanded considerably. Also needed is a detailed explanation of the interactions between different syntax elements, particularly frame_code and timestamp related things.
Some notes on rationale are welcome too, but not strictly necessary.
Now you may as well forget all this anyway. Without a defined way of determining the codec for a stream, the format is useless. As you have previously refused to do anything about this, I'm not pursuing it further.
This was already done... *sigh* If you weren't interesting in working on this why didn't you just say so rather than flaming me after I try to put a lot of work into it. The structure of the syntax elements is already described in detail. What I've attempted to write (still extremely incomplete) is a guide for someone reading the spec to get the big picture. I'm sorry if it doesn't meet the expectations of what you were looking for, but I don't think it merits flame. Rich
Hi On Fri, Oct 27, 2006 at 07:41:47PM +0100, Måns Rullgård wrote: [...]
What I'm asking for is a NORMATIVE description of the MEANING of each syntax element. There is some hint at such a section in the so-called spec. This should be expanded considerably. Also needed is a detailed explanation of the interactions between different syntax elements, particularly frame_code and timestamp related things.
if you post a list of syntax elements which arent well documented then ill try to fix it, but its hard for us who wrote this and know what we had in mind to spot missing stuff
Some notes on rationale are welcome too, but not strictly necessary.
Now you may as well forget all this anyway. Without a defined way of determining the codec for a stream, the format is useless. As you have previously refused to do anything about this, I'm not pursuing it further.
i never had a problem with identifying codecs with fourccs, at least not more then i had with the mpeg systems (chinese avs and ac3 come to mind here) really i dont understand why you like one integer more then another the issue really is IMHO that every system which has been used in practice to store many different formats has accumulated some mess actually it seems that the number of formats used in practice and the number of somewhat messed up cases (divx vs. mpeg4 for example) is very highly correlated so sitting down and designing yet another will likely achive nothing either its not used by anyone or it will accumulate the same mess as every other system, or how do you want to prevent that? if you use strings instead of 32bit integers you will end up with a much much bigger mess because people _can_ missuse it much better [...] -- 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 <michaelni@gmx.at> writes:
Hi
On Fri, Oct 27, 2006 at 07:41:47PM +0100, Måns Rullgård wrote: [...]
What I'm asking for is a NORMATIVE description of the MEANING of each syntax element. There is some hint at such a section in the so-called spec. This should be expanded considerably. Also needed is a detailed explanation of the interactions between different syntax elements, particularly frame_code and timestamp related things.
if you post a list of syntax elements which arent well documented then ill try to fix it, but its hard for us who wrote this and know what we had in mind to spot missing stuff
Most of them. I already told you the interpretation of frame_code, and how the stuff it references is constructed could use some more explaining.
Some notes on rationale are welcome too, but not strictly necessary.
Now you may as well forget all this anyway. Without a defined way of determining the codec for a stream, the format is useless. As you have previously refused to do anything about this, I'm not pursuing it further.
i never had a problem with identifying codecs with fourccs, at least not more then i had with the mpeg systems (chinese avs and ac3 come to mind here) really i dont understand why you like one integer more then another
I prefer a DOCUMENTED integer over an UNDOCUMENTED one. I don't give a rat's ass about the exact values.
the issue really is IMHO that every system which has been used in practice to store many different formats has accumulated some mess actually it seems that the number of formats used in practice and the number of somewhat messed up cases (divx vs. mpeg4 for example) is very highly correlated
That's because AVI doesn't specify anything, so you HAVE TO invent something. Yeah, I've heard of some kind of official registry of codec IDs, but did you ever try finding it?
so sitting down and designing yet another will likely achive nothing either its not used by anyone or it will accumulate the same mess as every other system, or how do you want to prevent that? if you use strings instead of 32bit integers you will end up with a much much bigger mess because people _can_ missuse it much better
What you're saying is that because any system CAN be abused, rather try to start out with something sane, you incorporate an existing, already very abused, "system" lock, stock and barrel. Makes no sense to me. -- Måns Rullgård mru@inprovide.com
Måns Rullgård wrote:
What you're saying is that because any system CAN be abused, rather try to start out with something sane, you incorporate an existing, already very abused, "system" lock, stock and barrel. Makes no sense to me.
Last time we discussed it we ended with a "who implements the codeclist got it in the spec", nobody stepped up with a list nicer than what we have now. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Luca Barbato <lu_zero@gentoo.org> writes:
Måns Rullgård wrote:
What you're saying is that because any system CAN be abused, rather try to start out with something sane, you incorporate an existing, already very abused, "system" lock, stock and barrel. Makes no sense to me.
Last time we discussed it we ended with a "who implements the codeclist got it in the spec", nobody stepped up with a list nicer than what we have now.
I don't see ANY list. I don't care if you copy someone else's list, or invent your own, but whatever you do, it HAS to be in the spec. -- Måns Rullgård mru@inprovide.com
On Sat, Oct 28, 2006 at 11:47:05AM +0100, Måns Rullgård wrote:
Luca Barbato <lu_zero@gentoo.org> writes:
Måns Rullgård wrote:
What you're saying is that because any system CAN be abused, rather try to start out with something sane, you incorporate an existing, already very abused, "system" lock, stock and barrel. Makes no sense to me.
Last time we discussed it we ended with a "who implements the codeclist got it in the spec", nobody stepped up with a list nicer than what we have now.
I don't see ANY list. I don't care if you copy someone else's list, or invent your own, but whatever you do, it HAS to be in the spec.
one of the many proposed lists: http://lists.mplayerhq.hu/pipermail/nut-devel/2006-June/000433.html This is mostly grave-digging. I've never cared strongly about the issue. Feel free to throw gasoline on the ashes... Just hope it won't ignite. - ods15
Oded Shimon <ods15@ods15.dyndns.org> writes:
On Sat, Oct 28, 2006 at 11:47:05AM +0100, Måns Rullgård wrote:
Luca Barbato <lu_zero@gentoo.org> writes:
Måns Rullgård wrote:
What you're saying is that because any system CAN be abused, rather try to start out with something sane, you incorporate an existing, already very abused, "system" lock, stock and barrel. Makes no sense to me.
Last time we discussed it we ended with a "who implements the codeclist got it in the spec", nobody stepped up with a list nicer than what we have now.
I don't see ANY list. I don't care if you copy someone else's list, or invent your own, but whatever you do, it HAS to be in the spec.
one of the many proposed lists: http://lists.mplayerhq.hu/pipermail/nut-devel/2006-June/000433.html
Yes, there were a few PROPOSED lists. None of them were adopted in the actual spec.
This is mostly grave-digging. I've never cared strongly about the issue.
Therein lies the problem. You can't set out designing a file format ignoring one of the fundamental aspects. Until this changes, I consider the NUT format incomplete and a waste of time. -- Måns Rullgård mru@inprovide.com
On Sat, Oct 28, 2006 at 12:45:11PM +0100, Måns Rullgård wrote:
Oded Shimon <ods15@ods15.dyndns.org> writes:
On Sat, Oct 28, 2006 at 11:47:05AM +0100, Måns Rullgård wrote:
Luca Barbato <lu_zero@gentoo.org> writes:
Måns Rullgård wrote:
What you're saying is that because any system CAN be abused, rather try to start out with something sane, you incorporate an existing, already very abused, "system" lock, stock and barrel. Makes no sense to me.
Last time we discussed it we ended with a "who implements the codeclist got it in the spec", nobody stepped up with a list nicer than what we have now.
I don't see ANY list. I don't care if you copy someone else's list, or invent your own, but whatever you do, it HAS to be in the spec.
one of the many proposed lists: http://lists.mplayerhq.hu/pipermail/nut-devel/2006-June/000433.html
Yes, there were a few PROPOSED lists. None of them were adopted in the actual spec.
This is mostly grave-digging. I've never cared strongly about the issue.
Therein lies the problem. You can't set out designing a file format ignoring one of the fundamental aspects. Until this changes, I consider the NUT format incomplete and a waste of time.
Would it make you happy if something like this was added to the spec? possible fourcc's: "XVID","DIVX","DX50","FMP4" MPEG-4 Part 2 "H264","h264" MPEG-4 Part 10 "vrbs" Xiph.org Vorbis "\x00\x50" MP1, MP2 "\x00\x55" MP3 .... * note: the list is not a complete list and values can be added in the future Since I don't care about the issue, I don't mind if you add such a thing to the spec... For you this is fundemental. For me, this is bikeshed. - ods15
Oded Shimon <ods15@ods15.dyndns.org> writes:
On Sat, Oct 28, 2006 at 12:45:11PM +0100, Måns Rullgård wrote:
Oded Shimon <ods15@ods15.dyndns.org> writes:
On Sat, Oct 28, 2006 at 11:47:05AM +0100, Måns Rullgård wrote:
Luca Barbato <lu_zero@gentoo.org> writes:
Måns Rullgård wrote:
What you're saying is that because any system CAN be abused, rather try to start out with something sane, you incorporate an existing, already very abused, "system" lock, stock and barrel. Makes no sense to me.
Last time we discussed it we ended with a "who implements the codeclist got it in the spec", nobody stepped up with a list nicer than what we have now.
I don't see ANY list. I don't care if you copy someone else's list, or invent your own, but whatever you do, it HAS to be in the spec.
one of the many proposed lists: http://lists.mplayerhq.hu/pipermail/nut-devel/2006-June/000433.html
Yes, there were a few PROPOSED lists. None of them were adopted in the actual spec.
This is mostly grave-digging. I've never cared strongly about the issue.
Therein lies the problem. You can't set out designing a file format ignoring one of the fundamental aspects. Until this changes, I consider the NUT format incomplete and a waste of time.
Would it make you happy if something like this was added to the spec?
possible fourcc's: "XVID","DIVX","DX50","FMP4" MPEG-4 Part 2
Why so many IDs for the same codec?
"H264","h264" MPEG-4 Part 10 "vrbs" Xiph.org Vorbis "\x00\x50" MP1, MP2 "\x00\x55" MP3 .... * note: the list is not a complete list and values can be added in the future
Since I don't care about the issue, I don't mind if you add such a thing to the spec... For you this is fundemental. For me, this is bikeshed.
So given a NUT file, how do you know which codec is used if there is no official list of codec IDs? -- Måns Rullgård mru@inprovide.com
On Sat, Oct 28, 2006 at 01:12:12PM +0100, Måns Rullgård wrote:
Oded Shimon <ods15@ods15.dyndns.org> writes:
possible fourcc's: "XVID","DIVX","DX50","FMP4" MPEG-4 Part 2
Why so many IDs for the same codec?
That's an incomplete list, too... As for the rational, Michael mentioned turning on special codec workarounds by fourcc's.
"H264","h264" MPEG-4 Part 10 "vrbs" Xiph.org Vorbis "\x00\x50" MP1, MP2 "\x00\x55" MP3 .... * note: the list is not a complete list and values can be added in the future
Since I don't care about the issue, I don't mind if you add such a thing to the spec... For you this is fundemental. For me, this is bikeshed.
So given a NUT file, how do you know which codec is used if there is no official list of codec IDs?
I dunno, how do you accomplish this right now with AVI? As far as support goes, I'd say AVI is doing pretty well.. Even on set-op players... Now, believe it or not, coming up with a new system against the AVI mess, makes the situation WORSE, not better, because players would have to maintain multiple lists instead of one in order to support several formats. As for the actual list to put in the spec, for all I care you can grab the list from riff.c and use that. - ods15
Oded Shimon <ods15@ods15.dyndns.org> writes:
On Sat, Oct 28, 2006 at 01:12:12PM +0100, Måns Rullgård wrote:
So given a NUT file, how do you know which codec is used if there is no official list of codec IDs?
I dunno, how do you accomplish this right now with AVI? As far as support goes, I'd say AVI is doing pretty well.. Even on set-op players...
I thought we all agreed that AVI was a mess.
Now, believe it or not, coming up with a new system against the AVI mess, makes the situation WORSE, not better, because players would have to maintain multiple lists instead of one in order to support several formats.
Players already need one list per format. Did you ever notice that mov.c has its own list? Perhaps in an ideal world, each codec would have a unique identifier used across all formats. That is not the world we're living in, and unless we can manage to change that, which seems very unlikely, we simply have to deal with what we have. Closing your eyes does not make the problem go away.
As for the actual list to put in the spec, for all I care you can grab the list from riff.c and use that.
The fact that you don't seem to care at all about an important part of the spec is what worries me. -- Måns Rullgård mru@inprovide.com
Hi Måns Rullgård wrote:
Oded Shimon <ods15@ods15.dyndns.org> writes:
On Sat, Oct 28, 2006 at 01:12:12PM +0100, Måns Rullgård wrote:
So given a NUT file, how do you know which codec is used if there is no official list of codec IDs? I dunno, how do you accomplish this right now with AVI? As far as support goes, I'd say AVI is doing pretty well.. Even on set-op players...
I thought we all agreed that AVI was a mess.
Now, believe it or not, coming up with a new system against the AVI mess, makes the situation WORSE, not better, because players would have to maintain multiple lists instead of one in order to support several formats.
Players already need one list per format. Did you ever notice that mov.c has its own list? Perhaps in an ideal world, each codec would have a unique identifier used across all formats. That is not the world we're living in, and unless we can manage to change that, which seems very unlikely, we simply have to deal with what we have. Closing your eyes does not make the problem go away.
As for the actual list to put in the spec, for all I care you can grab the list from riff.c and use that.
The fact that you don't seem to care at all about an important part of the spec is what worries me.
I totally agree with Mans here, and I also really would like one and only one official fourcc per codec supported in NUT, be either avi one or mov one, and I would like to see it mentioned in the spec. Also, for codecs using different wrapping method (mov vs avi), it would be nice to mention the method that MUST be used in NUT, that's already done for H264, and OGG, and that should be done for every codec, which has more than one method. As it seems that nobody wants to write it, I'll try to complete one existing, or write a new one. Let's start something sane to build on: Tell me if someone disagree with that: 1) choose common avi fourcc if it exists, then mov one, then choose one 2) mov fourcc if it exists predomines twocc. 3) use twocc (I would prefer not, but oh well...) 4) generic garbage fourcc (like mp4a) which are not unique for codec will not be chosen. Any other idea ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
On Sat, Oct 28, 2006 at 02:05:10PM +0100, Måns Rullgård wrote:
Oded Shimon <ods15@ods15.dyndns.org> writes:
On Sat, Oct 28, 2006 at 01:12:12PM +0100, Måns Rullgård wrote:
So given a NUT file, how do you know which codec is used if there is no official list of codec IDs?
I dunno, how do you accomplish this right now with AVI? As far as support goes, I'd say AVI is doing pretty well.. Even on set-op players...
I thought we all agreed that AVI was a mess.
Being a mess and being broken are two entirely different things. AVI is a mess just like Wikipedia is a mess, because anyone can contribute whatever {codecs|articles} they want. The analogy continues in that both tend to, over time, stabilize on something less messy. On the other hand, MKV and MPG are _BROKEN_ because you cannot use arbitrary codecs in them (aside from the even-more-broken dshow-in-mkv idiocy or user-defined streams in MPG that have no standard interpretation aside from a small number of codecs like AC3).
Now, believe it or not, coming up with a new system against the AVI mess, makes the situation WORSE, not better, because players would have to maintain multiple lists instead of one in order to support several formats.
Players already need one list per format. Did you ever notice that
No they don't. As there are generally(*) no conflicts between the numbers used in different formats, a single list with multiple names for each codec in cases where they vary is sufficient. (*)The few broken formats that do use conflicting names, like 0x00000001 or such, generally only support a tiny number of codecs, or else the player can just remap the few conflicting names in the demuxer for the particular format to their standard names. One big list plus a few tiny patch-ups for broken formats is much better than O(n) lists!!
mov.c has its own list? Perhaps in an ideal world, each codec would have a unique identifier used across all formats. That is not the world we're living in, and unless we can manage to change that, which seems very unlikely, we simply have to deal with what we have. Closing your eyes does not make the problem go away.
The only way to make that reality is to adopt the already-agreed-upon names, not to invent some idiotic new standard!! ARRG I AM NOT GOING TO GO THROUGH THIS FUCKING DISCUSSION AGAIN! I AM PISSED ENOUGH ABOUT IT ALREADY!!!
As for the actual list to put in the spec, for all I care you can grab the list from riff.c and use that.
The fact that you don't seem to care at all about an important part of the spec is what worries me.
An actual list does not belong in the spec. On the other hand, here's what we _could_ do, and maybe you would be happy: 1. AVI/MOV video/audio codec names are used, with the most representative, least implementation-specific one being preferred. 2. For a list of common codecs, we document a preferred name. Any player that supports one of these codecs MUST (to be NUT compliant) support it when the preferred name is used. Obviously if someone goes and uses a stupid name like "DIVX" for mpeg4, the player might or might not support it, but it must support the name in the list. This way there is no large list to maintain, but we can guarantee compatibility for major standardized codecs. Moreover this "MUST" requirement will encourage file authors to use the standard name (since they know any NUT player will play it) rather than some stupid vendor-specific name like DIVX. If other NUT developers are interested in this and willing to maintain such a small list, I have no problem with the above system. But I will have nothing to do with any proposal that calls for a full codec registry, which reeks of NIH-syndrome! Rich
On Sat, Oct 28, 2006 at 11:10:30AM +0100, Måns Rullgård wrote:
Some notes on rationale are welcome too, but not strictly necessary.
Now you may as well forget all this anyway. Without a defined way of determining the codec for a stream, the format is useless. As you have previously refused to do anything about this, I'm not pursuing it further.
i never had a problem with identifying codecs with fourccs, at least not more then i had with the mpeg systems (chinese avs and ac3 come to mind here) really i dont understand why you like one integer more then another
I prefer a DOCUMENTED integer over an UNDOCUMENTED one. I don't give a rat's ass about the exact values.
OK then see below and add this to the spec...
the issue really is IMHO that every system which has been used in practice to store many different formats has accumulated some mess actually it seems that the number of formats used in practice and the number of somewhat messed up cases (divx vs. mpeg4 for example) is very highly correlated
That's because AVI doesn't specify anything, so you HAVE TO invent something. Yeah, I've heard of some kind of official registry of codec IDs, but did you ever try finding it?
No, you don't have to. What you specify is: THIS FIELD CONTAINS VALUES GENERALLY AGREED UPON BY THE PUBLIC. WHEN MULTIPLE VALUES ARE IN COMMON USE, RECOMMENDATIONS ARE MADE AS TO THE PREFERRED VALUE FOR USE IN NUT. THERE WILL BE NO CODEC ID REGISTRY!
so sitting down and designing yet another will likely achive nothing either its not used by anyone or it will accumulate the same mess as every other system, or how do you want to prevent that? if you use strings instead of 32bit integers you will end up with a much much bigger mess because people _can_ missuse it much better
What you're saying is that because any system CAN be abused, rather try to start out with something sane, you incorporate an existing, already very abused, "system" lock, stock and barrel. Makes no sense to me.
Look, we already finished NUT. This is over and decided. Please stop bringing up old flames again! I am so sick of explaining over and over why we made the decision we did and why it's vastly superior to all the other proposals which claim to "fix the problem" but fail, and moreover that there is in fact no problem to be fixed. Rich
participants (6)
-
Baptiste Coudurier -
Luca Barbato -
Michael Niedermayer -
Måns Rullgård -
Oded Shimon -
Rich Felker