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

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

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

pub   1024D/45C11CA7 2011-01-30 [expires: 2012-01-30]
      Key fingerprint = 160A 96C4 CA7F 8ABA D43C  C087 62B9 7F54 45C1 1CA7
uid                  VideoLAN Release Signing Key (2011)

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

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

This affects way too many code paths. Let KDE fix their own crap.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

This fixes cases where the stream length is unknown

Otherwise, when sending requests while already receiving data
(e.g. seeking) responses are not waited for properly

This reverts commit 7b18ec43.
This broke LibVLC and wall.

This reverts commit 95b63292.
This broke LibVLC and the wall filter.

Same rationale as previous patch about Linux.

fix trac #4440 (to be tested)

When the default window provider is used (dummy, rc, ... interfaces),
rather decide what to do when the user closes the video window than let
the WM blindly destroy it. Till now, this led to an error message, input
dying and the playlist being stopped. For -I dummy, it also meant leaving
vlc hanging since no interface could then be used to stop vlc.

Action taken is to stop vlc, but feel free to change/improve/make it
more configurable if need be.

An negative integer would make no sense here. I guess we could use an
unsigned char here, since it can only be between 0 and 127, as far as I
understand

This fixes opening of file names containing non-ASCII characters

Fixes Debian bug #600269

We still need to use it to stop VoD instances because the VLM waits
to join the input thread :(

For VoD, the synchronization is bad, but accurate synchronization would
require at least changes in the core to add support for some kind of
"instant pausing" to the stream output. Synchronous calls to the VLM
shouldn't cause delay problems, no operation waits for the input.