[NUT-devel] NUT documentation

[Måns Rullgård]

Michael Niedermayer <michaelni at 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 at inprovide.com