At worst it will use a lot of CPU but this will allow to detect buggy
access/access_demux module.

Interfaces are updated every 250 millisecond.
Statistiques are updated every second.

This reverts commit 7cc631ac.

freetype.c and quartztext.c contain a lot of common code, that should
be factorized.

So there are no deadlocks if multiple threads are waiting on the same
object (although that's not a very brilliant idea).

Get rid of unsafe PulseEvent().
Fix recursive mutex implementation (hopefully).
Use critical section (fast non-shared/intra-process mutexes)
 rather than mutex handle (slow shared/inter-process mutexes) [1].
Do not rely on unspecified locking when SignalObjectAndWait is alerted.
Real vlc_cond_broadcast() support (hopefully).

[1] should also merge the WinCE support with WinNT.

The overhead of calling a function is rather tiny compared to the
overhead of doing the system call these typically involve.

Also refs #1392

Seems like this is needed for proper vlc_object_kill() (if more than
one thread waits on a given object).

Threads can be cancelled and are not killed by default.

Windows API expect a timeout in millisecond.
SignaObjectAndWait should properly work with a 0 timeout, so try it.
(avoid an invalid lock and an uninitialized return value).

Copy palette to fmt_out.
No you cannot blindly copy between VLC and FFmpeg structures...

SwScaler uses a really ugly hack to transmit the palette.

Pointed-out-by: Laurent Aimar

Variables callback can be (and usually are) invoked from other threads.
They cannot access the object without locking, and must be unregistered
before the object is destroyed (var_DelCallback() -> free(p_sys)).