On Sun, Feb 19, 2006 at 06:47:13PM +0200, Oded Shimon wrote:
maybe a system we both would like is to add a list of streams and start/stop times at the top of every info packet, so that the packet applies to (streamX + StreamY + ... + StreamZ) at the time intervals (startX..endX + startY..EndY + ... + startZ..EndZ)
and require that every 2 info packes with the same streams and intervalls be identical
that would avoid the chapter limitation your system introduces and it doesnt make info packets depend on each other which means simpler parsing and more error robustness
Do we really need the ability to specify regions smaller/seperate from chapters? I fail to see the usefulness of this... Even mkv doesn't have such an ability, and they are the bloated tag-info experts... Maybe we can make a 'chapterid=-1' or whatever that means it's not any chapter, it's some subregion. it has the disadvantage of having to allow several packets with the same "chapterid"..
BTW, I vote to back to dropping the masks and going back to ability of a single stream and/or single chapterid per info packet.. The very rare space
I tend to agree with this, unless there's a compelling reason to do otherwise. What I originally envisioned was this: some metadata applies to the file as a unit (such as title, author, ...) while other metadata applies only to a single stream (language, disposition, ...). Then if you want chapters, you also have metadata that applies to only a fixed time range of the file as a unit, or (if you want very detailed information in odd cases) metadata that only applies to a fixed time range of one particular stream. Anyway, I never saw file-global metadata as being equivalent to "all streams". For instance, if I have an anime fansub, I would still consider the production company, director, etc. tags to apply to the file as a whole, and only tag the subtitle tracks with special info by the sub group (or even alternatively make an X-Subtitler global tag). Thus, I don't see any need when adding an extra stream to a nut file to exclude the global info tags from applying to it.
save is not worth the complexity.. (you have multiple packets describing the same stream or whatever) Even a simple implementation detail, how do you store the bitmask, you either limit yourself to 64 bits or use yet another dynamic array for the info packet...
No you don't!! This was already discussed. 'v' is called v for a reason; it has arbitrarily many bits! An implementation that won't read more than 64 for a field that's not limited to 64bit is a broken implementation. Anyway, I have no particular position for or against Michael's particular implementation ideas on info. However, here are a few things I would prefer... - Let's not use the same key more than once with different values in the same context (same stream/chapter/timeinterval). I fear this will be confusing to players. - If possible, I'd prefer that the demuxer not need to handle any of the semantics of info tags. But maybe this is a stupid requirement on my part. Maybe I'll try throwing some ideas out later for discussion. In the mean time, no worries, it's not my intent to flame or shoot down anyone's approach to info. Rich