[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Fri, Sep 09, 2005 at 10:12:59PM +0200, Michael Niedermayer wrote:
> > 2. Info packet position? Presumably now they can go anywhere, but this
> >    doesn't seem useful since we have info streams.. Can we restrict
> >    them to go at the beginning right after the main headers, so that
> >    the demuxer can actually find them? And at most one info packet per
> >    stream, plus at most one global info packet?
> 
> i dont like this

then how in the world is the player supposed to find them? the problem
is just like the problem we were having with those stupid gaps... it's
a linear search. and the worst part is, if there's no definitive way
to find the info packet _at startup_, it's impossible for the player
to select the right language the user wants! the result? players will
simply choose not to implement proper stream selection. :((((

as far as i can tell, the info streamtype provides a perfectly good
way to mux time-dependent info packets into the file. if
time-dependent info packets are stored the same as the file-global
info packet at the beginning of the file, it makes it impossible to
repeat the file-global info along with headers for redundancy (it
would appear as if it beloned to a specific time..).

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

> >    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.
Also 1 second is a very very frequent repetition. Will you really have
such a small video keyframe interval? If so, don't expect to get
tolerable quality with < 100 kbit.

Perhaps I'm not understanding your example and your intent very well,
so could you explain more..?

rich