[MPlayer-dev-eng] Finalize NUT spec

[Michael Niedermayer]

Hi

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


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


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


[...]

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

/me is silly, i missread that, i thought u meant convert ...

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


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

[...]
-- 
Michael