vf_eq: fix behavior when changing parameters

Using -vf eq and changing brightness, contrast, etc. using key bindings
with e.g. "add brightness 1" didn't work well: with step width 1, the
property gets easily "stuck". This is a rounding problem: e.g. setting
gamma to 3 would actually make it report that gamma is set to 2, so
the "add" command will obviously never reach 3 with a step width of 1.
Fix this by storing the parameters as integers.

This was broken in cac7702. This commit effectively changed these
properties to use the value as reported by vf_eq, instead of the
previously set value for the "add" command. This was more robust,
but not very correct either, so we keep the new behavior and make
vf_eq report its parameters more accurately.
command: simplify video brightness/gamma/etc. handling a bit

We don't need to store the offsets of the options corresponding to the
properties, because the option-property bridge knows about this already.

The check against 1000 was for the case if e.g. the --brightness option
is not used. Always overwrite the option value instead, both when
querying and setting the property. (This is needed to make the settings
persistent even if vf_eq is used and the video chain is reinitialized.)

This commit assumes that VFCTRL_SET_EQUALIZER is always paired with
VFCTRL_GET_EQUALIZER (likewise for VOCTRL), which is the case.
manpage: fix (again) incorrect ao_alsa example

One example in ao.rst used the old syntax with misspelling of "no-block".
mplayer: start track IDs from 1 rather than 0

Completely pointless, but makes ChrisK happy for some reason.

Track ID 0 is now rejected by the option parser itself.
options: replace --edition=-1 with --edition=auto

Originally, the objective of this commit was changing --edition to be
1-based, but this was cancelled. I'm still leaving the change to
demux_mkv.c though, which is now only of cosmetic nature.
mplayer: replace "D:" in status line with "Late:"

Too many people thought "D:" really meant number of dropped frames. But
it's actually the number of frames where the playloop thought it'd be
a good idea to drop them. Of course this does nothing if frame dropping
is disabled, but even with normal frame dropping, this doesn't indicate
whether a frame was _really_ dropped. (Looks like libavcodec doesn't
even give us this information reliably? The decode function can return
no frame in case of codec delay due to threading and such.)
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.
Merge remote-tracking branch 'upstream/master'

Conflicts:
	video/decode/vd_lavc.c
	video/img_format.h