[MPlayer-dev-eng] Lots of stuff for NUT

[Michael Niedermayer]

Hi

On Mon, Jan 09, 2006 at 05:42:33PM -0500, Rich Felker wrote:
[...]
> > > "Limited seek info" (your method)
> > > - extremely low overhead
> > > - approximate seeking is very fast
> > > - accurate seeking is very slow, even with index

with my suggestion of an index with
keyframe flags per syncpoint & stream it needs _rarely_ 2 seeks
and normally 1 while yours always can do it in one, thats not very slow

[...]

> 
> > > - demuxer implementation is somewhat more complex
> > 
> > i dont see why
> 
> Again if you only care to have your demuxer do really bad approximate
> seeking, it's not more complex.

so we agree here, we just disagree about the "badness"


> 
> If you want my old requirement (latest point such that ALL streams
> have keyframe between that point and target pts) then it's somewhat
> more complicated due to syncpoint timestamp not having a good
> definition. (As far as Oded and I can tell, it's impossible to make a
> good definition for it without complicating the muxer a LOT..)
> 
> If you're writing a demuxer that can seek to any keyframe, it will
> have lots of complications. This is the case I'm assuming since I want
> a complete, full-featured demuxer.

well, but your pts per stream method fails for closed GOP mpeg1/2/... files
too ...
for example:

pts: 1423756A89DBC
dts: 0123456789ABC
     IPBBPBBIBBPBB

lets assume complete knowledge about all keyframes
seek to pts=9 you will go to the first I frame and if you want, decode until
you reach that frame
now the catch is that if you would have seeked to the second I frame the mpeg
decoder does output the b frames as they dont depend upon the previous frame
(closed gop ...) so you would get frames for pts 8 and 9 before the I frame
your method is off by a whole GOP ...

[...]
-- 
Michael