player: reset last_av_difference if not applicable

Don't let stale values linger around.

Also fix a slightly related case in audio.c.
player: use backwards flag for seeking external tracks

Otherwise, the external track could end up at a position that's too
late.
player: make code more obvious

Or at least I think so.
video: improve decoder-based framedropping mode

This is the "old" framedropping mode (derived from MPlayer). At least in
the mplayer2/mpv source base, it stopped working properly years ago (or
maybe it never worked properly). For one, it depends on the video
framerate, which assume constant framerate. Another problem was that it
could lead to freezing video display: video could get so much behind
that it couldn't recover from framedrop.

Make some small changes to improve this.

Don't use the current audio position to check how much we are behind.
Instead, use the last known A/V difference. last_av_difference is
updated only when a video frame is scheduled for display. This means we
can keep stop dropping once we're done catching up, even if video is
technically still behind. What helps us here that this forces a video
frame to be displayed after a while. Likewise, we reset the
dropped_frames count only when scheduling a new frame for display as
well.

Some inspiration was taken from earlier work by xnor (see issue #620),
although the implementation turned out quite different.

This still uses the demuxer-reported (possibly broken) FPS value. It
also doesn't account for filters changing FPS. We can't do much about
this, because without decoding _and_ filtering, we just can't know how
long a frame is. In theory, you could derive that from the raw packet
timestamps and the filter chain contents, but actually doing this is
too involved. Fortunately, the main thing the FPS affects is actually
the displayed framedrop count.
video: actually count decoder-dropped frames

Normally, feeding a packet to the decoder should always return a frame
_if_ we received a frame before. So while we can't know exactly whether
a frame was dropped, at least the normal case is easily detectable.

This means we display something closer to the actual framedrop count,
instead of a bad guess.
player: rename "Late:" field to "SD:"

Follow up to previous commit.

This is probably confusing from a user point of view, since this field
shouldn't show up normally anymore. (Before this commit, it could show
up sporadically when a slow operation was performed during playback,
such as switching fullscreen.)
manpage: document terminal status line components

(The classic MPlayer documentation had this in separate files, but we
deleted them ages ago.)
mixer: always restore volume (even with pulse), don't unmute

Be less clever, and restore the volume state even with AOs like pulse,
which have per-application audio.

Before this commit we didn't do this, because the volume is global (even
if per-application), so the volume will persist between invocations. But
to me it looks like always restoring is less tricky and makes for easier
to understand semantics.

Also, don't always unmute on exit. Unmuting was done even with ao_pulse,
and interfered with user expectations (see #1107).

This might annoy some users, because mpv will change the volume all the
time. We will see.

Fixes #1107.
osdep: hack to fix build with low quality pthreads-w32 headers

When compiling semaphore_osx.c on win32, the following error happened:

/usr/i686-w64-mingw32/include/semaphore.h:160:6: error: unknown type name 'mode_t'

This is because this system header references symbols that are not
not defined anywhere. This is clearly a bug in pthreads-w32, but has
been known and unfixed since 2012, so add a hack to fix it.

We build semaphore_osx.c this way because it saves us an extra configure
check. On win32, Linux, etc. it's empty and contains
"#include <semaphore.h>" only.

Should fix #1108.
input: explain why we use semaphores

Also switch function names for better self-documentation.
vo_vdpau: fix confusion around vsync_interval

vc->vsync_interval and vsync_interval should be the same value, but
actually vc->vsync_interval was updated after vsync_interval was
initialized. This was probably not intended. Fix this by removing the
duplicate local variable. There were probably no bad effects.
vo_vdpau: better integration with the generic framedrop code

vo_vdpau uses its own framedrop code, mostly for historic reasons. It
has some tricky heuristics, of which I'm not sure how they work, or if
they have any effect at all, but in any case, I want to keep this code
for now. One day it might get fully ported to the vo.c framedrop code,
or just removed.

But improve its interaction with the user-visible framedrop controls.
Make --framedrop actually enable and disable the vo_vdpau framedrop
code, and increment the number of dropped frames correctly.

The code path for other VOs should be equivalent. The vo_vdpau behavior
should, except for the improvements mentioned above, be mostly
equivalent as well. One minor change is that frames "shown" during
preemption are always count as dropped.

Remove the statement from the manpage that vo_vdpau is the default; this
hasn't been the case for a while.
TOOLS/umpv: use MPV environment variable, not UMPV_OPTIONS

Just like the rest of TOOLS/*.sh scripts.
TOOLS/umpv: print error message to stderr
TOOLS/umpv: make URL detection consistent with mpv method

See mp_is_url in options/path.c.
video: fix some vo_direct3d crashes due to FFmpeg nonsense

For incomprehensible reasons, AV_PIX_FMT_GRAY8 (and some others) have a
palette. This literally makes no sense and this issue has bitten us
before, but it is how it is.

This also caused a crash with vo_direct3d: this mapped a texture as
IMGFMT_Y8 (i.e. AV_PIX_FMT_GRAY8), and when copying this, it tried to
copy the non-existent palette.

Fixes #1113.
video: fix redrawing when pausing after framedrop

When pausing after a frame was just dropped, we're logically at the
dropped frame, and thus should redraw the dropped frame. This was
implemented, but didn't work after unpausing for the second time,
because of a minor logic bug.
manpage: clarify vf_pp docs

Make the note about quoting more prominent.
Add a warning that this filter is useless for new files.
TOOLS: idet: remove extra '$' in $(()) expansion
options: remove --volstep

It's just confusing; users are encouraged to edit input.conf instead
(changing the argument to the "add" command).

Update input.conf to keep the old behavior.