diff options
Diffstat (limited to 'xml/htdocs/proj/en/desktop/video/vlc.xml')
| -rw-r--r-- | xml/htdocs/proj/en/desktop/video/vlc.xml | 289 |
1 files changed, 289 insertions, 0 deletions
diff --git a/xml/htdocs/proj/en/desktop/video/vlc.xml b/xml/htdocs/proj/en/desktop/video/vlc.xml new file mode 100644 index 00000000..a2a68db7 --- /dev/null +++ b/xml/htdocs/proj/en/desktop/video/vlc.xml @@ -0,0 +1,289 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/video/vlc.xml,v 1.26 2009/11/12 19:40:57 aballier Exp $ --> + +<guide link="/proj/en/desktop/video/vlc.xml" lang="en"> +<title>vlc and related</title> + +<author title="Author"> + <mail link="flameeyes@gentoo.org">Diego Pettenò</mail> +</author> +<author title="Contributor"> + <mail link="aballier@gentoo.org">Alexis Ballier</mail> +</author> + +<abstract> +Maintainer notes about vlc and its relatives +</abstract> + + +<!-- The content of this document is licensed under the CC-BY-SA license --> +<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> +<license/> + +<version>1.24</version> +<date>2009-11-12</date> + +<chapter> <!-- vlc --> +<title>vlc</title> + +<section> <!-- Introduction --> +<title>Introduction</title> + +<body> + +<note> +This guide was last updated for <c>vlc</c> version 1.0.3. +</note> + +<p> +<c>media-video/vlc</c> is +<uri link="http://www.videolan.org/">VLC media player</uri>, a multimedia player +with different interface modules, though primarily as a streaming client. +There are no frontends a part the core <c>vlc</c> binary, but the different +interfaces are loaded as modules. +</p> + +<p> +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 +<c><uri link="xine.xml">xine-lib</uri></c>. +</p> + +<p> +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 <c>vlc</c> +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. +</p> + +</body> +</section> + +<section> <!-- Patches --> +<title>Patches</title> + +<body> + +<p> +Patches for <c>vlc</c> are a bit different respect <c>xine-lib</c>, 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). +</p> + +<p> +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 <path>configure.ac</path>. In the past it needed patching to get +wxGTK or Samba dependencies fixed. +</p> + +<p> +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 <path>eautoreconf</path> call should +be enough. +</p> + +<p> +There are two ways to send patches upstream: either via their <path>vlc-devel</path> +<uri link="http://developers.videolan.org/lists.html">mailing list</uri> or by +<uri link="http://wiki.videolan.org/Report_bugs">reporting a bug</uri> in the +<uri link="https://trac.videolan.org/vlc/">Trac system</uri>. +</p> + +<p> +The patches are hosted in CVS inside <path>gentoo/src/patchsets/vlc</path> +and are organized by version. Released patchsets are tagged with the name of the +tarball minus the <path>.tar.bz2</path>. 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 <c>quilt</c> to +manage the patches. +</p> + +<note> +Also if usually this point was never stressed out, now that patches are hosted +on the CVS it's important that they bring a description in the header, with also +a link to relevant bugs, both in Gentoo and upstream. +</note> + +</body> +</section> + +<section> <!-- External libraries and plugins --> +<title>External libraries and plugins</title> + +<body> + +<p> +<c>vlc</c> uses a mixed architecture for linking decoding libraries: some of +them are linked as <e>builtin</e>, statically into the vlc binary, while others +are built as <e>plugins</e> that gets loaded at runtime. +</p> + +<p> +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 (<path>_pic</path> or <path>_p</path>) and one for the non-PIC, +enabling the plugin or the builtin depending on the case. +</p> + +<p> +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 <path>configure.ac</path> file +to get the right name for the library to build as plugin. +</p> + +<p> +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. +</p> + +<p> +Like newer versions of <c><uri link="xine.xml">xine-lib</uri></c>, <c>vlc</c> +always uses an external copy of <c>ffmpeg</c>. This means that when a new +version of that package is stabilized, <c>vlc</c> has to be checked against it. +It also means that it does not suffer from problems related directly to +<c>ffmpeg</c> code, such as security vulnerabilities. +</p> + +</body> +</section> + +<section> <!-- Testing versions --> +<title>Testing versions</title> + +<body> + +<p> +As many other projects, also <c>vlc</c> 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. +</p> + +<p> +Test versions are usually announced on <path>vlc-devel</path> mailing list and +can be found at +<uri link="http://download.videolan.org/pub/videolan/testing/">http://download.videolan.org/pub/videolan/testing/</uri>. +The naming scheme used is X.Y.Z-testT. +</p> + +<p> +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. +</p> + +</body> +</section> + +<section> <!-- useflags --> +<title>useflags</title> + +<body> + +<p> +As many other multimedia programs, also <c>vlc</c> 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. +</p> + +<p> +The <b>nsplugin</b> 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. +</p> + +<p> +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 +<path>*-config</path> script, again depending on which one you want to +link against. +</p> + +<p> +The <b>live</b> useflag enable support of live555 for RTSP support, +provided by <c>media-plugins/live</c>. 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 <path>--with-live555-tree</path> option is not passed +anymore, in vlc 0.8.6 and later, if the newer version of live is +present. +</p> + +<table> + <tr> + <th>Useflag</th> + <th>Local description</th> + <th>Dependency</th> + <th>Reason for removing</th> + </tr> + + <tr> + <ti>portaudio</ti> + <ti>PortAudio output plugin</ti> + <ti>>=media-sound/portaudio-19</ti> + <ti> + The required version of <c>portaudio</c> is the currently experimental + version (19), not present in Portage and too unstable. + </ti> + </tr> + + <tr> + <ti>tremor</ti> + <ti>Enables Tremor decoder support</ti> + <ti></ti> + <ti>Missing dependency</ti> + </tr> + + <tr> + <ti>tarkin</ti> + <ti>Enables experimental tarkin codec</ti> + <ti></ti> + <ti>Missing dependency</ti> + </tr> + + <tr> + <ti>cyberlink</ti> + <ti>Enable CyberLink UPnP stack</ti> + <ti></ti> + <ti>Missing dependency</ti> + </tr> + + <tr> + <ti>libtar</ti> + <ti>Enables libtar support for skins2 module</ti> + <ti>dev-libs/libtar</ti> + <ti>libtar doesn't build a PIC shared library thus we disable it</ti> + </tr> + +</table> + +</body> +</section> + +</chapter> + +</guide> + +<!-- kate: space-indent on; indent-width 2; replace-tabs on; --> |