osc: change configfilename prefix to "plugin_"
cocoa_common: fix window positioning with `--geometry`

Regression since ff3b98d11c. The window positioning code relied on the
visibleFrame's height without taking into account the dock's presence.

Also moved the constraining code to the proper method that overrides the
original NSWindow behaviour. This avoids having to check for border since the
constraining is performed by Cocoa only for titled windows.

Fixes #190
mp_msg: fix typo in message level for new msg API macros
video: add vda decode support (with hwaccel) and direct rendering

Decoding H264 using Video Decode Acceleration used the custom 'vda_h264_dec'
decoder in FFmpeg.

The Good: This new implementation has some advantages over the previous one:

 - It works with Libav: vda_h264_dec never got into Libav since they prefer
   client applications to use the hwaccel API.

 - It is way more efficient: in my tests this implementation yields a
   reduction of CPU usage of roughly ~50% compared to using `vda_h264_dec` and
   ~65-75% compared to h264 software decoding. This is mainly because
   `vo_corevideo` was adapted to perform direct rendering of the
   `CVPixelBufferRefs` created by the Video Decode Acceleration API Framework.

The Bad:
  - `vo_corevideo` is required to use VDA decoding acceleration.
  - only works with versions of ffmpeg/libav new enough (needs reference
    refcounting). That is FFmpeg 2.0+ and Libav's git master currently.

The Ugly: VDA was hardcoded to use UYVY (2vuy) for the uploaded video texture.
One one end this makes the code simple since Apple's OpenGL implementation
actually supports this out of the box. It would be nice to support other
output image formats and choose the best format depending on the input, or at
least making it configurable. My tests indicate that CPU usage actually
increases with a 420p IMGFMT output which is not what I would have expected.

NOTE: There is a small memory leak with old versions of FFmpeg and with Libav
since the CVPixelBufferRef is not automatically released when the AVFrame is
deallocated. This can cause leaks inside libavcodec for decoded frames that
are discarded before mpv wraps them inside a refcounted mp_image (this only
happens on seeks).
For frames that enter mpv's refcounting facilities, this is not a problem
since we rewrap the CVPixelBufferRef in our mp_image that properly forwards
CVPixelBufferRetain/CvPixelBufferRelease calls to the underying
CVPixelBufferRef.

So, for FFmpeg use something more recent than `b3d63995` for Libav the patch
was posted to the dev ML in July and in review since, apparently, the proposed
fix is rather hacky.
stream_file: uncrustify
stream_avdevice: remove redundant dummy callback
stream: move file forward skipping to common stream implementation

stream_file.c contains some code meant for forward seeking with pipes.
This simply reads data until the seek position is reached. Move this
code to stream.c. This stops stream_file from doing strange things
(messing with stream internals), and removes the code duplication too.

We also make stream_seek_long() use the new skip code. This is shorter
and much easier to follow than the old code, which basically did strange
things.
stream: don't require streams to set s->pos in seek callback

Instead, set s->pos depending on the success of the seek callback.
stream: allow potentially faster skipping

Instead of always skipping in STREAM_BUFFER_SIZE blocks, allow an
arbitrary size. This allows - in theory - faster forward seeking in
pipes.

(Maybe not a very significant change, but it reduces the number of
things that depend on STREAM_BUFFER_SIZE for no good reason. Though
we still use that value as minimum read size.)
demux_raw: read multiple frames per packet

The rawaudio demuxer read one frame per packet, basically a few bytes,
which caused insane overhead. (I found this when I couldn't play raw
audio without dropouts when using -v, which printed a line per packet
read.)

Fix this and read 1 second of audio per packet. This is a regression
since cfa5712 (merging of demux_rawaudio and demux_rawvideo).
demux: check whether stream is selected in demux_get_next_pts()

Otherwise, this would just try to demux a good chunk of the file, even
though the operation can't succeed anyway.

This caused some pretty strange issues, where perfectly valid use cases
would print a "Too many packets in the demuxer packet queue..." message.
demux: remove unused audio_delay parameter from demux_seek()

Used to be needed by demux_avi.
ao: remove some leftovers
audio/out: do some mp_msg conversions

Use the new MP_ macros for some AOs instead of mp_msg.

Not all AOs are converted, and some only partially. In some cases, some
additional cosmetic changes are made.
cocoa_common: avoid locking calls when not needed

cocoa_common contains some locking calls to support video outputs that support
live resizing (at this moment only vo=opengl).

These should not be used unless the VO declares it is multithreaded by
registering the resize_redraw callback used for live resizing.

Fixes #200
x11/out: mp_msg conversion
Some more mp_msg conversions

Also add a note to mp_msg.h, since it might be not clear which of the
two mechanisms is preferred.
sub: add webvtt-in-webm support

The way this was added to FFmpeg is less than ideal, because it requires
text parsing in the Matroska demuxer. But in order to use the FFmpeg
webvtt-to-ass converter, we still have to mimic this in some way. We do
this by putting the parsing into sd_lavc_conv.c, before the subtitle
packet is passed to libavcodec. At least this keeps the ugliness out of
unrelated code.

There is some change that FFmpeg will fix their design eventually.

Instead of rewriting the parsing code, we simply borrow it from FFmpeg's
Matroska demuxer.
Merge remote-tracking branch 'origin/master' into lua_experiment
vo_vaapi: potentially fix screenshot colorspace issues

mp_image_set_params() doesn't check whether the colorspace parameters
are  consistent (e.g. setting YUV colorspaces with RGB formats), and
shouldn't need to.