[NUT-devel] Patch for info packets

[Rich Felker]

On Fri, Feb 24, 2006 at 02:31:15PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Feb 24, 2006 at 01:45:46AM -0500, Rich Felker wrote:
> > On Fri, Feb 24, 2006 at 07:45:36AM +0200, Oded Shimon wrote:
> > > On Fri, Feb 24, 2006 at 01:39:00AM +0100, Michael Niedermayer wrote:
> > > > On Thu, Feb 23, 2006 at 08:18:32PM +0200, Oded Shimon wrote:
> > > > > New patch. One kink left to sort out is info frames. My suggestion for it 
> > > > > is to use negative chapter id's..
> > > > > 
> > > > > Can I commit this patch?
> > > > 
> > > > ok
> > > 
> > > committed, with one additional clause:
> > > +Info SHOULD be stored in global packets instead of info streams/frames if
> > > +possible, and the amount of data is not large.
> > > 
> > > Taken from Michael's phrasing a while ago...
> > > 
> > > Now, my idea for info frames - exactly the same as info packets. The pts 
> > > for info frames is completely meaningless, it's only there to be able to 
> > > comply to MN rule, so there can be repeated info frames, that describe the 
> > > same "chapter", and you can see that they are the same info frame because 
> > > they have the same chapter id, which means they must be binary identical.
> > 
> > I'm against it, unless you're proposing that we remove info streams
> > entirely.. This completely nullifies the stream-quality of info
> > streams. There's no guarantee that you'll have the frame by the time
> > it becomes relevant, or that it won't appear way before it's relevant,
> > etc.
> > 
> > Rather, I would _like_ to do like this: info frames have no
> > chapter_start or chapter_len because these values are implicit in
> > their frame pts and the next frame pts (possibly EOR). However, this
> 
> iam against this, info frames and info packets should be identical so
> we can remux info stream stuff into info packets if we want to or
> the other way around without looking at the contents
> furthermore if we start playing in the middle of a chapter we will need
> some repeated info frames to figure out what we see

If you're against this adamantly then we might as well remove info
streams entirely, since your objections ruin the whole stream property
of info streams that I wanted them for. The problem is this: if you
have a reason to use info streams instead of info packets at the
header, it's because chapter length is NOT known at the time the first
info frame for the 'chapter' is written. Consider something like a
like news show where the info is produced by someone at the studio at
the same time it's being transmitted. A simpler more realistic example
would be a live net radio show with DJ segments (unknown length) and
songs (known length).

I have a proposal that works, IMO. It requires some alterrations to
convert info frames to info packets, but ONLY in the header (chapter
start/length), not any of the contents (key/value pairs). It works
like:

1. All info frames with the same chapter id must be binary identical.
2. The first info frame with a given chapter id determines the start
   time of the chapter from its pts.
3. An info frame with different chapter id (or EOR) marks the end time
   of the previous chapter. Info frames with same chapter id are just
   repetition and have no other meaning.

This scheme allows full stream-type semantics for info frames, so that
they work as intended.

Oded had an alternate proposal of just storing 0 as the chapter length
if it's unknown. I objected to this because it's lossy, i.e. these
chapters, like all chapters, _do_ have a length; it's just not known
until further along in the stream. Surely it could be stored in other
ways (like key/value pairs), but this precludes easy remuxing chapter
information from a live stream into chapter information for a
permenant file, since you'd have to parse special keys.

One objection you may have to my scheme is that it precludes
overlapping chapter spans. I thought this was a problem too and didn't
like it at first, but then Oded pointed out that you can use more than
one info stream if you need to (the above points 2-3 should be
interpreted only within a single given stream).

Comments?

Rich