[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Mon, Sep 12, 2005 at 11:01:03PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Sep 11, 2005 at 03:40:47PM -0400, Rich Felker 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?
> > 
> > Michael, you said you don't like what I said here, but can you explain
> > why? IMO info packets are useless if the player can't find them.
> 
> ok there are several things i think are problematic
> we have info streams? do you mean the metadata stream type? what is
> its format? entirely user defined?

My intention was that you store key/value pairs in nut info format, or
at least this could be the contents of a metadata stream with one
particular fourcc (so that people could use metadata streams for other
types of data if they prefer).

> there are too many rules and restrictions with no analysis of the 
> consequnces

Well that's what I want to do now. Lack of any rules can also have bad
consequences, like not being able to find the relevant data in
efficient time or at all..

> info packets must be at the start, the muxer must not require seeking back
> how is this supposed to work?

For info that doesn't change and applies to the whole file, you know
it before writing starts. For a file containing a single
song/movie/whatever, this would be things like title, artist/studio,
album, language, copyright, ...

As for info that varies during the file (for instance a multi-song
live stream) i think it only makes sense to send it at the points
where it's valid. However, this data should be muxed in a sane way
such that it can be found with the index. Otherwise if you save a live
stream to disk, it becomes virtually impossible to use the info
packets stored in it unless you play the stream sequentially from the
beginning.

> and if you now suggest to put them at the end
> well you also said truncated files must be valid IIRC ...

I definitely don't suggest putting them at the end.

> furthermore you completely ignore that various metadata might not be constant
> for example a nut file with all the LOTR films, the title isnt constant
> the start and stop times of each might or might not be known when
> encoding starts,

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

> if we could have multiple packets at the start then the parts could be
> described at least if the info is available ...

I see. This is ok, but not very useful for live streams (and see above
for why I think it's a bad idea to handle live streams differently).
I'm not at all against having multiple info packets at the beginning
each applying to different times (altho maybe the time to which the
packet applies should be stored in the nut structure itself rather
than as a key/value pair, but that's not really important).

> > > 3. Info fields table:
> > ...
> > 
> > My idea for this seems to have been rejected. IMO it's not a big deal
> > as long as there's a safe way to add new values without breaking
> > parsability of the table.
> 
> why do we need to add new fields to the table? i see no sense in 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).

Rich