[NUT-devel] Patch for info frames

[Oded Shimon]

On Sat, Feb 25, 2006 at 10:44:02PM -0500, Rich Felker wrote:
> On Sun, Feb 26, 2006 at 01:28:53AM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Sat, Feb 25, 2006 at 09:42:22PM +0200, Oded Shimon wrote:
> > [...]
> > > > 2. No frame with a different chapter_id (or EOR) may appear between
> > > >    chapter_start and chapter_start+len.
> > > 
> > > I'm OK with that. Michael?
> > 
> > iam ok with:
> > No frame with a different and positive chapter_id (or EOR) may appear between
> > chapter_start and chapter_start+len of a chapter_id>0 chapter
> 
> I want it for negative chapter_id too. Otherwise the stream-type
> semantics are broken.
> 
> I agree totally that overlapping spans are useful, but they can be
> done just as well using 2 or more info streams instead of just one.
> And this gives some meaning to the fact that we consider info as a
> stream like all others (with possible multiple instances), to make it
> seem a bit less odd. ;)

I agree with Rich...

> > > Index: DOCS/tech/mpcf.txt
> > > ===================================================================
> > > RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v
> > > retrieving revision 1.113
> > > diff -u -r1.113 mpcf.txt
> > > --- DOCS/tech/mpcf.txt	25 Feb 2006 18:51:46 -0000	1.113
> > > +++ DOCS/tech/mpcf.txt	25 Feb 2006 19:41:12 -0000
> > > @@ -640,6 +640,9 @@
> > >  
> > >  chapter_len
> > >      Length of chapter in same timebase of chapter_start.
> > > +    In info streams, if chapter_len is zero, chapter_len is the pts of
> > > +    the first EOR or info frame with a different chapter_id in the same
> > > +    info stream, minus chapter_start.
> > 
> > i would suggest (though i am not strongly against the above):
> > In info streams, chapter_len may be zero for some but not all info frames
> > of a chapter if the length is not known yet
> > this is simpler to remux with filling in length everywhere and its more
> > error robust
> 
> I discussed the idea of storing length in the final info frame of the
> span with Oded, but we agreed it was a bad idea because it would mean
> you would have to mux an extra 'duplicate' right at the end of the
> span, exactly at the moment where it ceased to be relevant. This seems
> totally wasteful and counter-intuitive.
> 
> Also I don't like the idea of the frames not being binary-identical.
> As long as they're binary-identical, the player can ignore the
> contents of duplicate frames completely, which simplifies the logic.

Agree here too.

- ods15