[NUT-devel] revisions for nut-english.txt?

[Rich Felker]

On Thu, Feb 07, 2008 at 02:50:02AM +0100, Michael Niedermayer wrote:
> I have no interrest to support some custom blinking and sparkling GUI menus.
> What i want and what generic info packets fully supported until you decided
> that this functionality does not belong in nut. But rather belongs into some
> other hypothetical (=non existing) layer was for example:
> 
> Info packet 1
>     Title "scene abcd"
>     Start <timestamp>
>     End   <timestamp>
>     Stream 1,2,3,4
> 
> ...
> 
> Info packet 5
>     Title "scene defg"
>     Start <timestamp>
>     End   <timestamp>
>     Stream 1,2,3,4
> 
> Info packet 6
>     Title "scene defg without the nasty screams in the background"
>     Start <timestamp>
>     End   <timestamp>
>     Stream 1,2,3,5
> 
> ...
> 
> Info packet 10
>     Title "Foobar with happy ending"
>     Play 1
>     Play 3
>     Play 5
>     ...
> 
> Info packet 11
>     Title "Foobar with dramatic ending"
>     Play 1
>     Play 4
>     Play 5
>     ...
> 
> Info packet 12
>     Title "Foobar with happy ending, the censored for conservatives edition"
>     Play 1
>     Play 6
>     ...
> 
> Info packet 13
>     Title "Main movie menu"
>     Alernative  10
>     Alernative  11
>     Alernative  12

This whole sort of "play X, play Y, ..." scripting begins to reak an
awful lot of QuickTime... Look how hard it is to play QT files right
(or even decide what it means to play them "right") due to ridiculous
edit-type functionality in the container. I understand how stuff like
this is useful for certain purposes, but I still tend to think it's
better kept outside of NUT. (Not only does it preclude the creation of
files which no player knows how to play "right"; it also makes it
easier for someone working with menus to edit the menu structure
without recreating the whole file.)

Honestly I don't remember at this point what all the arguments
involved in the info flamewar were, what the pros and cons were, etc.
I know at one point I was in support of certain types of
limited-coverage info packets that apply only to segments of the
program, and my recollection is that it was more an issue of technical
problems (locating them, semantics for them, etc.) than theoretical
objection that led to my support of a proposal without them. In any
case, my health would do well not to revisit this unpleasant part of
the past...

Rich