waf: make shlib tasks less noisy
video/out: remove unused config() parameters

This was cleaned up yesterday.
player: reset last_frame_duration on init
player: handle video reconfig slightly different again

Now we avoid calling update_video() twice on reconfig (once to check
whether there are still new frames, and again to actually do the
reconfig). Instead, we check whether there's still something going on
before calling update_video() at all, and depending on that
update_video() will be allowed to reconfig or not.

This will simplify some things later.
player: limit max. fallback frame duration

It's calculated from the demuxer reported FPS, which is not very
reliable. Limit the damage a completely insane and broken value could
cause.
player: minor reshuffling of video code
player: remove VO from seeking code path

Until recently, the VO was an unavoidable part of the seeking code path.
This was because vdpau deinterlacing could double the framerate, and hr-
seek and framestepping etc. all had to "see" the additional frames. But
we've removed the frame doubling from the vdpau VO and moved it into a
video filter (vf_vdpaupp), and there's no reason left why the VO should
participate in seeking.

Instead of queuing frames to the VO during seek and skipping them
afterwards, drop the frames early.

This actually might make seeking with vo_vdpau and software decoding
faster, although I haven't measured it.
player: avoid reconfig during seeking

This probably matters only in extremely corner-case heavy testcases,
such as using mf:// with a bunch of differently sized images.
options: add --hr-seek-framedrop option

This allows disabling of decoder framedrop during hr-seek.

It's basically another useless option, but it will help exploring
whether this framedropping really makes seeking faster, or whether
disabling it helps with precise seeking (especially frame backstepping).
command: add property that estimates current video FPS

This is done after filters, so things like framerate-doubling
deinterlacing is accounted for.

Unfortunately, framedropping can cause inaccuracies (especially after
precise seeks), and we can't really know when that happens. Even though
we know that the decoder might drop a frame if we request it to do so,
we don't know when the dropped frame will start or stop affecting the
video filter chain. Video filters can have frames buffered, and we
can't tell at which point the dropped frame would have been output.
It's not even possible to mark a discontinuity after seek, because
again we don't know if the filter chain still has the discontinuity
within its buffers.

So we have to live with the fact that the output of this property can
be completely broken after seek, unless --no-hr-seek-framedrop is used.
man: tweak --sub-codepage for concision

The many "boxes" in this entry were causing rst2pdf to fail because it
couldn't figure out where to break the page. Make the boxes smaller by
removing semi-redundant examples. Also try and make surrounding text a
little shorter by rewording.
Merge pull request #774 from kevmitch/man_pdf_tweaks

man: tweak --sub-codepage for concision
osxbundle: split and optimize bundling script

Move the code that copies the dylib's to the bundle to a new script
(dylib-unhell.py) which is called by osxbundle.py.

dylib-unhell is about 20x faster than the previous implementation. This is
accomplished by removing superflous shell-out operations which are kept track
of using an in memory tree of all the needed dependencies. Moreover the
shell-outs have been further optimized by not requiring a complete shell for
every operation and just using subprocess.call (which is equivalent to Popen).
w32_common: fix typo

Also, reset rc completely, instead of assuming things.
input: fix typos, cosmetics
vdpau: handle display preemption during decoding

This was broken for some time, and it didn't recover correctly.

Redo decoder display preemption. Instead of trying to reinitialize the
hw decoder, simply fallback to software decoding. I consider display
preemption a bug in the vdpau API, so being able to _somehow_ recover
playback is good enough.

The approach taking here will probably also make it easier to handle
multithreading.
vo_vdpau, vo_opengl: handle vdpau preemption differently

Use the newly provided mp_vdpau_handle_preemption() function, instead of
accessing mp_vdpau_ctx fields directly. Will probably make multithreaded
access to the vdpau context easier.

Mostly unrelated to the actual changes, I've noticed that using hw
decoding with vo_opengl sometimes leads to segfaults inside of nvidia's
libGL when doing the following:

1. use hw decoding + vo_opengl
2. switch to console (will preempt on nvidia systems)
3. switch back to X (mpv will recover, switches to sw decoding)
4. enable hw decoding again
5. exit mpv

Then it segfaults when mpv finally calls exit(). I'll just blame nvidia,
although it seems likely that something in the gl_hwdec_vdpau.c
preemption handling triggers corner cases in nvidia's code.
vdpau: remove some code

There's no reason why we should treat the preemption case differently
here.
vdpau: make mp_vdpau_ctx thread-safe

Preparation so that various things related to video can run in different
threads. One part to this is making the video surface pool safe.

Another issue is the preemption mechanism, which continues to give us
endless pain. In theory, it's probably impossible to handle preemption
100% correctly and race-condition free, unless _every_ API user in the
same process uses a central, shared mutex to protect every vdpau API
call. Otherwise, it could happen that one thread recovering from
preemption allocates a vdpau object, and then another thread (which
hasn't recovered yet) happens to free the object for some reason. This
is because objects are referenced by integer IDs, and vdpau will reuse
IDs invalidated by preemption after preemption.

Since this is unreasonable, we're as lazy as possible when it comes to
handling preemption. We don't do any locking around the mp_vdpau_ctx
fields that are normally immutable, and only can change when recovering
from preemption. In practice, this will work, because it doesn't matter
whether not-yet-recovered components use the old or new vdpau function
pointers or device ID. Code calls mp_vdpau_handle_preemption() anyway to
check for the preemption event and possibly to recover, and that
function acquires the lock protecting the preemption state.

Another possible source of potential grandiose fuckup is the fact that
the vdpau library is in fact only a tiny wrapper, and the real driver
lives in a shared object dlopen()ed by the wrapper. The wrapper also
calls dlclose() on the loaded shared object in some situations. One
possible danger is that failing to recreate a vdpau device could trigger
a dlclose() call, and that glibc might unload it. Currently, glibc
implements full unloading of shared objects on the last dlclose() call,
and if that happens, calls to function pointers pointing into the shared
object would obviously crash. Fortunately, it seems the existing vdpau
wrapper won't trigger this case and never unloads the driver once it's
successfully loaded.

To make it short, vdpau preemption opens up endless depths of WTFs.

Another issue is that any participating thread might do the preemption
recovery (whichever comes first). This is easier to implement. The
implication is that we need threadsafe xlib. We just hope and pray that
this will actually work. This also means that once vdpau code is
actually involved in a multithreaded scenario, we have to add
XInitThreads() to the X11 code.
encode: fix PTS unit mismatch

This used MP_NOPTS_VALUE to compare with ffmpeg-style int64_t PTS
values. This probably happened to work, because both constants use the
same value.