[MPlayer-dev-eng] Accurate video pts handling

[Michael Niedermayer]

Hi

On Tue, May 09, 2006 at 08:08:56PM +0300, Uoti Urpala wrote:
> The attached patch implements accurate video pts calculation for videos
> with B frames, and allows filters to modify pts values. It's not
> finished code but should be useful for people who want to test filters
> that modify pts values or who want accurate playback (I've modified the
> ASS subtitle patch to use the filter timestamps so subtitle changes
> timed at scene changes work correctly).
> 
> The patch adds an MPlayer option called -correct-pts. If that is not
> enabled things should work about the same; turning it on enables
> accurate pts tracking and allows filters to manipulate pts, but also
> breaks some things. The internal mpeg demuxer won't work (because
> currently code in video.c with mpeg-specific cases isn't run). If the
> demuxer doesn't give video timestamps for every frame things won't work
> right (no attempt to calculate timestamps based on default fps). Video
> decoders other than lavc won't work right if the video stream contains
> skipped or broken frames. There are also some other smaller known
> problems.
> 
> vf_ptstest.diff contains a simple video filter to demonstrate the pts
> manipulation. It compresses each second of video into the first half of
> the second with no frames in the second half.
> 
> The pts calculation with B frames works by keeping a buffer of pts
> values, where the timestamp of each frame fed to the decoder is added.
> Whenever the decoder outputs a frame the smallest timestamp is taken out
> 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

decoder input:
    pts  1423756
    dts  0123456
         IPBBPBB
decoder output:
         .IBBPBBP
    ts    1234567

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


> as long as the only reason the decoder doesn't
> return a frame is decoder lag. However to handle broken or skipped
> frames cooperation from the decoder is necessary, as it's necessary to
> distinguish between decoder lag (a timestamp should be buffered for that
> frame) and skipped frames (a timestamp should be dropped). The code
> tries to query the decoder for the number of buffered frames that have
> not been shown yet (those that should be timestamps buffered for them).
> The changes to vd_ffmpeg.c (ab)use the buffer interface to get this
> information out of lavc, it seems to work at least for the files I've
> tested.

whats the problem with using AVCodecContext.has_b_frames as the delay?

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

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

[...]

-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is