We need to check vlc_object_alive() anyway, due to the intrinsic race
condition whereby the thread is killed before it's got the chance to
lock its object and call vlc_object_wait().

There is no point in unlocking and locking again immediatly.
Not only will this typically fail to yield the CPU to another would-be
waiting thread, but vlc_object_wait() will unlock&lock anyway.

all formats where the pixel pitch is of 1 byte on every plane).

but packed should be easy to implement.

planar YUV).

mozilla: Use --ignore-config, we don't want local VLC to interfer with the plugin. Also support exception.

vlckit: Make sure it compiles, by switching to autotools. This will allow the framework to be a bit more stable, as autotools is still our main buildsystem, and modifications to it break cmake often.

macosx: Sanitization. Suppress non-sense yield(->p_input) release(->p_input), invalidate the manage thread, make sure we don't re-run a timer when the interface is dead. (Shoot 'em up!)

Remember, you can't assume that in your thread an object is alive if you don't delimit want-to-be safe place by a lock(p_obj)/unlock(p_obj).
Also, yield(p_playlist->p_input) is invalid if you don't lock the playlist before. The correct way here is to use vlc_object_find() as the locking policy of the playlist is not safe.

av_free and friends are used in the ffmpeg plugin, and after r13528
ffmpeg's .pc files do not tell anymore to link needlessly to its
private library requirements.
Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>

Including it after stdbool will cause compile failures as pointed by
Mike Frysinger in https://bugs.gentoo.org/show_bug.cgi?id=224289Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>