[MPlayer-dev-eng] Finalize NUT spec

[Oded Shimon]

On Fri, Jan 27, 2006 at 05:52:01PM +0100, Michael Niedermayer wrote:
> On Fri, Jan 27, 2006 at 05:40:09PM +0200, Oded Shimon wrote:
> > We want pts 11, we'll end up at K7 cause EOR10 is "silenced" by the K13. 
> > Only question left, do we care. I don't.
> 
> if we drop optimal seeking, can we then also drop the pts per first keyframe
> from the index?

I don't think so... I don't mind loosing optimal seeking just for edge EOR 
situations, but not in general.

> anyway heres an alternative suggestion for EOR indexes
> 1. store keyframe flags per syncpoint & stream (like we do currently)
> 2. store relevances flags per syncpoint & stream same way as keyframes 
>    so all syncpoints after a EOR are non relevant until the next keyframe
> 3. store nonkeyframe flags like keyframe flags (not needed for this but could
>    come in handy for other things and overhead should be negligible)

I think I've looked into this and it breaks just as much, like:

S EOR1 K3 EOR5 S

or other weird stuff. I dunno.

> > 2) info streams
> > They make single back_ptr rediculously big if you don't ignore them, and it 
> > wouldn't make sense to special case them. You can use EOR closely after the 
> > info frame, or you can repeat the info frame over and over... All solutions 
> > are non-ideal (and not theoretically correct)..
> 
> just repeat info packets and single back_ptr will be fine, or use nonkeyframe
> flags to skip "empty" segments

nonkeyframe flags? explain?...

> > 3) compare_ts
> > Could someone give an "accurate" code for this? I'm no good at this 
> > overflowing math. :)
> 
> av_rescale_rnd() in libavutil/mathematics.c

Hmm, doesn't seem like quite what I wanted. Either way, you used lavc 
bignum, which defeats the point. :)
Currently my compare_ts is:

static inline int compare_ts(uint64_t a, nut_timebase_t at, uint64_t b, nut_timebase_t bt) {
        a = convert_ts(a, at, bt);
        return a - b;
}

Which is wrong in cases where 'a' is close to 'b' and b's timebase is low 
accuracy (I need to know precisely if it is bigger than, smaller than, or 
equal to)

> > 4) what is a fourcc
> > Maybe it should be a seperate document from NUT spec, tied with it.
> 
> hmm, whatever but dont reinvent the wheel, the "fourccs" from avi&mov
> should be used whereever possible

Yeah I think just PCM needs it.

> > 5) index repetition
> > It can appear at any arbitrary point in the file, if it appears at all, it 
> > must be pointed to by index_ptr at EOF.
> 
> index repeation -> multiple indexes but 1 index_ptr or do we have several?

single index_ptr, definetaly.
I still don't really see a use for having index anyway except EOF or right 
after headers in begginning of file, and I'd rather the spec restrict it to 
those 2 places, so the demuxer only needs to look for it in 2 places. I 
don't want index position coded anywhere in main header or something 
like that...

> > Michael you said you had some minor comments? Now would be the time...
> 
> hmm, forgot them all :(

hehe. Maybe regarding main header tmp_* stuff?

- ods15