[NUT-devel] Issues

[Michael Niedermayer]

Hi

On Fri, Mar 03, 2006 at 02:06:07PM -0500, Rich Felker wrote:
> 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.

no its much simpler then what you proposed, you proposed a complicated and
very limited system of info packets, frames and streams where the end times of 
the frames would have to be calucaled based on future packet timstamps, 
my system has no info streams or frames, just info packets and they never
depend on any timestamps  of any packet and the demuxer never has to seek 
anywhere to  search for them the muxer must place them where they will be
needed like in every other standard


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

your restriction was that info must not be stored outside its relevance
area (start .. end to which it applies) the next field you propose
above violates this
if OTOH this rule only applies to chapter_start/len then iam happy
and we will just put dummy values in this and store all the actual info
in next-* fields
and if if you dont insist on that restriction anymore then no need for
a 2x complexity double level next-* system, just store the info packet
describing the next song

[...]
-- 
Michael