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

[Andy Furniss]

Vicente Sendra wrote:

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

New patch seems OK for the tests I've been doing.

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

Transport streams do seem to be a real pain, while testing I found one 
that messes up with vanilla mplayer (+demuxer lavf and yadif=1) - it 
plays in slow motion and never recovers.
It's just an unlucky start AFAICT as snipping to the first PUSI flagged 
ts packet fixes it (maybe less would do - I didn't try), but the 
recorders/streamers I use don't do that - maybe the ts demuxer should, 
but then I suppose it would loose some video that should work.

> 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

In some ways I think a pause is better to get ts in sync - that's what 
TVs seem to do. I was just looking for differences to vanilla and of 
course the end issue needed fixing.