Close #2521

...and it is probably no use considering vout thread already has the
informations.

This reverts gullible commit 54b43fae. vout_Control() cannot be called
from another thread. Full point.

It was broken after being privatized.

input: send inputEvent when length if input changes

This one should fix #2435

It fixes a logical bug as the input and output format could be different.
(Not plugin that does that yet).

If an interface exits "early" it should reparent (although reparenting
is no safer). Otherwise, the core will ensure that the video output was
safely closed before it terminates the interface.

Calling vout_Control() after vlc_object_find() or input_GetVouts is not
valid. It cannot be. There is no warranty that pf_control is valid (the
video output plugin could be initializing or deinitializing). Even if
there were a lock without the pf_control implementation (as with X11),
it still wouldn't work.

Anyway, in this particular case, we already have video-snapshot to do
the exact same thing in a safe manner.

There remain some issues with snapshots:
 - there is no synchronization of b_snapshoy with the video thread,
 - there is no/incomplete error handling,
 - there is no protection against multiple concurrent snapshot reqs.

It did not work properly, and was GNU specific anyway.

This reverts back to 0.9 (and --enable-libtool 0.8.6) state. This
should fix bindings and web plugins, without hacks. However, this will
require relinking all VLC plugins whenever libvlccore changes.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Laurent Aimar <fenrir@videolan.org>