[MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.
Vicente Sendra
visenri at yahoo.es
Tue Jan 1 22:19:53 CET 2013
--- 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.
More information about the MPlayer-dev-eng
mailing list