Project:Video/VLC

Maintainer notes about vlc and its relatives

Introduction
isVLC media player, a multimedia player with different interface modules, though primarily as a streaming client. There are no frontends a part the core binary, but the different interfaces are loaded as modules.

Because of its structure, a crash into the decoding routines means a complete crash of the interface, too. A careful maintenance is needed, similarly to.

Its maintenance is usually simple, as it's one of the most portable solutions (it runs natively on Linux, Windows, OSX and FreeBSD). Related to  there are, though, different libraries that might be a problem to maintain, as they are handled differently in Portage from what the other distributions do.

Patches
Patches for  are a bit different respect  , as they are sometimes exclusive to Gentoo Linux and simply can't be upstreamed at all. This is the case of the patches that change some libraries from builtin to plugins (with the assumption that Gentoo always have them as PIC libraries).

In general there might be necessity to patch vlc when something in its dependencies changes, as it's usually quite good-written the internal code and also the. In the past it needed patching to get wxGTK or Samba dependencies fixed.

The bootstrap script provided with the sources should not be used to rebuild autotools support. While it's usually better to use the upstream-provide file, that bootstrap script contains also instructions to update gettext support, that might create confusion with the shipped version, and requires also the cvs command to get autopoint right. A simple call should be enough.

There are two ways to send patches upstream: either via their  mailing list or by reporting a bug in the Trac system.

The patches are hosted in CVS inside and are organized by version. Released patchsets are tagged with the name of the tarball minus the. The directories contains also a series file, as they are used by quilt: just symlink the checked out directory inside an extracted source tree of vlc (for that version) and use  to manage the patches.

External libraries and plugins
uses a mixed architecture for linking decoding libraries: some of them are linked as builtin, statically into the vlc binary, while others are built as plugins that gets loaded at runtime.

As the plugins are by all means shared objects, they must be built with PIC enabled and can't link against static non-PIC libraries. As some libraries used to decode or demux (such as libmatroska and libdts) used to be static libraries only, the configure sometimes checks for two names for libraries, one for the PIC version ( or  ) and one for the non-PIC, enabling the plugin or the builtin depending on the case.

As in Gentoo most of the libraries are patched to build the PIC shared version with the same name of the original one, the configure script sometimes gets false negatives, and builds as builtin something that could have been built as plugin. In those cases, it's needed to edit the file to get the right name for the library to build as plugin.

The use of plugins instead of builtins allows VLC to continue working also if one of the libraries gets broken by a changed ABI, as the plugins fails to load on demand, while builtins breaks the main executable file.

Like newer versions of ,   always uses an external copy of. This means that when a new version of that package is stabilized,  has to be checked against it. It also means that it does not suffer from problems related directly to  code, such as security vulnerabilities.

Testing versions
As many other projects, also  releases beta versions of the code before the actual final release. These beta versions are usually useful to test the changes to the dependencies and the code in package.mask so that problems can be found before unleashing the final version to users.

Test versions are usually announced on mailing list and can be found at http://download.videolan.org/pub/videolan/testing/. The naming scheme used is X.Y.Z-testT.

Since version 0.8.4, the ebuild carries the transformation between _beta to -beta versions and uses the right URL for betas without having to edit it by hand.

useflags
As many other multimedia programs, also  have quite a lot of useflags to disable and enable dependencies and extra features. There are a few missing dependencies that are not enabled, and a few useflags that were removed for many reasons in the past.

The nsplugin useflag is used to build the Netscape-compatible plugins (used by Mozilla, Firefox and Konqueror); this plugin is quite fragile, and the useflag (that was added after 0.8.2 release) was removed till the latter 0.8.5 revisions, with patches to build against Firefox or Seamonkey rather than the old Gecko-SDK (no more supported) or XULRunner (experimental). The plugin itself is unsatble anyway, and if bugs are confirmed is probably simpler to remove it or declare it experimental.

Most of the nsplugin's problems were fixed in 0.8.6, although the way to select against which package to build changed drastically (as the patch applied to 0.8.5 was rejected for a different approach). Since this version, you need to pass the XPIDL variable with the path to the IDL libraries for the package to link against (firefox or seamonkey) and the MOZILLA_CONFIG variable with the path to the script, again depending on which one you want to link against.

The live useflag enable support of live555 for RTSP support, provided by. Starting from version 2006.12.08 of this latter package, the way it is installed in the system is drastically changed; while previously it installed in a "build tree", and was linked statically, the newer versions installs as a normal package using lib and include directories. For this reason, the option is not passed anymore, in vlc 0.8.6 and later, if the newer version of live is present.

Acknowledgements
We would like to thank the following authors and editors for their contributions to this guide:


 * Diego Pettenò
 * Alexis Ballier