summaryrefslogtreecommitdiffstats
path: root/osdep/timer.c
Commit message (Collapse)AuthorAgeFilesLines
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* timer: fix a corner case on clock changeswm42015-07-041-1/+4
| | | | | | | | | | | | | | | | It's conceivable that the OS time source is subject to clock changes. The time could jump back to before when mpv was started, which would cause mp_time_us() to return values smaller than 1. This is unexpected by the code and could trigger assertions. If there's no monotonic time source there's not much we can do anyway, so just sanitize the return value. It will cause strange behavior until the "lost" time offset has passed, but if you make such huge changes to the system clock while everything is running, you're asking for trouble anyway. (Normally we try to get a monotonic time source, though. This problem sometimes happened on Windows when compiled without winpthreads, when the code was falling back to gettimeofday(). This was already fixed by always using another method.)
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-111-1/+7
| | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.)
* timer: add "static" to a variablewm42015-05-011-1/+1
|
* msg: add --log-file optionwm42015-01-261-1/+1
| | | | | | | | | This allows getting the log at all with --no-terminal and without having to retrieve log messages manually with the client API. The log level is hardcoded to -v. A higher log level would lead to too much log output (huge file sizes and latency issues due to waiting on the disk), and isn't too useful in general anyway. For debugging, the terminal can be used instead.
* timer: remove unneeded time_t overflow checkwm42014-05-241-12/+1
| | | | | | | This is mostly covered by the OSX workaround, if the timeout is very high. It also means that with systems using 32 bit time_t, the time will overflow 2036 already, instead of 2037, but we don't consider this a problem.
* timer: workaround for crappy operating systemswm42014-05-231-0/+1
| | | | | | | | | | Some operating systems apparently can't deal with really long timeouts in pthread_cond_timedwait(). Passing a time about 300000 in the future makes the call return immediately. (tv_sec/time_t doesn't overflow in this situation.) Reduce the wait time to about 100 days, which seems to work fine. The list of affected OSes follows: OSX
* timer: fix previous commitwm42014-05-221-1/+1
| | | | | Sigh... of course the type of the (?:) exprsssion is double, so INT64_MAX was converted to double, which is a problem.
* timer: improve overflow checkswm42014-05-221-4/+5
| | | | | | | Probably more correct and better readable. Although the special-casing of 0x1p63 is weird in terms of readability (the value itself is INT64_MAX+1, so it's already outside of range, but INT64_MAX is not exactly representable with double precision).
* timer: fix (usually impossible) timespec.tv_sec overflowwm42014-05-221-1/+13
| | | | | | | This usually can't happen, because even if time_us (first input value) is INT64_MAX, the value added to tv_sec will be about 2^43, and tv_sec will be <2^31, far below a possible overflow in 64 bits. But should time_t be 32 bits (32 bit Linux/Windows?), an overflow could happen.
* timer: account for negative time valueswm42014-05-181-2/+6
| | | | | | | | It can easily happen that mp_time_us_to_timespec() gets a time in the past, and then the time difference will be negative. Regression introduced in commit f47a4fc3. Also fix an underflow check in mp_add_timeout().
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-3/+63
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* timer: add utility function to get relative timewm42014-02-281-0/+11
|
* timer: init only oncewm42014-02-101-1/+8
| | | | | | | | | | This avoids trouble if another mpv instance is initialized in the same process. Since timeBeginPeriod/timeEndPeriod are hereby not easily matched anymore, use an atexit() handler to call timeEndPeriod, so that we can be sure these calls are matched, even if we allow multiple initializations later when introducing the client API.
* Replace calls to usec_sleep()wm42013-05-261-6/+0
| | | | | | This is just dumb sed replacement to mp_sleep_us(). Also remove the now unused usec_sleep() wrapper.
* Replace all calls to GetTimer()/GetTimerMS()wm42013-05-261-10/+0
| | | | | | | | | | | | | | | | | | | | | | GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
* timer: refactor, add 64 bit timer functionwm42013-05-261-0/+82
Make OS specific timer code export a mp_raw_time_us() function, and add generic implementations of GetTimer()/GetTimerMS() using this function. New mpv code is supposed to call mp_time_us() in situations where precision is absolutely needed, or mp_time_s() otherwise. Make it so that mp_time_us() will return a value near program start. We don't set it to 0 though to avoid confusion with relative vs. absolute time. Instead, pick an arbitrary offset. Move the test program in timer-darwin.c to timer.c, and modify it to work with the generic timer functions.