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

When cleared the menu was not refreshed.
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>

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

Some broken .Ram playlist have .rm extensions. The real demuxer should take the actula .rm files before.

Adds a RAM playlist demuxer to read .ram playlist files. Handles parameters author, copyright, clipinfo, start, end and title.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

On my linux x86_64 system, when trying to statically link the x264
module against libx264, I get the following error:

/usr/bin/ld: /usr/local/lib/libx264.a(cabac-a.o): relocation
R_X86_64_PC32 against symbol `x264_cabac_range_lps' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

Even though libx264 was compiled as PIC. Dynamically linking against the
shared library, built during the same process, works well.

The x264 folks said that VLC needed to use the -Bsymbolic flag to allow
conversation of a static PIC library into a shared library, so that's
what I did, and it works for me.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

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

 It will avoid VLC loading every .mkv in the same directory than the
one you are trying to play (can be very very long).
Of course, this will break linked mkv files...

 This modules seems to not resample the first samples (which is not good
at all for an audio filter2 btw). This has to be taken into account when
calculating the output buffer size.
Fixes #1862 and #1962(duplicate).

Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

Available capture devices will be listed in the debug output when no device is forces (alsa://).

If compiled with libv4l2 support, first try using the kernel v4l2 api
and then fallback to libv4l2 if it didn't work. You can force using
libv4l2 with --v4l2-use-libv4l2. (libv4l2 broke the v4l2 access for
some people. This should be backported to 0.9.9)

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

It fixes at least a deadlock in win32 when seeking.

Not yet activated
Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

Signed-off-by: Christophe Mutricy <xtophe@videolan.org>