On Sun, Feb 19, 2006 at 03:42:11PM +0100, Michael Niedermayer wrote:
On Sun, Feb 19, 2006 at 03:01:25PM +0200, Oded Shimon wrote:
Umm... I had no intention of flaming or fighting :/
I want a relatively standarnized way of handling chapters/streams in info packets in nut so not any asshat can make up his own stuff and no player will know what to do with it... Yes info packets should be generic, but not to the point that players won't know how to handle them and make use of them... :/
So, going back to your idea of "first triplet is the id of the info packet". You use it is like this?
packet: title=bla, artist=.. (global packet) packet: streamid=1, disposition=.. ("streamid" is a field like any other?) packet: chapterid=1, start=0, length=3min, title=... packet: chapterid=2, start=3min, length=3min, ... ...
If I understand this correctly, there's no way to describe further in detail than a chapter, or a stream, or describe several streams/chapter together. (like, you can't describe a certain chapter for a certain stream. not that i see a usefulness in this though)
well, my idea was supposed to allow this too, but iam no longer sure if its clean or a good idea how i wanted to support that, probably you wont like it
packet: global, title=blah, artist= ... packet: stream=2, disposition=commentary, language=eng packet: part=0, stream=0, stream=1, disposition= packet: chapter=0, start=0, length=5, title="introduction" packet: chapter=1, start=5, length=10,title="battle" packet: part=1, chapter=0, chapter=1, director="arpi" packet: part=2, part=1, chapter=2, location="russia" packet: part=3, start=0, length=1, stream=1, artist=foobar
Yeah you guessed right... I don't like it, too high complexity :/
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 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... - ods15