[NUT-devel] Issues

[Rich Felker]

On Fri, Mar 03, 2006 at 07:44:45PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Mar 03, 2006 at 12:49:37PM -0500, Rich Felker wrote:
> [...]
> > > 4. Info frames/streams/packets
> > > The first problem: limiting positions where info frames/packets should be
> > > Michael you said you're strongly against this, but you also said a muxer 
> > > should place them sanely and the demuxer should not go crazy looking for 
> > > them. IMO there should be rules that you can't just put the frames/packets 
> > > all over the place as you please, and I'd like to find the best ones that 
> > > stay fully featured while still allowing the demuxer to not have to search 
> > > everywhere for them.
> > 
> > Agree strongly. Michael, if you insist on having some type of info
> > packets that can be positioned at any random place in the file, I also
> > want there to be some way for the demuxer to know when the file author
> > was sane and only placed the packets where they belong. Info streams
> > with full stream semantics were my preferred solution, but I'm open to
> > other equivalent approaches. Things I don't want though:
> > 
> > - being required to transmit a duplicate info packet at the end of a
> >   chapter just to update the length.
> > 
> > - having to search the whole file to find the info that applies to a
> >   given time interval.
> 
> maybe nochange and noadd flags per info packet would make you happy, so as
> soon as some info is final these would be set and following info packets 
> for the specific "chapter" would have to be identical, that still allows
> updates on realtime streams ...
> 
> so the rules would be
> 
> 1. values MUST not change in a chapter for which a past info packet had the
>    nochange flag set, likewise nothing MUST be added if the noadd flag was
>    set
> 2. info packets MUST be stored and repeated after every mainheader-
>    streamheader set after which they become known unless they are big or
>    unimportant or irrelevent

This is a lot of added complexity for no gain over what I proposed...
Still it's better than nothing.

> rich, theres also yet another case where your idealistic restrictions cause
> troubble, and that is the next song/show/lecture/... in case of a realtime
> stream, yeah if its known i would like to know it so i can decide if i keep 
> sitting infront of my computer or if i can do something else in case i dont 
> want to hear it

How do my restrictions preclude a next-song field? IMO you have a
misperception of what I'm asking for.

Rich