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