[MPlayer-dev-eng] Accurate video pts handling

Uoti Urpala uoti.urpala at pp1.inet.fi
Wed May 10 01:04:56 CEST 2006


On Wed, 2006-05-10 at 00:24 +0200, Michael Niedermayer wrote:
> On Tue, May 09, 2006 at 10:19:06PM +0300, Uoti Urpala wrote:
> > > whats the problem with using AVCodecContext.has_b_frames as the delay?
> > 
> > I think it doesn't always have the correct value for that use. It
> > doesn't seem to be reset after seeks or errors which make lavc drop
> > buffered frames.
> 
> could you elaborate?
> if we seek, we flush the buffers so the number of frames in the decoder
> becomes 0 (you also could flush the pts buffer here), and at the time 
> when we output the next frame it should be AVCodecContext.has_b_frames 
> again, this seems correct?

It's not for h264 at least, the first keyframe after seek is output
immediately.

> theres also something entirely different ... what about remuxing without
> a decoder (-vcodec copy / -acodec copy)? this also needs correct timestamps

That's mainly a question of demuxers. Muxing to containers like mkv
without decoding is not possible with the current MPlayer demuxers,
they'd all need to be changed to give timestamps in the order the
pictures are coded rather than monotonously (and remuxing from
containers like avi without codec-level parsing is impossible I
suppose...).




More information about the MPlayer-dev-eng mailing list