[MPlayer-dev-eng] Finalize NUT spec

[Oded Shimon]

On Fri, Jan 27, 2006 at 07:45:04PM +0100, Michael Niedermayer wrote:
> On Fri, Jan 27, 2006 at 07:09:22PM +0200, Oded Shimon wrote:
> > 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.
> 
> you dont loose it, it just needs 1 extra seek

You mean, still have optimal seeking with just a single pts per syncpoint 
and a single extra seek? I'm doubtful... Unless you mean a big linear 
search.

> > > 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
> 
> hmm, wheres the probem?
> if you want to seek to X and X is in a non relevant syncpoint interval then
> the stream is non relevent for X, if its relevant go back until you find a 
> keyframe in the index with a acceptable timestamp
> 
> here the interval is relevant, and you didnt mention it for the previous
> and next ones
> the first keyframe in the interval is EOR1 (EORs are keyframes!)
> so if the timestamp is < EOR1 we need to look at previous index entries
> if the timestamp is >= EOR1 and <S_end then this syncpoint interval is the
> correct one, for >S_end we would need to know what comes after it which you
> didnt write down ...
> for the EOR5 ... S and EOR1 ... K3 you seek there and then notice its not
> relevant sure, but thats not a problem, it just needs to look through 1
> syncpoint interval which we need anyway

Sorry, I can't think with the EOR and keyframe stuff anymore, it confuses 
me too much. :( If you got a spec and a seek algo and you think it works, 
just give it and I'll patch the spec and libnut...

I think I understand what you meant now, in the 'relavence syncpoint' part, 
you mean just code yes-or-no for every syncpoint saying if it is relavent 
or not, not pts or anything else... so, in the above example, is that 
syncpoint region relavent or not? what about a syncpoint region which just 
has an eor in it? how is it defined.

> > > > 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?...
> 
> forget it, it only works with an index and so the back_ptr wont matter

Speaking of which, I'm generally against nonkeyframe flag, it just adds 
muxer and spec complication to save speed in an already slow operation 
(percise frame-exact seeking). Actually, heh, it does speed up keyframe 
exact seeking too, but I'm not sure it is worth it.

> return a * at.num * bt.den - b * bt.num * at.den;
> would work if it doesnt overflow :)
> 
> what about:
> 
> if(convert_ts(a, at, bt) < b) return -1
> if(convert_ts(b, bt, at) < a) return  1
> return 0
> 
> why does it work? magic :)
> no, convert_ts always rounds inexact ones down, so 
> if "a < b" then convert_ts(a, at, bt) < b and the other way around too
> now if "a=b" then both convers should be equal if convert_ts is exact

A-ha, cool! Thanks. :)

> > > > 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...
> 
> the demuxer only has to look in one place (at the end) but a demuxer can
> if that one is damaged try a redundant copy of it, thats optional

Where would it look for it though, just linear search the entire file? If 
we decide it can be put at any random place, we should decide what those 
random places are then, like 2^n with main headers...

- ods15