[MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.

[Vicente Sendra]

--- El lun, 31/12/12, Vicente Sendra <visenri at yahoo.es> escribió:

> De: Vicente Sendra <visenri at yahoo.es>
> Asunto: Re: [MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.
> Para: mplayer-dev-eng at mplayerhq.hu
> Fecha: lunes, 31 de diciembre, 2012 19:33
> --- El sáb, 29/12/12, Andy Furniss
> <andyqos at ukfsn.org>
> escribió:
>  
> > I tried a longer version of the sample I previously
> uploaded
> > and linked in previous reply -
> > 
> > http://www.andyqos.ukfsn.org/judder.m2ts
> >  
> > If I play it with -demuxer lavf (which I would always
> do for
> > ts/m2ts as it tends to get the right sound track and
> better
> > lipsync) it's quite broken.
> > 
> > Initially it starts by alternating 10 sec turns of
> sound
> > then video - ie if there is sound video pauses, when
> video
> > resumes sound stops this continues for the first 70
> seconds,
> > then both play together but well out of sync, which
> takes
> > another minute to sort.
> > 
> > Without -demuxer lavf it seems Ok.
> > 
> > This happens regardless of -vo or vsync settings or
> audio
> > track selected.
> > 
> > I have not tried any new options/filters yet, this is
> just
> > playing a 24fps file on a 60Hz monitor with
> -framedrop.
> 
> I found the problem, it was related to my comment:
> 
> >  In correct-pts mode full_frame should be used to
> check if frame is 
> >  complete and not an interlaced frame.
> 
> But it is not limited to interlaced frames, some times
> decode_video returns without a complete frame because it has
> decoded a frame it needs but it is not the actual frame.
> 
> I declared full_frame in generate_video_frame and changed
> code as follows:
> 
> decoded_frame  = decode_video(sh_video, start, in_size,
> drop_frame, pts, &full_frame);
> 
>         if (decoded_frame) {
>             ....
>         } else {
>             if(full_frame){
>                
> *frame_time = calculate_frame_time_by_pts(sh_video,0);
>                
> process_framedrop(0,*frame_time,drop_frame);
>                
> break;
>             }
>         }
> 
> We do frame stuff only if full frame.
> In your sample, calculate_frame_time_by_pts was called for
> some frames that were not a full_frame, and this resulted in
> an incorrect mpctx->delay.

Just in case anyone is thinking about why doesn't happen with vanilla mplayer, well it does, but in a different way:

original code was like this:

    decoded_frame  = decode_video(sh_video, start, in_size, drop_frame, pts, NULL);
    if (decoded_frame) {
        ...
        if (filter_video(sh_video, decoded_frame, sh_video->pts))
            break;
    } else if (drop_frame)
        return -1;

So it could return with not not a full_frame if drop_frame was set.
mpctx->delay was updated when this function was finished.

In conclusion, it failed (updated mpctx->delay when it should not) only if a framedrop was triggered in frames that were not full frames.