[NUT-devel] Chapters

[Oded Shimon]

On Sat, Feb 18, 2006 at 12:50:49PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Feb 18, 2006 at 01:32:13PM +0200, Oded Shimon wrote:
> > On Sat, Feb 18, 2006 at 12:21:38PM +0100, Michael Niedermayer wrote:
> [...]
> > 
> > > > > > Another note: I'd like to disallow info streams in non live streams.. For 
> > > > > > any purpose, info packets and chapters can be used. (It should at least be 
> > > > > > a "SHOULD"...)
> > > > > > 
> > > > > 
> > > > > use COULD.
> > > > 
> > > > No, SHOULD. "Info streams SHOULD NOT be used in non-live streams."
> > > > COULD only means ability. They can be used anywhere, but they should only 
> > > > be used in this situation. BTW, the only keywords defined in NUT spec are 
> > > > SHOULD and MUST. :)
> > > 
> > > iam strongly against that, either we need info streams or non global info
> > > packets, i dont care which but i wont accept the "neither case"
> > 
> > Well, there are two problems here:
> > 1. A player wants to know all chapter info when loading the file, so the 
> > user can do 'mplayer -chapter 5', and it can show chapter info while 
> > playing.
> > 2. A live stream wants to give song info when switching songs.
> > 
> > If we put chapter info spread out in an info stream, there's no way to load 
> > all chapter info when opening the file except linear searching the entire 
> > file.
> > What solution do you suggest to these 2 problems?
> 
> info != chapter
> 
> info can be stored at 2 places
> 1. global & constant & repeated after every main/stream headers
> 2. local in an info stream
> 
> info SHOULD be stored in global packets instead of info streams if possible
> and the amount of data is not large
> 
> noone wants 50mb of info packets at the file start nomatter what they contain

OK, I agree, this is actually same as I had in mind, I guess we just 
understood each other differently.

I can't think of any scenarios where info streams are useful except for 
live streams, that's why I said the "SHOULD" there, but your rule is more 
accurate...

- ods15