[NUT-devel] Info Packets

Oded Shimon ods15 at ods15.dyndns.org
Sun Feb 19 17:47:13 CET 2006


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




More information about the NUT-devel mailing list