[MPlayer-dev-eng] Re: [PATCH] dvr-ms fixes for pts, key frame detection and seeking

[John Donaghy]

> As I said sh_video->fps doesn't matter all that much, so "it getting
> messed up" should not be a big problem. If there are real problems with
> playback then it sounds like either the fps value you're using for
> creating the pts or the pts value read later is wrong, so that
> number_of_frames * fps_based_frame_distance doesn't match the new pts.
> Or do you mean you're using the same fps value in you code and it
> getting changed (at pts discontinuities?) by other code breaks your
> code? If so then just keep an internal copy.


Based on earlier posts on this thread Michael Niedermayer changed the lavf
demuxer to use the newly discovered dvr-ms pts values when they are present.
When they are not present the demuxer returns a pts of zero. And it works
perfectly because the DEMUXER_TYPE_LAVF case limb in video.c only does
something if sh_video->fps==1000.

So, mimicking this approach I can now get dvr-ms playback working perfectly
by using the new pts values found in the container as long as I:
a) set sh_video->fps correctly at the start (which I can do from the
container alone now), and
b) change video.c to something like:

      case DEMUXER_TYPE_ASF: {
        if (!asf->is_dvr-ms) {
        double next_pts = ds_get_next_pts(d_video);
        double d= (next_pts != MP_NOPTS_VALUE) ? next_pts - d_video->pts :
d_video->pts-pts1;
        if(d>=0){
          if(d>0){
            if((int)sh_video->fps==1000)
              mp_msg(MSGT_CPLAYER,MSGL_V,"\navg. framerate: %d
fps             \n",(int)(1.0f/d));
        sh_video->frametime=d; // 1ms
            sh_video->fps=1.0f/d;
      }
          frame_time = d;
        } else {
          mp_msg(MSGT_CPLAYER,MSGL_WARN,"\nInvalid frame duration value
(%5.3f/%5.3f => %5.3f). Defaulting to %5.3f
sec.\n",d_video->pts,next_pts,d,frame_time);
          // frame_time = 1/25.0;
        }
      }
      }
      break;

If, instead I try to supply missing pts values based on the framerate it
doesnt always work. The problem arises when the first few timestamps are
missing in the video stream but not in the audio stream. E.g from the sample
I posted that only contains intermittent pts values:

pts video: 0.000
pts video: 0.000
pts video: 0.000
pts video: 0.000
pts audio: 290.584
pts audio: 290.608
pts audio: 290.632
pts audio: 290.656
pts audio: 290.680
pts video: 0.000
pts video: 0.000
pts video: 0.000
pts video: 0.000
pts video: 0.000
pts audio: 290.704
pts audio: 290.776
pts audio: 290.800
pts audio: 290.824
pts audio: 290.848
pts audio: 290.872
pts audio: 290.896
pts video: 0.000
pts audio: 290.920
pts video: 291.195   <<<<<<<< first useful video pts
pts video: 0.040
pts video: 0.080
pts audio: 290.944
pts audio: 290.968
pts audio: 290.992
pts audio: 291.016
pts audio: 291.040
pts audio: 291.064
pts audio: 291.088
pts video: 0.000
pts video: 291.235
pts video: 291.275
pts video: 0.000
pts video: 291.355
pts audio: 291.112

I dont know what pts to assign to those first few video frames because if I
use (0.00, 0.04, 008..etc) it causes sync issues. The only solution I can
think of at this point, that doesnt involve a change to video.c, is to
somehow buffer the first few video frames and then retrospectively set the
pts values by interpolating downwards after I first the first useful one.

Exactly how does seeking "not work at all" with -correct-pts?


The video freezes after a seek but I havent had time to investigate why
exactly, plus the AV sync is often out with this option.