[NUT-devel] Info Packets

[Michael Niedermayer]

Hi

On Sun, Feb 19, 2006 at 03:01:25PM +0200, Oded Shimon wrote:
> On Sun, Feb 19, 2006 at 01:23:30PM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Sun, Feb 19, 2006 at 02:09:09PM +0200, Oded Shimon wrote:
> > > On Sun, Feb 19, 2006 at 10:28:39AM +0100, Michael Niedermayer wrote:
> > > > Hi
> > > > 
> > > > Currently info packets are
> > > > list of streams
> > > > list of name/type/value triplets
> > > > 
> > > > i would suggest that we change this to
> > > > first name/type/value is the "name/id" of what is described
> > > > remander is a list of descriptions
> > > > and require that any 2 info packets with the same name/id
> > > > be identical
> > > > 
> > > > one case where the current variant is unclear is
> > > > ChapterId=5
> > > > StartTime=1min
> > > > StopTime=2min
> > > > 
> > > > does this mean Chapter 5 is from 1min to 2min or that the info packet
> > > > describes the time from 1min to 2min of chapter 5?
> > > 
> > > I don't think you can break down info packets to smaller than chapers...
> > > Also, it's 'ChapterLength', not 'StopTime'...
> > > 
> > > I'm considering something different - each info packet is prepended with 
> > > stream id/mask and chapter id/mask, and they identify the entire info 
> > > packet.
> > > If we do the chapter mask thing, we might want to bring back the 
> > > "decompress element" you had... Chapters really would need an overflow 
> > > protection, and building a custom v reader is slightly annoying, as they 
> > > come in reverse order... (msb bits first)
> > 
> > do what you want, i will write my own ext-info packet
> > extension, as this is not worth the fight, info packets had one propose
> > and that was to be generic, and you and rich try to make it impossible
> > to store generic info with these packets, you wont succeed, people dont need
> > a standarized system to store what they want to store, only thing you achive
> > is that it will be non standard or they will use another container
> 
> 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


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

[...]
-- 
Michael