[NUT-devel] Patch for info frames

[Rich Felker]

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

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

Rich