command: vf-metadata: minor fixup of return status

Signed-off-by: wm4 <wm4@nowhere>
vf_vapoursynth: wipe vapoursynth state completely on reloading

Before this commit, the filter attempted to keep the vsscript state
(p->se) even when the script was reloaded. Change it to destroy the
script state too on reloading. Now no workaround for LoadPlugin is
necessary, and this also fixes a weird theoretical race condition when
destroying and recreating the mpv source filter.
New option --no-ometadata to opt out of including metadata when encoding.

This re-allows the previous behaviour of being able to reencode with
metadata removed, which is useful when encoding "inconsistently" tagged
data for a device/player that shows file names when tags are not
present.
video: change image format names, prefer mostly FFmpeg names

The most user visible change is that "420p" is now displayed as
"yuv420p". This is what FFmpeg uses (almost), and is also less confusing
since "420p" is often confused with "420 pixels vertical resolution".

In general, we return the FFmpeg pixel format name. We still use our own
old mechanism to keep a list of exceptions to provide compatibility for
a while.

Also, never return NULL for image format names. If the format is unset
(0/IMGFMT_NONE), return "none". If the format has no name (probably
never happens, FFmpeg seems to guarantee that a name is set), return
"unknown".
options: don't allow --no-foo=yes

It's a bit strange to allow this, so get rid of it.

This probably breaks a bunch of user config files.

The client API still allows setting them with MPV_FORMAT_FLAG with a
value of 1 (i.e. true), but I guess this is tolerable.
vf_vapoursynth: handle destruction more gracefully

We were relying on vsscript_freeScript() to take care of proper
termination. But it doesn't do that: it doesn't wait for the filters to
finish and exit at all. Instead, it just destroys all objects, which
causes the worker threads to crash sometimes.

Also, we're supposed to wait for the frame callback to finish before
freeing the associated node.

Handle this by explicitly waiting as far as we can. Probably fixes
crashes on seeking, although VapourSynth itself might also need some
work to make this case completely stable.
command: add a property to indicate core pause state

Currently this is (probably) equivalent to "paused-for-cache", but the
latter is a bit special, while this new property is a bit more general.
One case where they might actually be different is dvdnav menus, but I
haven't checked.

Also add property change notifications for these two properties.
command: add property to indicate when pausing due to --keep-open

This property is set to "yes" if playback was paused due to --keep-open.

The change notification might not always be perfect; maybe that should
be improved.
client API: remove mpv_event_pause_reason

And slightly adjust the semantics of MPV_EVENT_PAUSE/MPV_EVENT_UNPAUSE.

The real pause state can now be queried with the "core-idle" property,
the user pause state with the "pause" property, whether the player is
paused due to cache with "paused-for-cache", and the keep open event can
be guessed with the "eof-reached" property.
README: mention minimum FFmpeg/Libav versions
video: remove use of deprecated AVFrame fields on Libav

qscale export has been completely removed from Libav 10, and FFmpeg has
an alternative API, so this code does nothing and only causes
deprecation warnings on Libav.
audio: wake up the core when audio buffer is running low

And also add a function ao_need_data(), which AO drivers can call if
their audio buffer runs low.

This change intends to make it easier for the playback thread: instead
of making the playback thread calculate a timeout at which the audio
buffer should be refilled, make the push.c audio thread wakeup the core
instead.

ao_need_data() is going to be used by ao_pulse, and we need to
workaround a stupid situation with pulseaudio causing a deadlock because
its callback still holds the internal pulseaudio lock.

For AOs that don't call ao_need_data(), the deadline is calculated by
the buffer fill status and latency, as before.
ao_pulse: use ao_need_data()

I'm not quite sure why ao_pulse needs this. It was broken when a thread
to fill audio buffers was added to AO - the pulseaudio callback was
waking up the playback thread, not the audio thread. But nobody noticed,
so it can't be very important. In any case, this change makes it wake up
the audio thread instead (which in turn wakes up the playback thread if
needed).
audio: wake up the core when audio buffer is running low (2)

Same change as in e2184fcb, but this time for pull based AOs. This is
slightly controversial, because it will make a fast syscall from e.g.
ao_jack. And according to JackAudio developers, syscalls are evil and
will destroy realtime operation. But I don't think this is an issue at
all.

Still avoid locking a mutex. I'm not sure what jackaudio does in the
worst case - but if they set the jackaudio thread (and only this thread)
to realtime, we might run into deadlock situations due to priority
inversion and such. I'm not quite sure whether this can happen, but I'll
readily follow the cargo cult if it makes hack happy.
player: remove audio waiting

The audio subsystem now wakes up the playback thread explicitly, and we
don't need this anymore.

It still could cause dropouts and such if there are bugs in the recently
introduced audio changes, so this is a thing to watch out for.
input: deal with playback thread wakeup on windows

The recent change of waking up the playback thread using a wakeup pipe
doesn't work on windows, because windows is horrible. So use a condition
variable instead to wake up the thread. To make things worse, jackaudio
is also horrible and "disallows" the use of mutexes, so all we can do is
implementing a half-solution that is not race condition free.

It would probably better to give up on this lock-free crap in the pull-
API audio path.

Mostly untested.
af_lavcac3enc: detach on any passthrough format, not just ac3