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.