[MPlayer-dev-eng] Accurate video pts handling

[Uoti Urpala]

On Tue, 2006-05-09 at 20:27 +0200, Michael Niedermayer wrote:
> > of the buffer and used as the output timestamp of that frame. This works
> > without decoder assistance and whether the demuxer returns timestamps in
> > coded or display order

> then i must missunderstand you

> if we feed the reorder buffer from pts we get: 1234567, if we use dts we
> get: 0123456, thats not the same

By "timestamps in coded or display order" I mean pts values only. Using
dts values with formats which have those separately from pts won't work
right.

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

> alternatively if dts are available they can be used if not pts can be
> feeded into the decoder and reordered in it

dts values only work if you make assumptions about decoder behavior
(whether it does unnecessary buffering to nominal decode delay or not),
and aren't available in formats like mkv. Current libavcodec doesn't
seem to support feeding pts info with frames (and adding that would
probably be no simpler than adding internal counting of unseen buffered
frames, though might be preferable aesthetically). It would also require
that the demuxers give timestamps in coded order only, which current
mplayer demuxers do not.

> either way i disslike your changes to vd_ffmpeg.c, they are messy

I agree they're messy. As I said, the patch was not meant to be finished
code. It could be cleaned up somewhat, but I think the general approach
is the only one that works with current libavcodec. Changing libavcodec
instead would enable a cleaner solution. Just doing the same buffer
counting on the libavcodec side would make it much less messy, though it
would require numerically more code changes.