[MPlayer-dev-eng] Finalize NUT spec

[Michael Niedermayer]

Hi

On Fri, Jan 27, 2006 at 09:07:15PM +0200, Oded Shimon wrote:
> 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.

hmm, the way i thought it could be done is flawed, heres a different one
i hope its not flawed ...

1. give every syncpoint a min and max pts (the max and min pts of the keyframes
   between this and the next syncpoint)
2. every syncpoint and stream has a relevance flag which indicates the
   relevance of the stream at that file position, any frame including EOR
   means relevant

seeking:
T is the timestamp the user wants
1. find all syncpoints which have min<=T<=max there will be very few due to 
   pts-dts difference limitations
2. search through these, every stream will either be
   non relevant due to a found EOR<=T with no EOR<keyframe<=T
   non relevant due to relevance flag == 0 in every of these syncpoints
   relevant with keyframe due to keyframe<=T with no keyframe<EOR<=T
   remaining ones
3. for the remaining ones search backward in the index until either
   a non relevant syncpoint is found -> non relevant stream
   a keyframe is found
4. take the earliest syncpoint which we end up with from the previous step
   and seek to it

--------
and heres a different one

1. do strict dts ordering
2. define a keyframe_pts map (keyframe flag within pts range for every stream
   stored exactly like the index-keyframe flags)
3. for each such keyframe store the dts-pts difference (this will need practi
   cally no space as the pts-dts difference for keyframes is very well
   compressable)
4. store for each pts map entry and stream its relevance at that point
5. store a syncpoint pos + dts index


seeking:
T is the timestamp the user wants
1. find the spot in the keyframe_pts map which contains T, find the max and
   min dts values of the keyframes which we are interrested in
2. find the corresponding syncpoints and look whats there, there will be either
   non relevant due to a found EOR<=T with no EOR<keyframe<=T
   non relevant due to flag of current entry
   relevant with keyframe due to keyframe<=T with no keyframe<EOR<=T
   relevant with no keyframe here
3. for the remaining ones go through the keyframe_pts map backward until you
   find a keyframe
4. take the earliest syncpoint which we end up with from the previous step
   and seek to 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...
> > 
> > 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...

after any of the repeated headers maybe?


also keep in mind headers (not index) cannot only be repeated every 2^n,
think about streaming they must be repeated often like once per second

[...]
-- 
Michael