[PATCH] Fix wrong elapsed time due to MPEG-TS PTS rollover

[Basic.Master]

[after I realized that the last patch posted there was from 2012, so this fotum seems to be the better place]

MPEG-TS files (e.g. DVB recordings) have a 2^33 wide PTS (playback timestamp) value regularly embedded, which is used by MPlayer to output the current time. As this timestamp is not (necessarily) 0 at the start of the file, in SMPlayer mset.starting_time is subtracted from mset.current_sec to get the elapsed time since the file start.

This only works if mset.current_sec > mset.starting_time is valid. But if between the file start and the current position there is a PTS rollover, this leads to a negative value displayed by SMPlayer.

The attached patch fixes this issue by compensating this PTS rollover. You can find a test MPEG-TS file at which is 20s long and has a PTS rollover at 10s.

[rvm]

I've just applied your patch (svn r6885).

[Basic.Master]

[rvm]

The change was several months ago, I think I don't remember the reason. Maybe mpv doesn't work well with it.

[Basic.Master]

Hmm, in that case it would be great if the #define could be re-enabled so that everybody with mplayer benefits from having a correct position within a MPEG-TS.

[rvm]

Could you provide a sample video where this patch is needed? The link you provided on your first post doesn't work anymore. I'd like to test it with mpv.

[Basic.Master]

I just reuploaded the file; the link works again now. Without the #define and with mplayer, the video starts at about position 26:30:04.

[Basic.Master]

Have you possibly been able to test it with mpv?

[rvm]

Your sample video plays fine (correct time from 0 to 20 seconds) in mpv without the patch. So I think that maybe the problem should actually be fixed in mplayer, since mpv seems to already include a fix, instead of adding a workaround in smplayer.