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

[Oded Shimon]

On Mon, Jan 09, 2006 at 10:58:52PM -0500, Rich Felker wrote:
> On Tue, Jan 10, 2006 at 03:04:38AM +0100, Michael Niedermayer wrote:
> > On Mon, Jan 09, 2006 at 05:42:33PM -0500, Rich Felker wrote:
> > > 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.

I didn't quite understand what you mean here, but I'd like to note that 
with per stream pts and ptr, a seek to pts will give the first keyframe, 
not the second. Because the second keyframe has pts A, which is higher than 
9...
back_ptr always points to the last keyframe, pts is the pts of that 
keyframe. (for the entire duration of a GOP, all syncpoints will have the 
same pts)

- ods15