[MPlayer-dev-eng] [PATCH] buffered pts when -correct-pts

[Pásztor Szilárd]

Hi,

I'm attaching a patch that hacks PTS buffer handling when -correct-pts is in
effect, resulting in a smooth playback as it should be.
PTS buffer handling is incorrect when an interlaced stream has B-frames, such
as most H.264 HD broadcasts or Blu-Rays. When asking for the "decoder lag",
it is not taken into account that interlaced streams generate twice as many
entries into the PTS buffer but decoder lag reports only the number of full
frames, resulting in timestamps getting dropped from the end of the buffer.
Hence, the stupidest method to handle it is what you can see in this patch in
dec_video.c. It is not a clever solution but probably doesn't do any harm
because the multiplied value is only used as kind of a security check.
Determining if streams are interlaced and doubling the value accordingly
would be the best solution.

There is also a small insertion to mplayer.c where a bug can occur if
framedrop is enabled. The video pts in sh_video may never be initialized if
the first frame can get dropped, which means that video can never spring into
life. Therefore it can be helpful to disable framedropping until we have
decoded our first video frame.

To demonstrate the difference in decoding precision due to the pts buffer
patch, here are 2 snippets from my own debug output of playing a 25fps h264
hd stream, at first before patching:

Framediff: 34432, PTS: 9335.33, slept: 21, Vo-diff: 59
Framediff: 69358, PTS: 9335.41, slept: 35893, Vo-diff: 66
Framediff: 42343, PTS: 9335.45, slept: 13079, Vo-diff: 51
Framediff: 25241, PTS: 9335.45, slept: 25, Vo-diff: 63
Framediff: 36300, PTS: 9335.49, slept: 20, Vo-diff: 56
Framediff: 64668, PTS: 9335.57, slept: 31264, Vo-diff: 66
Framediff: 40579, PTS: 9335.61, slept: 12791, Vo-diff: 55
Framediff: 27808, PTS: 9335.61, slept: 24, Vo-diff: 63
Framediff: 35195, PTS: 9335.65, slept: 21, Vo-diff: 60
Framediff: 59598, PTS: 9335.73, slept: 25427, Vo-diff: 54
Framediff: 40017, PTS: 9335.77, slept: 14711, Vo-diff: 65
Framediff: 28339, PTS: 9335.77, slept: 24, Vo-diff: 62
Framediff: 35802, PTS: 9335.81, slept: 21, Vo-diff: 62
Framediff: 56879, PTS: 9335.89, slept: 22539, Vo-diff: 61
Framediff: 40042, PTS: 9335.93, slept: 12374, Vo-diff: 56
Framediff: 27735, PTS: 9335.93, slept: 24, Vo-diff: 63
Framediff: 37548, PTS: 9335.97, slept: 19, Vo-diff: 62
Framediff: 56009, PTS: 9336.05, slept: 20611, Vo-diff: 68
Framediff: 40614, PTS: 9336.09, slept: 13497, Vo-diff: 67
Framediff: 30188, PTS: 9336.09, slept: 24, Vo-diff: 62
Framediff: 36706, PTS: 9336.13, slept: 23, Vo-diff: 61
Framediff: 55682, PTS: 9336.21, slept: 22905, Vo-diff: 58

The times shown are in microseconds. Framediff should be as close to 40000 as
possible (1/25 seconds). What you see instead is a result of the PTS being
perturbed because values get erroneously dropped. This is how playback goes
after patching (same sample):

Framediff: 40011, PTS: 9375.13, slept: 5364, Vo-diff: 61
Framediff: 40005, PTS: 9375.17, slept: 4049, Vo-diff: 60
Framediff: 40010, PTS: 9375.21, slept: 15680, Vo-diff: 59
Framediff: 40009, PTS: 9375.25, slept: 14958, Vo-diff: 64
Framediff: 39026, PTS: 9375.29, slept: 22, Vo-diff: 60
Framediff: 41394, PTS: 9375.33, slept: 8466, Vo-diff: 57
Framediff: 39578, PTS: 9375.37, slept: 10972, Vo-diff: 61
Framediff: 40000, PTS: 9375.41, slept: 10954, Vo-diff: 58
Framediff: 39079, PTS: 9375.45, slept: 25, Vo-diff: 60
Framediff: 41064, PTS: 9375.49, slept: 7512, Vo-diff: 54
Framediff: 39918, PTS: 9375.53, slept: 12397, Vo-diff: 59
Framediff: 39966, PTS: 9375.57, slept: 12794, Vo-diff: 467
Framediff: 39940, PTS: 9375.61, slept: 3625, Vo-diff: 60
Framediff: 40015, PTS: 9375.65, slept: 4024, Vo-diff: 65
Framediff: 40001, PTS: 9375.69, slept: 15988, Vo-diff: 66
Framediff: 39972, PTS: 9375.73, slept: 15112, Vo-diff: 58
Framediff: 40009, PTS: 9375.77, slept: 1223, Vo-diff: 94
Framediff: 40085, PTS: 9375.81, slept: 5603, Vo-diff: 56
Framediff: 39917, PTS: 9375.85, slept: 15741, Vo-diff: 54
Framediff: 40286, PTS: 9375.89, slept: 10687, Vo-diff: 54
Framediff: 39926, PTS: 9375.93, slept: 3607, Vo-diff: 54

This time the PTS are correct, and so is timing.

greets
s.

              ----------------------------------------------------
              |  Sometimes the best solution to morale problems  |
              |     is just to fire all the unhappy people.      |
              ----------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: correct-pts-20100816.diff
Type: application/octet-stream
Size: 1844 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100816/51645986/attachment.obj>