[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Wed, Sep 14, 2005 at 01:39:52AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Sep 12, 2005 at 11:26:52PM -0400, Rich Felker wrote:
> > On Tue, Sep 13, 2005 at 03:55:42AM +0200, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Mon, Sep 12, 2005 at 07:47:55PM -0400, Rich Felker wrote:
> > > [...]
> > > > > ok the obvious solution is to place that in the info stream
> > > > > its just that the player is probably not going to find these how should it?
> > > > 
> > > > Looking at index. Or backpointers at syncpoints when seeking without
> > > > index.
> > > 
> > > ok but how exactly should that work, my lets say 3h movie would have 200 
> > > info frames in the index and i would like to know the title(s) of all parts
> > > what should the player do, read all info frames?
> > 
> > Hmm, I see the problem. But I don't know a good solution. You're good
> > at these things; maybe you have an idea for making info easy to find
> > while also allowing dynamic info?
> 
> * store info stuff in several streams, so that "chapter/part descriptions" 
> like author/title/... are in their own while other less interresting things
> are in a different stream
> * mark repeated frames somehow in the index

Are you suggesting both together? I don't see how #1 helps without #2.
Still this seems very hackish.. I feel like there _should_ be an
elegant way to deal with this.

> > > > Well the spec seemed to imply that we would in the future add new
> > > > standard fields if they're deemed useful (and otherwise people can use
> > > > X-Foobar custom fields).
> > > 
> > > yes, but they dont need to be added to the table ...
> > 
> > Right. I was under the impression thought that if people made useful
> > extensions, we might eventually give them the holy blessing of NUT and
> > add them to the official spec without the X-... :) Surely you can
> > envision new fields becoming important in the future.. Whether they
> > need their own shortcut id codes, who knows.. maybe it's not
> > important.
> 
> well, you said yourself that updating the table is problematic and i agree
> it is when the thing which demuxes the file is old and the player new
> descriptive strings could be passed easily but nut specific id numbers ...

Hmm, I wasn't sure if this was a realistic problem or not. But if it
is, we should make sure we think of lots of possible keys before the
spec is made final, so that the size efficiency is maximized.

Rich