DOCS: fix an external link

This got lost in commit b980884f.
timer: switch to CLOCK_MONOTONIC

Apparently, this is always _really_ monotonic, despite what the Linux
manpages say. So this should be much better than gettimeofday(). (At
times there were kernel bugs which broke the monotonic property.)

From the perspective of the player, time can still be discontinuous
(you could just stop the process with ^Z), but at least it's guaranteed
to be monotonic without further hacks required.

Also note that clock_gettime() returns the time in nanoseconds. We want
microseconds only, because that's the unit we chose internally. Another
problem is that nanoseconds can wrap pretty quickly (less than 300 years
in 63 bits), so it's just better to use microseconds. The devision won't
make the code that much slower (compilers can avoid a real division).

Note: this expects that the system provides clock_gettime() as well as
CLOCK_MONOTONIC. Both are optional according to POSIX. The only system
I know which doesn't have these, OSX, has seperate timer code anyway,
but I still don't know whether more obscure (yet supported) platforms
have a problem with this, so I'm playing safely. But this still expects
that CLOCK_MONOTONIC always works at runtime if it's defined.
timer: reduce ifdef headsplitting-factor

I'd rather duplicate some trivial code, rather than split functions in
the middle with ifdefs.
ao_sdl: use new pull API helpers

One strange issue is that we apparently can't stop the audio API on
audio reset (ao_driver.reset). We could use SDL_PauseAudio, but that
doesn't specify whether remaining audio is dropped. We also could use
SDL_LockAudio, but holding that over a long time will probably be bad,
and it probably doesn't drop audio. This means we simply play silence
after a reset, instead of stopping the callback completely. (The
existing code ran into an underrun in this situation.)

The delay estimation works about the same. We simply assume that the
callback is locked to audio timing (like ao_jack), and that 1 callback
corresponds to 1 period. It seems this (removed) code fragment assumes
there 1 one period size delay:

// delay subcomponent: remaining audio from the next played buffer, as
// provided by the callback
buffer_interval += callback_interval;

so we explicitly do that too.
build: fix compilation with MinGW-w64

References to WinMM/OLE/UUID were missing.

Signed-off-by: wm4 <wm4@nowhere>
ao_rsound: pass correct data type to rsd_set_param()

Signed-off-by: wm4 <wm4@nowhere>
ao_wasapi: Use double math for QueryPerformanceCounter correction

The uint64_t math would cause overflow at long enough system uptimes
(...such as 3 days), and any precision error given by the double math will
be under one milisecond.
ao_alsa: check ALSA PCM state before pause and resume

It is possible to have ao->reset() called between ao->pause() and
ao->resume() when seeking during the pause. If the underlying PCM
supports pausing, resuming an already reset PCM will produce an error.
Avoid that by explicitly checking PCM state before calling
snd_pcm_pause().

Signed-off-by: wm4 <wm4@nowhere>
ao_alsa: remove unneeded initializations

priv is 0-initialized, can_pause is always overwritten later.
audio/out: reduce amount of audio buffering

Since the addition of the AO feed thread, 200ms of latency (MIN_BUFFER)
was added to all push-based AOs. This is not so nice, because even AOs
with relatively small buffering (e.g. ao_alsa on my system with ~170ms
of buffer size), the additional latency becomes noticable when e.g.
toggling mute with softvol.

Fix this by trying to keep not only 200ms minimum buffer, but also 200ms
maximum buffer. In other words, never buffer beyond 200ms in total. Do
this by estimating the AO's buffer fill status using get_space and the
initially known AO buffer size (the get_space return value on
initialization, before any audio was played). We limit the maximum
amount of data written to the soft buffer so that soft buffer size and
audio buffer size equal to 200ms (MIN_BUFFER).

To avoid weird problems with weird AOs, we buffer beyond MIN_BUFFER if
the AO's get_space requests more data than that, and as long as the soft
buffer is large enough.

Note that this is just a hack to improve the latency. When the audio
chain gains the ability to refilter data, this won't be needed anymore,
and instead we can introduce some sort of buffer replacement function in
order to update data in the soft buffer.
ao_alsa: fix return value for volume operations with spdif

This AO pretended to support volume operations when in spdif passthrough
mode, but actually did nothing. This is wrong: at least the GET
operations must write their argument. Signal that volume is unsupported
instead.

This was probably a hack to prevent insertion of volume filters or so,
but it didn't work anyway, while recovering after failed volume filter
insertion does work, so this is not needed at all.
ao_alsa: reduce default buffer size

