video: add a "hwdec" property to enable or disable hw decoding at runtime
terminal: fix printing of prefix

This was subtly change in 5cfb18. Revert the change.
dispatch: move into its own source file

This was part of osdep/threads.c out of laziness. But it doesn't contain
anything OS dependent. Note that the rest of threads.c actually isn't
all that OS dependent either (just some minor ifdeffery to work around
the lack of clock_gettime() on OSX).
dispatch: wakeup target thread when locking/suspending

Without this, it could happen that both the caller thread and the target
thread sleep.
dispatch: fix broken locking

mp_dispatch_queue_process() releases the queue->lock mutex while
processing a dispatch callback. But this allowed mp_dispatch_lock() to
grab the "logical" lock represented by queue->locked. Grabbing the
logical lock is not a problem in itself, but it can't be allowed to
happen while the callback is still running.

Fix this by claiming the logical lock while the dispatch callback is
processed. Also make sure that the thread calling mp_dispatch_lock() is
woken up properly.

Fortunately, this didn't matter, because the locking function is unused.
dispatch: use a real lock for mp_dispatch_lock()

This is much simpler, leaves fairness isues etc. to the operating
system, and will work better with threading-related debugging tools.

The "trick" to this is that the lock can be acquired and held only while
the queue is in suspend mode. This way we don't need to make sure the
lock is held outside of mp_dispatch_queue_process, which would be quite
messy to get right, because it would have to be in locked state by
default.
dispatch: implement timeout

Note that this mechanism is similarly "unreliable" as for example
pthread_cond_timedwait(). Trying to target the exact wait time will just
make it more complex.

The main use case for this is for threads which either use the dispatch
centrally and want mp_dispatch_queue_process to do a blocking wait for
new work, or threads which have to implement timers. For the former,
anything is fine, as long as they don't have to do active waiting for
new works. For the former, callers are better off recalculating their
deadline after every call.
threads: fix function name

Closer to the corresponding standard function pthread_cond_timedwait.
dispatch: improve documentation comments
audio: minor simplification in wait code
cache: remove redundant log prefix
ao_coreaudio: add verbose output of detected channel layouts

This can be useful for debugging purposes.
dispatch: wakeup only if needed on mp_dispatch_resume()

The wakeup is needed to make mp_dispatch_queue_process() return if
suspension is not needed anymore - which is only the case when the
request count reaches 0.

The assertion added with this commit always has/had to be true.
command: allow native access to "vf" property

This allows client API users and Lua scripts to side-step the pretty
horrible video filter string "language" (although it's back and can't be
avoided when using libavfilter).
lua: fix stack going out of sync

This broke with recursive tables.
ao_coreaudio: log even more info in verbose mode

This logs more info that can be used for debugging purposes, in particular
it prints all the AudioChannelDescription in the descriptions array.
vo: do not check for events on unconfigured VO

fixes #741
dispatch: document some guarantees

The here documented guarantee might simplify code using this mechanism
a lot, because it becomes unnecessary to invent a separate mechanism to
make the mp_dispatch_queue_process loop exit after processing a dispatch
callback. (Instead, the dispatch callback can set a flag, and the caller
of mp_dispatch_queue_process can check it.)
demux_mkv: enable parsing for mp3

For some reason, some files appear to have broken mp3 packets, or at
least in a form that libavcodec can't deal with. The audio in the sample
file in question could not be decoded using libavcodec.

The problematic file had variable packet sizes, and the libavcodec
decoder kept printing "mp3: Header missing" for each packet it was fed.
Remuxing with mkvmerge fixes the problem. The mp3 data is probably not
VBR, and remuxing resulted in fixed-size mp3 frames. So I don't know why
the sample file was muxed this way - it might just be incorrect.

The sample file had "libmkv 0.6.4" as MuxingApp (although I could not
get mkvinfo to print this element, maybe the file uses an incorrect
element ID), and "HandBrake 0.9.4" as WritingApp.

Note that the libmpg123 decoder does not have any issues with it. It's
probably more robust, because libmpg123 was made to decode whole mp3
files, not just single frames.

Fixes issue #742.
af.rst: fix replaygain-track description

libav now supports reading ReplayGain values from LAME's Info/XING tag as well.