[MPlayer-dev-eng] GetTimerMS overflow

[Reimar Döffinger]

On 02.03.2014, at 18:03, Jarek Czekalski <jarekczek at poczta.onet.pl> wrote:
> While working on the bug #2174 [1] I discovered that timestamp handling in mplayer is probably broken.
> 
> 1. It is vulnerable to time changes (daylight saving) twice a year
> 2. It suffers from overflows
> 
> Ad. 1
> Monotonic clock should be used instead of real time clock. That is get_clocktime(CLOCK_MONOTONIC) [2] instead of gettimeofday [3]

That is a (mostly, though on the other hand it is even problematic there) Linux-specific solution. MPlayer should be made robust against timestamp changes, as far as it is not yet.
If then issues remain, such a solution can be considered, but a solution that works only on one system rather increases maintenance and debug issues than really solve much.

> Ad. 2
> long long values should hold number of milli- and microseconds, as it is done in stream/tvi_v4l2.c. The private library function GetTimerMS (osdep/timer-linux.c) uses unsigned int for this purpose. This easily overflows, because current time in seconds is 1 393 778 888, which hardly fits in 32-bit integer. After multiplying by 1K or 1M we are overflowed. If my calculations are correct, that means GetTimerMS starts from 0 every 4000 seconds.

Which is completely irrelevant and not an issue as long as it is used correctly (as in: only used to track reasonably small time deltas), not to mention that it ensures compatibility with systems that only have 32 bit high-resolution timers.

> [1] https://trac.mplayerhq.hu/ticket/2174

I don't see the connection.