[MPlayer-dev-eng] [PATCH] reorder pts when needed

[Reimar Döffinger]

On Sun, Nov 27, 2011 at 06:13:44PM +0100, Dan Oscarsson wrote:
> sön 2011-11-27 klockan 16:03 +0100 skrev Reimar Döffinger:
> > What do you consider "slightly bad" when out of order doesn't qualify?
> 
> The pts value is off by some milliseconds from correct value. Like some
> demuxers/decoders do, for example som combinations of .avi and mp3 audio
> where pts values goes + some time, and then - some time, around correct
> value. That I can correct or reduce so mplayer do not have to move
> display of frame forward/backward from correct time, all the time to
> compensate for drifting pts values.
> When pts values are out of order, they can jump around 100 ms or more.
> 
> > If it can handle actually corrupted pts values I'd expect it should
> > handle reordering as well, at most hierarchical B might cause problems.
> 
> It is difficult to know if it is a corrupt pts value or a change in the
> stream where a new sequence of pts value occur, so my code cannot
> correct if the pts values jump around with big value changes (and by big
> I mean about 70-100 ms or more.

First, I do not see where the difference here is between big and small
value changes, you don't know in either case whether the jump (differing
from 1/fps) is an error or intended.
The only difference I see is how much the user notices if you guess
wrong.
Also you can be fairly certain if either
1) you check the following PTS
2) you apply "large" changes with 1 frame delay (where I'd consider
anything < 0.5/fps or > 1.5/fps as large)

The point of -nocorrect-pts mode is to be based on FPS first of all,
the fact that single incorrect pts matter so much seems to indicate
that for some reason it no longer properly fulfills that point.
I guess this is caused in part by the code removal but also in
combination with a higher default -mc value.