[MPlayer-dev-eng] NUT/menus proposal

[Michael Niedermayer]

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


> but any non-broken player needs to know aspect 
> or the output it shows will be bogus. similarly any nonbroken player
> needs to know if a stream is commentary, music-only, or main audio
> track, and what language it is, etc., or it will play bogus stuff by
> default.
>
> 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

[...]

>
> anyway michael i feel like this discussion is getting a little bit out
> of hand. 

thats a point i absoluely agree about :)


> you put a lot of work into designing something that doesn't 
> suck (tm^H^Hgm ;), and i don't mean to disrespect what you've done or
> your judgement on it. but i also know the current state of video
> containers sucks with respect to multi-track and multi-language, and
> often it's impossible to get your player to play the track you intend
> without randomly trying all the tracks until you find the right one.
> nut should be better than that, and i think if we stuff this critical
> information away in an info packet that can appear at an arbitrary
> location in the file (so it's hard for a player to find, like mplayer
> with ogm files now...) then things won't get any better. (i know we
> could still require an info packet at the beginning with these things,
> but it's more likely that people would ignore it..)

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

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

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 ...

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();  (violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535)
buf[i]= qp - buf[i-1];    (violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en