coreaudio_device: fix overwriting of user input

Fixes #1030
player: minor changes

This shouldn't change anything functionally.

Change the A/V desync message. --framedrop is enabled by default now, so
the text must be changed a little. I've never heard of audio outputs
messing up A/V sync recently, so remove that part.

Remove the unused ao_pts field.

Reorder 2 A/V sync related expressions so that they look the same.
input: stdin is 0, not 1

Oops. I can never remember this right.
manpage: mention that mp.commandv doesn't expand properties

The little lua snippet at #488 as well as the actual implementation
seems to indicate that not expanding properties is indeed the correct
behavior.  Document that.

Signed-off-by: wm4 <wm4@nowhere>
input: make all modifier flags unsigned
input: make key bindings like "Shift+X" work (for ASCII)

"Shift+X" didn't actually map any key, as opposed to "Shift+x". This is
because shift usually changes the case of a character, so a plain
printable character like "X" simply can never be combined with shift.

But this is not very intuitive. Always remove the shift code from
printable characters. Also, for ASCII, actually apply the case mapping
to uppercase characters if combined with shift. Doing this for unicode
in general would be nice, but that would require lookup tables. In
general, we don't know anyway what character a key produces when
combined with shift - it could be anything, and depends on the keyboard
layout.
player: fix weird behavior when framestepping over format changes

When video format changes, the frame before the frame with the new
format sets video_status briefly to STATUS_DRAINING. This caused the
code to handle the EOF case to kick in, which just pauses the player
when trying to step past the last frame. As a result, trying to
framestep over format changes resulted in pausing the player.

Fix by testing against the correct status.
TOOLS: youtube wrapper: allow overriding mpv binary
vo_opengl: add spline64 filter kernel

The coefficients are taken from fmtconv plugin for vapoursynth:
https://github.com/vapoursynth/fmtconv/blob/master/src/fmtc/ContFirSpline64.cpp

The package is licensed under WTFPL, and it's from the same author
of Dither plugin for avisynth.
vo_opengl: add cparam1 and cparam2 options

Although cscale is rarely used, it's possible that params of cscale
are accidentally set to lparam1 and lparam2, which might cause
unexpected results.
vo_opengl: add radius options for filters

Add two new options, make it possible for user to set the radius
for some of the filters with no fixed radius.

Also add three new filters with the new radius parameter supported.
 vo_opengl: add parameter to gaussian filter

 Add a new parameter 'p' to gaussian filter. The new formula used
 a different base taken from fmtconv plugin, so that the
 new parameter is exactly same as the one used in Avisynth and
 Vapoursynth.

 The new default value is 2 / log(2) * 10, with the default value it
 conforms to the original kernel taken from vector-agg.
demux: reduce wakeups if no cache is active

The purpose of the unconditional pthread_cond_signal() when reading
cached DEMUXER_CTRLs and STREAM_CTRLs was apparently to update the
stream cache state. Otherwise, the cached fields would never be updated
when the stream is e.g. paused.

The same could be said about other CTRLs, but these aren't as important,
since they are normally updated while reading packet data.

In order to reduce wakeups, make this logic explicit.
player: redo how stream caching and pausing on low cache works

Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.

Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.

Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
player: fix basic playback

The "buffering" logic was active even if the stream cache was disabled.
This is contrary to what the manpage says. It also breaks playback
because of another bug: the demuxer cache is smaller than 2 seconds,
and thus the resume condition never becomes true.

Explicitly run this code only if the stream cache is enabled. Also, fix
the underlying problem of the breakage, and resume when the demuxer
thread stops reading in any case, not just on EOF.

Broken by previous commit. Unbreaks playback of local files.
player: better cache status on status line

The cache percentage was useless. It showed how much of the total stream
cache was in use, but since the cache size is something huge and
unrelated to the bitrate or network speed, the information content of
the percentage was rather low.

Replace this with printing the duration of the demuxer-cached data, and
the size of the stream cache in KB.

I'm not completely sure about the formatting; suggestions are welcome.
Note that it's not easy to know how much playback time the stream cache
covers, so it's always in bytes.
demux: reset idle state on seeks
demux_lavf: don't reject av:// if cache is enabled

Enabling the cache doesn't make much in this situation, but there's also
no reason not to reject it.
player: slightly better cache underrun detection

Use the "native" underrun detection, instead of guessing by a low cache
duration. The new underrun detection (which was added with the original
commit) might have the problem that it's easy for the playloop to miss
the underrun event. The underrun is actually not stored as state, so if
the demuxer thread adds a new packet before the playloop happens to see
the state, it's as if it never happened. On the other hand, this means
that network was fast enough, so it should be just fine.

Also, should it happen that we don't know the cached range (the
ts_duration < 0 case), just wait until the demuxer goes idle (i.e.
read_packet() decides to stop). This pretty much should affect broken or
unusual files only, and there might be various things that could go
wrong. But it's more robust in the normal case: this situation also
happens when no packets have been read yet, and we don't want to
consider this as reason to resume playback.
player: dynamically change cache wait times

Remove the hardcoded wait time of 2 seconds. Instead, adjust the wait
time each time we unpause: if downloading the data took longer than its
estimated playback time, increase the amount of data we wait for. If
it's shorter, decrease it.

The +/- is supposed to avoid oscillating between two values if the
elapsed time and the wait time are similar. It's not sure if this
actually helps with anything, but it can't harm.