In general, we don't need to have a large hw audio buffer size anymore,
because we can quickly fill it from the soft buffer.

Note that this probably doesn't change much anyway. On my system (dmix
enabled), the buffer size is only 170ms, and ALSA won't give more. Even
when using a hardware device the buffer size seems to be limited to
341ms.
m_option: fix handling of empty channel layouts

Even if a channel map option signaled that empty layouts are accepted,
the option parser never actually accepted them.
audio: make --channels option always force the output layout

Use the --channels value directly on the AO, instead of doing it only in
the --channels=stereo (default) case and if the decoder output is not
stereo.
audio: don't downmix when doing digital passthrough

This obviously doesn't work. It wasn't much of a problem in the past
because most passthrough formats use 2 channels, which is also the
default for downmix.
ao_sdl: make sure our buffer is always larger than what SDL requests

Assume obtained.samples contains the number of samples the SDL audio
callback will request at once. Then make sure ao.c will set the buffer
size at least to 3 times that value (or more).

Might help with bad SDL audio backends like ESD, which supposedly uses a
500ms buffer.
vo_opengl: Use bt709_expand on OSD for :srgb

This affects the OSD only when :srgb is enabled, this still used the old
gamma approximation of 2.22 previously.
vo_opengl: Simplify and clarify color correction code

This commit:

- Changes some of the #define and variable names for clarification and
  adds comments where appropriate.
- Unifies :srgb and :icc-profile, making them fit into the same step of
  the decoding process and removing the weird interactions between both
  of them.
- Makes :icc-profile take precedence over :srgb (to significantly reduce
  the number of confusing and useless special cases)
- Moves BT709 decompanding (approximate or actual) to the shader in all
  cases, making it happen before upscaling (instead of the old 0.45
  gamma function). This is the simpler and more proper way to do it.
- Enables the approx gamma function to work with :srgb as well due to
  this (since they now share the gamma expansion code).
- Renames :icc-approx-gamma to :approx-gamma since it is no longer tied
  to the ICC options or LittleCMS.
- Uses gamma 2.4 as input space for the actual 3DLUT, this is now a
  pretty arbitrary factor but I picked 2.4 mainly because a higher pure
  power value here seems to produce visually better results with wide
  gamut profiles, rather then the previous 1.95 or BT.709.
- Adds the input gamma space to the 3dlut cache header in case we change
  it more in the future, or even make it user customizable (though I
  don't see why the latter would really be necessary).
- Fixes the OSD's gamma when using :srgb, which was previously still
  using the old (0.45) approximation in all cases.
- Updates documentation on :srgb, it was still mentioning the old
  behavior from circa a year ago.

This commit should serve to both open up and make the CMS/shader code much
more accessible and less confusing/error-prone and simultaneously also
improve the performance of 3DLUTs with wide gamut color spaces.

I would liked to have made it more modular but almost all of these
changes are interdependent, save for the documentation updates.

Note: Right now, the "3DLUT takes precedence over SRGB" logic is just
coded into gl_lcms.c's compile_shaders function. Ideally, this should be
done earlier, when parsing the options (by overriding the actual
opts.srgb flag) and output a warning to the user.

Note: I'm not sure how well this works together with real-world
subtitles that may need to be color corrected as well. I'm not sure
whether :approx-gamma needs to apply to subtitles as well. I'll need to
test this on proper files later.

Note: As of now, linear light scaling is still intrinsically tied to
either :srgb or :icc-profile. It would be thinkable to have this as an
extra option, :linear-scaling or similar, that could be used with or
without the two color management options.
vo_opengl: Correct and clarify gl_check_features

This updates the logic for the new, somewhat unified behavior of SRGB
and 3DLUT since 34bf9be (not that it was particularly correct even that
change) and checks for the presence of corresponding extensions only in
the cases in which they're needed.
video: initialize hw decoder in get_format

Apparently the "right" place to initialize the hardware decoder is in
the libavcodec get_format callback.

This doesn't change vda.c and vdpau_old.c, because I don't have OSX, and
vdpau_old.c is probably going to be removed soon (if Libav ever manages
to release Libav 10). So for now the init_decoder callback added with
this commit is optional.

This also means vdpau.c and vaapi.c don't have to manage and check the
image parameters anymore.

This change is probably needed for when libavcodec VDA supports gets a
new iteration of its API.