[MPlayer-dev-eng] NUT cleanup

[Michael Niedermayer]

Hi

On Tue, Sep 13, 2005 at 10:22:19PM -0400, Rich Felker wrote:
> 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? 

yes


> 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, if you think theres a better way then find and propose it or just drop
the 1pass muxing restriction


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

another example is remuxing with an old app ...


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

yes

[...]
-- 
Michael