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.

So that whatis is happy
Drop some unusefull undefined macros

This prevents the libvlc object from having it's name set to
"memcpymmxext" by module_Need.
This reverts commit 15e7d182.

Casting to any other type would be (is?) unsafe as users can now freely
alias objects.