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

[Vicente Sendra]

--- El jue, 10/1/13, Andy Furniss <andyqos at ukfsn.org> escribió:

> De: Andy Furniss <andyqos at ukfsn.org>
> Asunto: Re: [MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.
> Para: mplayer-dev-eng at mplayerhq.hu
> CC: "Vicente Sendra" <visenri at yahoo.es>
> Fecha: jueves, 10 de enero, 2013 01:15
> Andy Furniss wrote:
> 
> > Testing an old mpeg2 transport stream I am seeing an
> initial pause with
> > lavf/correct-pts - this happens with previous version
> of mplayer.c patch
> > as well
> 
> Here's a 10 meg sample - blanks 1-2 sec at the start and by
> luck my 10meg dd chop has shown another issue at the end -
> it doesn't quit.
> 
> -vo doesn't matter happens with tfielsd/yadif=1 doesn't
> happen with vanilla mplayer. needs -correct-pts/-demuxer
> lavf eg.
> 
>  -vf yadif=1 -correct-pts -vo xv -framedrop slow-start.ts
> 
> http://www.andyqos.ukfsn.org/slow-start.ts

What really triggers the problem is just -correct-pts combined with the frame decoding errors that this file has.

I've solved it with a modification of the last correction:


> 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.


This time the problem was that full_frames were parsed, but no decoding was done because of broken file. Calculate_frame_time_by_pts was called for some frames that were broken, and this resulted in an incorrect mpctx->delay

changing code like this solves the problem:

-------------------------------------------------------
          if (decoded_frame) {
              ....
          } else {
              if(full_frame && drop_frame){
                  *frame_time = calculate_frame_time_by_pts(sh_video,0);
                  process_framedrop(0,*frame_time,drop_frame);
                  break;
              }
          }
-------------------------------------------------------

Now video is played like vanilla mplayer.
The quitting problem is solved too with this little change.

There is a little difference in the A/V sync behavior at the start of the file between using a filter like yadif=1 and not using it, it has to do something with getting video PTS from VO, i'll take a deeper look at this tomorrow.

With yadif=1 it plays instantaneously and slowly sync with video (like vanilla mplayer).
Without it video waits for just a second.

Both get in sync correctly, just in a different way



The file attached is the new updated patch to apply over r35689.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer.c.diff
Type: application/octet-stream
Size: 47645 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20130111/5775ad2c/attachment-0001.obj>