[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Fri, Sep 09, 2005 at 01:44:52AM +0200, Alexander Strasser wrote:
> Hi,
> 
> Oded Shimon wrote:
> > +			Semantic requirements
> > +
> > +If more than one stream of a given stream class is present, each one MUST
> > +have info tags specifying disposition, and if applicable, language.
> > +
> > +A demuxer MUST NOT demux a stream which contains more than one stream, or which
> > +is wrapped in a structure to facilitate more than one stream or otherwise
> > +duplicate the role of a container. any such file is to be considered invalid.
> 
>   While i find the idea of the section good i find it way to strict.
> Or wrongly expressed --- i am not sure...
> 
>   What for example if i remux a file from a different format with multiple
> streams per class but the original file does not contain fields for
> disposition (and/or language). I don't want my muxer to just insert `random'
> valid fields just to be compliant with the nut specification. IMHO that

The semantic requirements are intended to be rules that the _user_ has
to follow when making files, not rules by which the software should
fudge around the user's mistakes. If a muxer wanted to be pedantic
about this it could give a fatal error, but IMO it's better to leave
the responsibility on the user.

So, what constitutes the user? IMO, if the input is coming from an
actual person operating the software and feeding it arbitrary input,
that person is the user. But if the input is coming from a
self-contained environment actually generating the content
(capture/encoding/etc.), the system should not be designed in such a
way that it will violate the semantic requirements.

> would even be backwards with regard to the spirit of the semantic requirements
> section. So I will end up with a invalid nut file.

:)

Perhaps there's room for discussing these, and replacing some MUST's
with SHOULD's. However if we have a "nutlint" program, it should
definitely report files that break these rules as broken.

>   There might also be cases with multiple streams per class which don't
> need dispostion at all.

Hmm?

>   Similar thing but maybe not so important goes for the second paragraph,
> what is wrong with demuxing the suspicious stream `at level 1' for trying
> to repair the sick combination.

"Be liberal in what you accept" is a very VERY bad philosophy for a
standard. It makes it so that anyone implementing the standard has to
create a horrible bloated abomination to handle the possibility that
someone has made a valid standards-conformant file requiring a
horrible bloated abomination to process it. Kind of like what's
happened to html, even though much of that's outside the actual
standard.

IMO the best philosophy for making a standard is to be extremely
pedantic in what you accept, such that there are as few ways to do a
given task as possible. Not only does this reduce bloat and redundancy
of the data stream itself, but it also makes it easy to know what's
correct and what's not, and what a valid implementation has to
support, and makes it feasible to actually make multiple independent
implementations. Surely some people will push the limits and try to do
stupid things. One way to discourage this is by making it so that most
of the stupid things they might try have well-defined conflicting
meanings already, so that it's impossible for an implementation to
handle both compliant and noncompliant data simultaneously. But
ultimately, if the things people do are stupid enough and not
permitted by the spec, no one will support it except their one broken
implementation, and no one will care.... :)

> Ok, it might be nontrivial, but maybe possible.
>   And i think the level 2 demuxing is out of the scope of the nut demuxer anyway.

Level 2 demuxing is forbidden by the NUT spec. :)
Stream class 0 means the content is video frames.
Stream class 1 means the content is audio frames.
etc.
There is no stream class for level 2 muxed data.


Rich