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)).

(Currently, <1ms on Linux, and <0 on others)

Thanks Courmisch for pointing it.

This fixes a few "deadlocks" with input waiting for playlist, while
playlist is waiting for input event.

Also do not needlessly lock after unregistering the callbacks. We have
to assume that when var_DelCallback returns, any pending callback
invocation has be completed. Otherwise, we would any crash when Close()
releases the mutex, destroys it, and the callback then tries to acquire
the mutex.

See page 66 of ETSI EN 300 468

This way the TS demux can create multiple tracks that will take you straight to the subtitles, program listings etc.