[NUT-devel] Info Packets

Rich Felker dalias at aerifal.cx
Sun Feb 19 19:39:51 CET 2006


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




More information about the NUT-devel mailing list