[NUT-devel] Info Packets

Oded Shimon ods15 at ods15.dyndns.org
Sun Feb 19 19:45:01 CET 2006


On Sun, Feb 19, 2006 at 01:39:51PM -0500, Rich Felker wrote:
> 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.

I can't think of a usefulness for this btw... but it should be allowed

> 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.

Same here... global info is info usually about the "main content"...

> > 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.

I meant store the bitmask in ram, it's just a silly implementation detail, 
but i want to avoid yet another malloc for info struct...

> 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.

You mean, if I have 'director' set to the entire file, i can't use 
'director' again as a subinfo for some stream?.. sounds ok with me...

> - 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.

BTW, I'm considering keeping compatiblity with mkv tags, so transcoding is 
easy... Just the names of the fields, they use all caps and underscores 
(TITLE, CHAPTER_ID, whatever)

- ods15




More information about the NUT-devel mailing list