Cosmetic on the file too.

We were always picking the same values. This is pretty bad as it breaks
fast resynchronization (and is totally lame anyway).

This module make possible uses libvlc as output (not input as vmem) for
video stream rendering in aplication ... motivation to create this patch can
find at http://forum.videolan.org/viewtopic.php?f=32&t=53256

Usage is similar to vmem output module. We need next vlc_argv[] options:
   "--codec", "invmem",
   "--invmem-width", width,
   "--invmem-height", height,
   "--invmem-lock", clock,
   "--invmem-unlock", cunlock,
   "--invmem-data", cdata,
and calling libvlc_media_new with "fake://" access string:
   libvlc_media_new(libvlc, "fake://", &ex);
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>

Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>

us_asprintf() has the same prototype as asprintf(), but doesn't use
the system locale.
Signed-off-by: Michael Hanselmann <public@hansmi.ch>
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>

Fix typo in comment: "spurious" instead of "supurious"
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>

(cherry picked from commit a684d026)

Replaces a function declaration by the needed empty definition for WinCE
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>

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

There was a segfault probably due to taglib module changes.

It avoids useless es creation every time the current active es is destroyed.

This is trivially exploitable to run code.

Pointed-out-by: Tobias Klein

could do reviewing.

The attached patch adds support for decrypting and playing drm
protected video, such as those from iTunes movie store.

The patch was created against the 0.9.5 source tarball, and was
compiled and tested on OSX against some (legitimately purchased)
iTunes purchased songs and movies.

Just like the existing audio support it requires decryption keys to be
deposited in ~/.drms/ and extracting the keys is left as an exercise
for the user.

[Commit message edited by Laurent Aimar]
Signed-off-by: Iain Wade <iwade@optusnet.com.au>
Signed-off-by: Laurent Aimar <fenrir@videolan.org>

It isn't legal for granulepos to be UINT64_MAX on an EOS page since
this special value indicates that no packets finish on the page, yet
an EOS page signifies that the final packet does finish on the page.

It seems that there is a convention for repeating the last used
granulepos in the EOS page per logical stream.  This then allows
some extra file size hints (duration = last gp - first gp) [1]

[1] This is flawed -- EOS may occur anywhere, however this is what
some people do.
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Laurent Aimar <fenrir@videolan.org>