[NUT-devel] Patch for info packets

[Michael Niedermayer]

Hi

On Fri, Feb 24, 2006 at 04:59:58PM -0500, Rich Felker wrote:
> 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).

IMHO the issue is more complex, your argumentation that chapter length
isnt known (and i fully agree that there are realistic cases where
its not known) can be applied to many other things too
with your DJ example, things like genre or artist would be examples

maybe simply allowing adding but not removing stuff from info packets
would be the solution ...


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

so a single lost info frames will mess up 2 chapters, while with my suggestion
all info frames of a chapter need to be lost to loose any information


[...]

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

1 stream: actual chapters
2 stream: start/stop of commercial/advertisements

single EOR in stream 2 is lost -> whole chapter becomes marked as a 
commercial

[...]
-- 
Michael