[NUT-devel] Issues

[Rich Felker]

On Fri, Mar 03, 2006 at 11:25:55PM +0100, Michael Niedermayer wrote:
> > 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

"Where they will be needed" is completely undefined and often the file
author has a very braindamaged idea of "where they will be needed"
based on their intentions of what you will be able to do with the file
(which often explicitly excludes save-to-disk).

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

Not at all. A "next song" field is relevant during the current song,
and not relevant once the next song actually starts playing. Relevance
has a very specific technical definition here, and that definition
does not preclude you from doing what you want to do.

> 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

This is perfectly valid according to my spec, albeit rather stupid for
most purposes.

> 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

OK I see where you're coming from. Actually I don't object to being
able to 'presend' info like this. What I object to is being able to
retroactively change info, or having to scan backwards for info. In
particular, I find it very bad if the info might not be stored during
the chapter itself at all, or if the info might be changed at some
unboundedly-distant point in the future.

Does this make more sense? I was writing a draft explaining my
position better but maybe we're finally making progress on this
without it..

Rich