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

[Rich Felker]

On Tue, Jan 10, 2006 at 03:04:38AM +0100, Michael Niedermayer wrote:
> 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

OK, so:

- accurate seeking is slightly slow with index, very slow without

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

Do files really use backward-only B frames for closed gop? IMO it's
just a waste but maybe it's required for some sort of conformance. I
would expect the frame type order (decode order) to be:

IPBBPBB|IPBBPBB
       ^ gop boundary

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

Isn't everyone's method off by a whole GOP for this? As far as I know
NUT contains no info that would allow you to know that B8 and B9
depend only on IA and not P7. Are you saying you'd like to include
some kinda gop boundary info, or..?

Honestly I don't know any good way to promise optimal seek to a given
nonkey frame. My point has always been about optimal seek to
keyframes.

Rich