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