[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Sat, Sep 10, 2005 at 02:01:42AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Sep 09, 2005 at 06:39:08PM -0400, Rich Felker wrote:
> [...] 
> > > >    B. We can't ever add new "well known" fields to this table, even if
> > > >       we add new standard fields to the NUT spec, since old demuxers
> > > >       won't be able to translate the integer codes to key/type pairs.
> > > >       Even if you don't care about old demuxers knowing the key name,
> > > >       they _MUST_ know the type to know whether to parse the value as
> > > >       "v" or "vb". Thus the savings are limited to the few fields
> > > >       already in the table...
> > > 
> > > we could add reserved fields or say even == v / odd == vb
> > 
> > But still the demuxer won't be able to map them into names, so the
> > player won't know what to do with these new fields..
> 
> and how does the old player know what to do with the new names? a random
> word is as good as a random number (especially if its a hackisch abbreviation)

Think about modular crap on windows, where the player may know about
new tags but be using an old version of the "splitter"...
Maybe it doesn't matter..

> > > >    IMO it would be much more beneficial to just use short efficient
> > > >    keys (like "lang" instead of "Language", etc.) whenever they're
> > > >    clear.
> > > 
> > > hmm lets see how much space we loose in worst case, lets assume the
> > > info packets are repeated every second and we have 1video 1audio 1subtitle
> > > stream (more wouldnt be realistic for a very low bitrate stream)
> > > Author,Title,Copyright,Description 35byte/sec
> > > Encoder,Language,Disposition 3*29byte/sec
> > > -> 122 byte/sec = 976bit/sec ~ 1kbit/sec iam not so sure this is 
> > > insgnificant for very low bitrate
> > 
> > That's why I said we should shorten the strings to reasonable
> > abbreviations. Unlike a fixed number<-->longstring mapping, this would
> > be extensible.
> 
> dont we have more important things to work on with respect to nut then
> this?

Yes, probably so. IMO the other concerns with info packets were much
more important and we haven't addressed them yet. :(

> the only issue here is that we cant add anything to the table which was 
> never planned anyway and could trivially be fixed by "even == v / odd == vb"
> its not obvious to me why shortening the strings is a good idea, it is
> alot of work (which you wont do ..., which will delay nut further) 
> will either make things unreadable or hardly save space and most demuxers 
> will have to remap the short names to the standard author,title,... 

Fine, forget the short names. I see you don't like them and it doesn't
matter. I really don't know about the id codes.. maybe they're ok if
you can distinguish v/vb. I still wonder if that's even sufficient
tho, whether we'd want rational/float values (s,v num/denom or s,s
mantissa,exponent), ... But the other issues are more important so
let's discuss them first.

Rich