[MPlayer-dev-eng] NUT/menus proposal

[D Richard Felker III]

On Fri, Sep 17, 2004 at 02:28:42AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Thursday 16 September 2004 05:33, D Richard Felker III wrote:
> > On Thu, Sep 16, 2004 at 03:43:43AM +0200, Michael Niedermayer wrote:
> [...]
> 
> >
> > > and please define what "essential" stream
> > > metadata is,
> >
> > i did this. essential data is something without which the player
> > cannot sanely play the movie. actually there's already a good example
> > of essential metadata in the stream headers, which you put there:
> > aspect ratio! sure you can decode and show the frames just fine
> > without knowing aspect, 
> 
> absolutely not, aspect ratio is needed to decode a stream into a physical 
> video (light intensity per x,y,t coordinate), the same would be true for 
> colorspace, framerate or gamma correction, but not for language or 
> disposition

i don't really see that much of a difference, but i sort of do.
whereas aspect, colorspace, etc. are needed to decode the stream
correctly, language/disposition are not needed to decode the stream
itself, but for correctly coordinating it with the other streams. btw
these things also apply to subtitles too -- you might have one track
that's karaoke/songlyrics, another that's director's comments, and
another that's translated dialogue.

btw for some movies subtitles are actually more complicated than you
might think. for example if you're watching a movie with both english
and spanish dialogue, you might only want to see english subs for
things said in spanish, but not things said in english. dvd handles
this with "forced" subtitle flag, but maybe this isn't general enough.
i wonder if this is an issue to be handled by the container or the
subtitle codec.

this brings up an interesting issue we've been arguing about a lot
actually: what really is a codec issue, and what's a container issue?
after all the experience everyone has had with audio and video, it's
obvious for audio and video, but i think it's still very non-obvious
for subtitles, your crazy advanced info packet ideas :), menus, etc.

> > if we want to move stuff to the info headers we could move aspect,
> > bitrate, colorspace type, and probably many other things there. but
> > instead we're storing these things in the main header because they're
> > considered essential. imo the ultimate determination should be this:
> > you should be able to take any nut file, strip all the info packets
> > from it, and still have a valid file that will be played correctly.
> 
> and what does "played correctly" mean? anyway, if u prefer this way of 
> seperating stream header content from info packet content over a clear 
> definition then thats fine with me, IIRC i already agreed in a past mail to 
> move the fields u consider essential-metadata to the stream header

i would be very happy with that solution, especially if we make sure
it's extensible so we can add a few more things later if ever needed.

if you'd prefer, i also think we could find something to agree upon
using info packets. i'm just not sure what a good way would be.
basically what you just quoted above is the biggest problem i have
with info packets. it's very hard to tell (without looking inside and
knowing a lot about the data) which ones are just fluff, and which
ones contain important data. if you want to remux a file, omitting
some streams, your remuxer needs to know which info packets are worth
keeping, and which were related to the discarded streams.

> > anyway michael i feel like this discussion is getting a little bit out
> > of hand. 
> 
> thats a point i absoluely agree about :)

:)

> clearly defining where info packets must be stored is not a thing that we 
> could but we must do otherwise the packets are obviously useless

ok, i agree strongly. but what do you think about where they should be
stored? perhaps it's different for different types of info packets.

while talking on irc, i mentioned the idea of interleaving info
packets like everything else thruout the file, but having them flagged
in the index with special entries so you could find them all if
needed. but this has problems too (lots of seeking at startup
required) 

> i also think it would be much more common to have disposition & language 
> incorretly set instead of having packets stored at a non-conforming place

imo not. people might omit them for single-stream files, but for
multistream it just wouldn't make sense. you wouldn't want to release
a file where it plays music-only soundtrack on half the players out
there... :) btw imo it should be allowed to omit all of these for
single-stream files, since no selection needs to be made, since legacy
tools writing single-stream only may not have a way to set this data,
and since you might just be making a quick casual encode. (on the
other hand, if you're making a multi-language rip it's almost
certainly a serious rip.)

> btw, something different, we should write a nut-verifer which checks that all 
> these rules are followed, that way we can reduce unintentional non-conforming 
> implementations, which generate non-interleaved files and such ...

yes, i agree totally. we already discussed this on irc. it would help
tremendously.

rich