libvlc: rename all libvlc_MediaInstance in libvlc_MediaPlayer and libvlc_MediaDescriptor to libvlc_Media
Signed-off-by: Pierre d'Herbemont <pdherbemont@videolan.org>

Signed-off-by: Pierre d'Herbemont <pdherbemont@videolan.org>

Do not allocate ridiculous amount of datas.
Signed-off-by: Jean-Paul Saman <jpsaman@videolan.org>

Actions on cropping UI. This doesn't work yet, because I am unsure of the good way to do it. Ref #1400.

Adding Panoramix there.

Renamings.

libvlc: In order not to be confused by a vlm created elsewhere, use a libvlc instance variable to old the vlm libvlc created if --vlm-conf was specified.

This also make sure the vlm created when --vlm-conf is specified gets really destroyed. Because find_object yields vlm and is never released.

libvlc: Don't use input_ItemClean. Anyway when we leak an object there is no use to delete it in the end. The mistake has already been done.

vlm: Only use gc enabled input item. (input_ItemClean and input_ItemInit shouldn't be used directly).

Instantiate VLM if vlm-conf option is used. You can now use VLM without having to launch the telnet or http interface.

We do maintain a lock around vlc_object_alive() because we want to make sure we won't miss the point when a concurrent thread will call vlc_object_kill(), that is set b_die and vlc_object_signal(). If we missed b_die and the signal, next vlc_object_wait() will dead lock.

Signed-off-by: Pierre d'Herbemont <pdherbemont@videolan.org>

We can't do what is advised in the documentation of vlc_object_alive(), but we try to stay close enough of it.

Remove useless variable

Signed-off-by: Ilkka Ollakka <ileoo@videolan.org>

The whole point of a global lock is that it is... global. Destroying it
every time it's released is severe brain damage, as we end up taking a
different lock all the time (or worse destroying the lock while another
threads is competing for it).