[MPlayer-dev-eng] Reverted patch of time-based PTS locking

[Reimar Döffinger]

On Mon, Aug 20, 2012 at 03:44:37PM +0200, Pásztor Szilárd wrote:
> +		case DEMUXER_CTRL_CORRECT_PTS:
> +		{
> +		    // Hack to return OK if H264 so that pts correction will be active
> +		    return ((sh_video_t *)(demuxer->video->sh))->format == 0x10000005 ?
> +			DEMUXER_CTRL_OK : DEMUXER_CTRL_DONTKNOW;

That is rather misleading. CORRECT_PTS does _not_ enable PTS correction,
quite the opposite it makes the code assume that the PTS values are
correct.
For that it also enables reordering of the PTS values, though that is
more a side-effect.
Another, more serious side effect is that it will disable parsing of the
video stream, which makes me think that there is a good chance this will
break playback completely for some files.
At least the FFmpeg demuxer seems to think that parsing is required.

> Index: mplayer/libmpcodecs/dec_video.c
> ===================================================================
> --- mplayer/libmpcodecs/dec_video.c	(revision 35107)
> +++ mplayer/libmpcodecs/dec_video.c	(working copy)
> @@ -404,7 +404,7 @@
>  
>      delay = get_current_video_decoder_lag(sh_video);
>      if (correct_pts && pts != MP_NOPTS_VALUE
> -        && (got_picture || sh_video->num_buffered_pts < delay)) {
> +        && (mpi || sh_video->num_buffered_pts < delay)) {
>          if (sh_video->num_buffered_pts ==
>              sizeof(sh_video->buffered_pts) / sizeof(double))
>              mp_msg(MSGT_DECVIDEO, MSGL_ERR, "Too many buffered pts\n");
> @@ -433,6 +433,9 @@
>      tt = t * 0.000001f;
>      video_time_usage += tt;
>  
> +    if (mpi && drop_frame && sh_video->num_buffered_pts)
> +	sh_video->num_buffered_pts--;
> +

Wouldn't it be simpler, more correct and also remove the need for the change in
mplayer.c to just remove the
    if (!mpi || drop_frame)
            return NULL;
code and do a return drop_frame ? NULL : mpi; at the end instead?
(plus changes necessary to not crash for mpi == NULL of course).