[NUT-devel] Re: FINALIZE NUT SPEC!!

[Rich Felker]

On Tue, Feb 28, 2006 at 08:15:13PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Tue, Feb 28, 2006 at 06:17:09AM +0200, Oded Shimon wrote:
> [...]
> 
> >  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.
> 
> iam not happy with this rule

A later frame could still update it. These end semantics are needed
for proper streaming; else you have to transmit an extra copy of the
info once it's no longer relevant, which is wasteful and silly. Also,
they improve reliability, not harm it. For example: if the length is
known ONLY once the chapter ends, then implicit ending ensures that
the length does not overflow forever if the final frame with the
length is somehow lost; it's bounded by the start of the next chapter.

> [...]
> > +The pts of an info frame MUST be >=chapter_start and <=chapter_start+len
> > +(Compared using compare_ts)
> 
> not acceptable, as it totally defeats the idea of updating info frames later

>= chapter_start is certainly correct imo.
If you want to relax/eliminate the <=chapter_start+len requirement I
won't object.

> > +Info frames with a different chapter_id (or EOR) MUST NOT appear between
> > +chapter_start and chapter_start+len. For overlapping chapters several info
> > +streams can be used.
> 
> not acceptable, same reason as above

As far as I can tell this is not related to the above.. Well, maybe
the "MUST NOT appear" is related, but the non-overlapping span
criterion is still valid.

> > +If an info stream contains an info frame for chapter X then it MUST contain
> > +an info frame with pts==chapter_start. Due to this restriction, the only
> > +legal timebase for chapter_start (and chapter_len) is the info stream
> > +timebase.
> 
> not acceptable, as it makes remuxing from info streams to info packets
> impossible (yeah the timebases might not match ...)

Agree that something needs to be done about this.

> > +Info frames with the same chapter_id and stream_id MUST have the same
> > +chapter_start and chapter_len if it is non zero. The last info frame with
> > +the same chapter_id and stream_id is the most correct one, and SHOULD have
> > +chapter_len filled.
> 
> iam weakly against this restriction, the last packet should be used otherwise
> errors in chapter_start/len cannot be fixed in realtime streams

I'm fairly neutral, but I'd like to do as much as we can to ensure
that info streams behave according to how you expect a stream to
behave, without imposing restrictions that prevent doing something
legitimate.

> i really start to loose interrest in fighting against these arbitrary
> restrictions, you shouldnt add a restriction without a REASON!!!!
> not add one based on philosophical ideas and then wait until some very
> serious consequences are found

Restrictions that are placed on the basis of 'philosophical ideas' do
have a reason. The reason is that a demuxer should not have to accept
every bit of random shit thrown at it by some windows idiot like is
the case with AVI. The more assumptions you can make about the format
and sanity of your data, and the more unexpected cases you can discard
as invalid data, the simpler the implementation and the less chance of
having unintended consequences.

I am all for arbitrary philosophical restrictions as long as they
don't impede the ability to represent legitimate, meaningful
information that cannot otherwise be represented. But I also don't
want to limit the usefulness of the format.

Rich