[MPlayer-dev-eng] [PATCH] unified timing patch for H264

[Pásztor Szilárd]

Reimar Döffinger:
> That's almost never true. The additional code for -nocorrect-pts
> is even completely independant

Not really since they both use the same interface change in
dec_video.c, but now I've put in some work and split the two.
Here are the 2 separate patches (apply the reorder one first).

> and the "disable framedrop for first frame" part would be better
> separate as well since I suspect it's actually just hiding the real
> issue (i.e. a corner case where the new code does not behave stable
> and the first frame being dropped is just the only case where you saw
> the issue but it probably also exists in more cases).

Not true, it has nothing to do with the new code. It's just the simple recognition that if a frame gets dropped before video pts could have been initialized (and audio pts will surely be initialized), frames get indefinitely dropped because we're only drifting farther and farther from sync and there's no way out. This fix was born long before I've made any changes to the timing part.

But it's not important for me to fix this, so if you don't like it, then be it, I simply removed it from the patches.
And I know of no cases where the new code is unstable, suggestions with specified circumstances are welcome. That's why I asked you to review the patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-2010-08-29-nocorrect-pts.patch
Type: application/octet-stream
Size: 4920 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100829/c35bcec9/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-2010-08-29-pts-reorder.patch
Type: application/octet-stream
Size: 7930 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100829/c35bcec9/attachment-0001.obj>