The xine engine FAQ list

The xine engine is a free media player engine. It comes in the form of a shared libarary and is typically used by media player frontends and other multimedia applications for playback of multimedia streams such as movies, radio/tv network streams, DVDs, VCDs.

Since there are several frontends for the xine library available, this document has a problem when it comes to examples. The two most common frontends xine-ui and gxine are mixed in command line examples throughout this FAQ. When you use a different frontend, some of these will not work for you. The filename of the config file also varies amongst frontends. If you get confused, I recommend you try with one of xine-ui or gxine.

The primary goal of this FAQ is to cover all recurring questions related to the xine engine. Frontend specific questions are usually not covered here.

First of all be sure that your question is really not covered here and that you haven't just been a bit too lazy to read through all of this text. ;-). Also check out the documentation specific to the frontend (e.g. xine-ui or gxine or totem).

That said – you are welcome to mail to our user mailing list: <xine-user@lists.sourceforge.net> Please provide some info about your setup so people have a chance to help you, e.g. include information about your audio/video hardware and drivers you use, operating system, cpu type and some console output/any error messages. Also include command line parameters you have specified and information about the type of stream you're trying to play back. Also very important is the version of xine you're using and information about any additional plugins you may have installed on your system.

As long as people know what you are talking about, you are free to pronounce it the way you like, but the official pronounciation is [ksi:n], like the name "Maxine" with the "Ma" removed.

Some time ago xine just became too complex to be just one big program. Therefore it was split into two major parts.

xine-lib is simply speaking the engine of xine. It contains all basic plugins and is necessary to run anything that relies on xine. (This is the part that is covered in this FAQ.)

Then there are frontends – applications that use xine. The most common frontend is that of a media player. There are currently three frontends being developed in the xine project: xine-ui, a skinned dvd-player style frontend directly based on xlib; gxine, a desktop media-player style frontend using the standard GTK widget set; and xine-plugin, a plugin for browsers such as Firefox. External projects like kaffeine, sinek and totem develop additional frontends. In the future you will likely see more and different types of applications being developed which will use the xine engine for video processing and other multimedia purposes.

If you simply want a media/dvd player, you'll need to install xine-lib first and then choose and install a player frontend like xine-ui or gxine.

Other repositories include xine-project-www, which contains the xine project website sources, and various packaging and development branches.

Be advised that end-users should stick to the official xine releases. The Mercurial repositories are only intended for developers and for others who know why they use it.

The repositories are listed at http://hg.debian.org/hg/; however, this is a list of all repositories which are kept there, not just the xine project's (which are the ones which begin with xine-lib/). To check one out:

   hg clone http://hg.debian.org/hg/repository local_copy

e.g.

   hg clone http://hg.debian.org/hg/xine-lib/xine-lib xine-lib

You can see a full list of repositories by visiting http://hg.debian.org/hg/xine-lib/.

We used to, but there are some significant problems with CVS. Merging is easier with Mercurial (and, for that matter, git); and we can commit changes locally, change them if mistakes have been made, then make them public whenever we're ready.

See the xine Hackers' Guide, chapter 3, "How to contribute". (This is available online at http://www.xine-project.org/hackersguide#contribute.)

The xine project does not provide pre-compiled binaries for legal reasons (some parts of xine may be covered by patents in some countries). Some OS projects/vendors (e.g. Debian, FreeBSD, …) offer binaries for their distributions – please contact them or use their package search tools for further info. You can also find links to third parties providing xine RPMs on the xine homepage at http://www.xine-project.org/releases.

See the next section of this FAQ for instructions on how to build xine from source.

First of all an official and stable release of gcc. Also be aware that patched gcc versions may break parts of xine and are therefore not supported by the xine project.

Furthermore you'll have to use GNU make to compile xine. On most GNU/Linux systems "make" is GNU make – on other platforms use "gmake" instead. Also, zlib is required (including the appropriate header files, which are often found in a package called zlib-devel or similar.)

If you want to compile xine from Mercurial, you'll need to have the autobuild tools installed (automake, autoconf and libtool – in recent versions).

Frontends might need additional libraries, e.g. for gxine you'll need to have GTK2 installed. Make sure you have not only the shared libraries themselves but also the header files (often packaged seperately as so-called -dev packages) on your system.

Some plugins that come with the xine engine need additional libraries (otherwise they will not be built). For example, libogg and libvorbis (plus their include files) are needed for ogg/vorbis support. Most notably, if you want to see any video on your X11 desktop (and that's what you're here for, isn't it?), you need the X developer packages as well.

Don't worry about this too much right now, xine's configure (see below) will check for all the stuff needed and will tell you what's missing (which means that you should check the output it produces carefully ;) ).

Basically you will only have to issue one command, if you have just downloaded a source tarball from our web site:

   rpmbuild -ta <THE_NAME_OF_YOUR_SOURCE_TAR_BALL>

(Older versions of RPM use rpm instead of rpmbuild.)

This will start the binary and source RPM building. After compiling is finished, a binary rpm is placed in your rpm binary directory which is something like /usr/src/RPM/RPMS/<YOUR_ARCHITECTURE> and a source RPM is written to your rpm source dir (e.g. /usr/src/RPM/SRPMS).

In case that you have an up-to-date hg repository, you will need to do the following first in order to get a tarball release out of it which you can later use with the rpmbuild -ta command above:

   ./autogen.sh && make clean && make dist

In any case, please keep in mind that you have to build and install xine-lib first before you can proceed with xine-ui.

You'll need an HG snapshot tarball or source checked out from the repository.

First, make sure that the "devscripts" package is installed. You'll then need the following commands (the first one isn't needed unless you're using a snapshot tarball):

   tar xzf <PACKAGE-VER.tar.gz>
   cd <PACKAGE-VER>
   ./autogen.sh noconfig
   debuild binary
     

(If debuild complains about unmet dependencies, then install them using aptitude install <PACKAGES> (as root) then re-run debuild binary.

Once the build has been successfully completed, you'll have some new .debs.

   cd ..
   ls *.deb
   su - -c 'cd '"`pwd`"' && dpkg -i <DEB_PACKAGES>'
     

Ubuntu users will probably want to use this instead of that su:

   sudo dpkg -i <DEB_PACKAGES>
     

In any case, please keep in mind that you have to build and install xine-lib first before you can proceed with xine-ui or gxine.

Yes, you can do so by setting the CFLAGS variable and then running configure again. You can even pass them to configure directly. Example:

   ./configure CFLAGS="-march=i686"

Other user variables configure respects are:

An example combining some of these would look like:

   ./configure CC="/opt/intel/bin/icc" LD="/opt/intel/bin/xild" \
   CPPFLAGS="-I/usr/local/include/dvdnav" LDFLAGS="-L/home/guenter/xine_libs"

If you have a recent gcc you can try to compile "more" k7 support in (esp. better instruction scheduling). If the configure script should fail to detect your processor/gcc correctly, try passing the canonical system name for your machine to configure with the --host option, e.g.

   ./configure --host=k7-pc-linux-gnu

Sure. First set up a subdir where you install your private software, eg.

   mkdir ~/xine

Then you have to set a few environment variables – it's probably a good idea to add this to your ~/.bashrc (or somewhere similar):

   export PATH="$HOME/xine/bin:$PATH"
   export LD_LIBRARY_PATH="$HOME/xine/lib:$LD_LIBRARY_PATH"

Now you can unpack tarballs e.g. in ~/xine/src (mkdir ~/xine/src if necessary) and do a

   ./configure --prefix=$HOME/xine
   make install

You also need to tell frontends using xine-lib, where to find it:

   ./configure --prefix=$HOME/xine --with-xine-prefix=$HOME/xine

For compiling xine under Windows with MinGW, CygWin or MS Visual C see README.WIN32.

For cross-compiling xine under comfortable unix-like environment with MinGW see README.MINGWCROSS.

xine supports VCD and SVCD playback out-of-the box. Similar to DVDs, make sure you have a /dev/cdrom alias pointing to your CDROM drive which you will use to play back the (S)VCD.

At the moment, CD-i formats are not supported by xine.

Do not try to mount the (S)VCD. Simply insert it into your CDROM drive and hit the VCD autoplay button or start something like gxine vcd:/ or xine vcd:/ from the command line.

Quicktime is just a system layer (container format) which can contain various different audio and video formats. The system layer itself is fully supported in xine. However, some quicktime audio/video codecs are not natively supported yet. Luckily, if you are using a x86 compatible machine (any recent PC hardware should do) you can install and use the original Quicktime DLLs and watch most streams (trailers) that can be downloaded from the net.

Possibly the most convenient way to get the Quicktime DLLs is to download them from the MPlayer website http://www.mplayerhq.hu/design7/dload.html . The package is called "essential". Unpack it and move everything you find inside to /usr/lib/codecs (actually you can place them anywhere you want, e.g. someplace in your home directory, but then you'll have to set decoder.external.win32_codecs_path in your xine config file accordingly). Restart xine then and you should be able to watch Quicktime trailers.

While the container format (system layer) ASF (wmv is just an alias) is fully supported in xine, for newer windows media 9 based streams you'll need to install windows binary codecs (.DLLs).

Possibly the most convenient way to get the Windows DLLs is to download them from the MPlayer website http://www.mplayerhq.hu/design7/dload.html . The package is called "essential". Unpack it and move everything you find inside to /usr/lib/codecs (actually you can place them anywhere you want, e.g. someplace in your home directory, but then you'll have to set decoder.external.win32_codecs_path in your xine config file accordingly). Restart xine then and you should be able to watch windows media streams.

At the time of this writing DVB support is a very new and experimental feature in xine. The number of supported cards is pretty limited at the moment. See doc/README.dvb (in the xine-lib tarball) for details.

Use something like:

   cat stream.mpg | gxine stdin:/

In xine 0.9.13 this used to be:

   xine foo.avi%bar.sub

Latest xine-lib modules (1-beta3 or newer) support external subtitles for any media file, not only AVI. In order to use it you can pass a special MRL construction like:

   xine file://path/to/test.mpg#subtitle:/path/to/file.sub

The external subtitles support can also be used by any xine frontend. Currently xine-ui and kaffeine implement this feature with a subtitle selection dialog.

Your hardware might be too slow for xine. Make sure you turn on all speed optimizing options. A few things you should check (in order of importance):

Video output can be further improved by tuning your linux kernel:

Linux 2.5/2.6 will probably have these improvements out of the box.

Miguel Freitas has written a nice article about his kernel multimedia experiments .

Check out the the corresponding README files in the directory xine-lib/doc.

aalib is an ascii art library. xine comes with an aalib video output plugin so you can watch movies in your xterm, on the console or on your old vt100 – very cool ;> … another nice option is to preview movies on a remote server in your shell over ssh.

To use it make sure you have aalib installed correctly before you configure/build xine-lib and xine-ui. In addition to the xine binary a binary named aaxine should get built and installed. You can then use something like:

   aaxine foo.mpg

to use aalib video output.

While xine's focus is clearly on software decoding, the dxr3 is supported.

You can find more information about using xine with the dxr3 here (also covers how to do tv output using the dxr3).

Currently xine support audio output via OSS (Linux 2.4 and most *BSD audio drivers), ALSA 0.9 and 1.0 (ALSA 0.5.x is no longer supported), aRTs (KDE 3's sound daemon), ESounD (esd, gnome's sound daemon not recommended because it has serious issues with a/v sync), JACK, PulseAudio, plus platform-specific output through Sun devices for Solaris and NetBSD and Irix output.

Congratulations, you seem to have an original movie audio track there.

Uhm. So you don't like it. Well, there are two things you can do:

If this happens with any video, first try a different audio driver (gxine -A oss, gxine -A arts, xine -A alsa …).

If this problem only occurs with one specific stream, maybe switching to a different audio channel (using the gui) helps. Some DVD streams have audio on strange channels.

If all this doesn't help, maybe you're missing an audio codec or you found a bug. If you decide to post your problem on the xine-user mailing list, make sure to include all console output xine produced and also clearly state what type of stream you tried to play back or, even better, make a test stream available somewhere for developers to download and try.

Yep, it can do that using OSS or ALSA drivers, provided that the driver supports it. However, since xine cannot detect if there are actually speakers connected to the additional channels, you'll have to activate that feature manually.

You can do this either in the config dialog while xine is running (press the config button on the xine panel and go to the AUDIO tab) or have it the complicated way by editing the config file yourself which is located in your home directory in .config/gxine or .xine:

   audio.output.speaker_arrangement:Surround 4.0
   audio.output.speaker_arrangement:Surround 4.1
   audio.output.speaker_arrangement:Surround 5.1

xine can do that too. Pretty much the same story as for 4-/5-channel surround (see above). You can either use the config dialog or edit the config file (~/.xine/config or ~/.config/gxine/config) yourself:

   audio.output.speaker_arrangement:Pass Through

The following explains how to get the above configuration going with xine. Some parts of it may applicable to other configurations (cards that use the EMU10k1 chip) as well.

   cp /usr/src/linux/configs/kernel-2.4.18-i686.config /usr/src/linux/.config

   /sbin/modprobe -rv emu10k1.o ac97_codec.o

   # delete emu10k1
   # delete ac97_codec
   # delete soundcore

   make install-tools

   CARD_IS_5_1=yes
   USE_DIGITAL_OUTPUT=yes
   ENABLE_TONE_CONTROL=yes
   AC3PASSTHROUGH=yes
   ENABLE_LIVEDRIVE_IR=no
   INVERT_REAR=no
   MULTICHANNEL=yes
   ROUTE_ALL_TO_SUB=no
   ANALOG_FRONT_BOOST=no
   SURROUND=no
   PROLOGIC=no
   ENABLE_CD_Spdif=yes
   ENABLE_OPTICAL_SPDIF=no
   ENABLE_LINE2_MIC2=no
   ENABLE_RCA_SPDIF=no
   ENABLE_RCA_AUX=no

   alias sound-slot-0 emu10k1
   post-install emu10k1 /usr/local/etc/emu-script

   /sbin/depmod -a

   /sbin/modprobe emu10k1

   audio.output.speaker_arrangement:Pass Through

   center pin jackplug ------|----- center pin RCA plug
                   GND     __|__    GND

   xine dvd:/1 -a 0

Some xine drivers do not support volume changing although the GUI will show the volume bar. Usually this is not xine's fault: aRts C API, for example, doesn't offer any volume property to applications. Similarly, with ac3 pass through it is not possible to set the volume.

Note that recently we added support to "simulate" volume in aRts by changing sample values on-the-fly before delivering them to the driver. Not as good as having access to sound card's mixer but at least users will not complain about lacking of volume bar anymore! :)

Might be a soundcard problem, if it only comes in longer intervals. Your soundcard does not keep it's sampling frequency accurately enough, which results in audio and video getting out of sync and xine has to compensate. If you see the message only from time to time, you might remedy it by using the resampling sync method. You can do this by setting the configuration entry audio.synchronization.av_sync_method to resample.

If you receive the metronom message more often, maybe switching to different drivers (alsa to oss or vise-versa) can help here. It has also been reported that setting the configuration entry audio.synchronization.force_rate to the native sampling rate of your soundcard (try 44100 and 48000) helps sometimes.

Another, whole different possibility is that you have some background process running which is messing with the clock (like some ntp client – chrony, ntpd, …).

Occasional messages of "fixing sound card drift" may happen on start and when playing a long stream (like a movie). This is normal behaviour, nothing to worry about.

You are using the OSS audio output plugin, right? In order to keep video and audio in sync, xine regularly queries the audio driver for the amount of delay induced by the current length of the driver's audio buffer. Unfortunately some OSS drivers seem to be broken because the can return strange values here. This confuses the xine audio subsystem and makes it drop audio.

You should try the various settings of the configuration entry audio.oss_sync_method. The options getodelay and getoptr ask the driver and might therefore show the problem. But chances are that only one is broken and the other works, so you should try them both first, since they are the most accurate. The option probebuffer does not ask the driver directly but tries to determine the buffer length from outside. This should work with any driver and is the way to go, of the driver dependent methods fail. softsync is the least accurate and should be used only in emergency situations.

Probably your hardware is simply too slow – see above for some hints on how to speed things up.

Another possibility is that you using a buggy Xv driver, see the next questions.

You are either watching a very boring video (just kidding) or you are suffering from a bug in the Xorg 6.7 implementation of X11.

The workaround is to add the line

   Option "XaaNoOffscreenPixmaps"

in the Device section of your X server configuration (usually /etc/X11/xorg.conf or /etc/X11/XF86Config).

This points to a problem with the Xv extension, which is used by xine to display the video image. To verify this, try running xine with the XShm video output plugin:

   xine -V XShm

If that works fine, you just proved, that the Xv extension is buggy. xine will remember the last used video output plugin, so the setting will stay at XShm. You could simply continue using this, but XShm is a lot slower than Xv, so read on and see if you can get it working. Usually you should look for updated versions of the X driver module that belongs to your graphics card.

Other possibilites are limitations in either your X driver module or your graphics hardware. If your card could somehow be running out of ressources (graphics RAM perhaps) and displays an incorrect Xv overlay because of that, try reducing the display resolution and/or colour depth.

Consult the next question for more details on Xv.

xine will normally use Xv by default if it is available. In some cases you might need to choose Xv playback manually (when the ~/.xine/config file for some reason says that you want to use XShm):

   xine -V Xv

If this doesn't work for you, it may be possible that Xv is not present on your system.

First you need to install/use X.org or XFree 4.x. Once you got that you have to make sure the X drivers you're using are supporting Xv on your hardware. Here are some hints for individual gfx chips:

Looks like some colours on your GUI match the colour key which Xv uses. You can change the colour key value to avoid this. There should be a line like:

   video.device.xv_colorkey:2110

in your ~/.xine/config file where you can change the colour that's used by xine for the video overlay.

Tell xine to prefer textured video. There should be a line like:

   video.device.xv_preferred_method:Any

in your ~/.xine/config file where you can change the preferred method used by xine for the video overlay.

It may be that your graphics card or driver doesn't have the necessary support for textured video, or the video is rendered too slowly.

If you find that textured video is significantly slower or isn't supported, you should either not use compiz or tell xine to use the xshm video output driver.

Usually xine discovers the screen aspect ratio by querying the X-server and then adjusts the video automatically to make it look right. However, if that doesn't work try pressing "a" to manually change the aspect ratio.

If you have a wide screen monitor, make sure the X-server is correctly configured. The X-server must know the physical size of the screen, which is independent of the resolution being used.

For X.org, the screen size should be set in the "Monitor" section in the file /etc/X11/xorg.conf, as in the example below:

   Section "Monitor"
      Identifier   "Monitor0"
      VendorName   "Monitor Vendor"
      ModelName    "DDC Probed Monitor - ViewSonic G773-2"
      DisplaySize  320	240
      HorizSync    30.0 - 70.0
      VertRefresh  50.0 - 180.0
   EndSection

For XFree86, the filename is normally /etc/X11/XF86Config.

Where DisplaySize specifies, in millimeters, the physical size of the monitor's picture area.

Sometimes xine will output a message like that:

   200 frames delivered, XX frames skipped, YY frames discarded

The difference between these counters is a little subtle for the non developer. There are two threads running in order to display video: the decoder thread will deliver frames to the video output thread. The latter is responsible for scheduling the frames to be displayed at the right time.

If your system can't keep up with decoding requirements, decoder will deliver overdue frames. Imagine if it finished decoding the frame tagged for displaying at 11:30 but xine clock marks 11:31. When this situation is detected, xine will try to skip decoding a few frames to recover. Not every decoder may support this feature.

When the frame is decoded to be shown somewhere in future but the output thread doesn't get scheduled in time by the operating system to complete the operation, the frame is discarded. One cause might be the disk access operation, which may halt the system for a few miliseconds without DMA. See performance section tips above.

Note that if a decoder can't skip frames for some reason, you would never see frames skipped (they would be all discarded).

This frequently happens with new Xv drivers or when switching to a different video card. Background is that different Xv drivers often use different ranges for the contrast/brightness/saturation settings.

To fix this, try opening the xine settings window and try adjusting the sliders for contrast, brightness and saturation.

Please note that some frontends save these settings in their config file so when you have found a working combination, make sure you exit xine cleanly so the values are saved.

xine supports several video drivers for outputing the image. These will differ on how the frames are copied to the video card memory, whether colourspace conversion and scaling is done in software or hardware, among other things. They may also differ on ease of use and stability.

Most of the time, Xv should give the users a good trade-off between quality, compatibility and ease of use. This is why xine tries to use Xv by default.

However some users may want to explore better the available hardware capabilities (eg. syncing frame drawing with monitor refresh). Also some Xv drivers contain slow copies and accessing the video card directly may yield performance gains.

Drivers that access hardware directly includes VIDIX (warning: requires root priviledges or kernel helper). User may try one of those, but should be warned that with root access they can cause the system to crash hard. The support is also limited to a couple of graphics cards only.

Graphic workstations like SGI have usually a good support for OpenGL. In that case, using OpenGL may be a better choice than XShm. However for most desktop systems the performance of OpenGL will be quite bad.

Since version 1-rc3 of xine-lib supports a new method for rendering OSD (On Screen Display) and subtitles. This method uses a X11 extension called XShape that allows using screen resolution instead of stream resolution. It is called "unscaled" OSD because it does not scales with the video being played.

Suppose you are watching a 320x200 video in full screen. Normal OSD would be blended at 320x200 and then scaled to full screen (lets say, 1024x768), resulting in big and ugly fonts. The unscaled overlay is drawn directly to screen, creating a sharper and better looking OSD.

There are side effects too. Sometimes the unscaled overlay show some glitch just before disappearing. Some people may be annoyed enough by that and might want to disable the usage of unscaled overlay altogether.

Unscaled OSD usage by subtitles and xine-ui is controlled by the following settings (~/.xine/config or ~/.config/gxine/config):

   gui.osd_use_unscaled:0

   subtitles.separate.use_unscaled_osd:0

If you are using xine-lib version 1-rc3 or newer, this is probably due buggy XV drivers that do not support unscaled OSD (the XShape extension) properly.

There have being reports of some ATI drivers that don't allow displaying anything over the video. The VIA Epia binary drivers is reported to leave a black box where the OSD was displayed.

The problem may be fixed by either updating the video driver, or disabling xine unscaled OSD support.

xine blends most overlays, specially the ones from DVD discs, directly over the image (scaled OSD). Unfortunately most codecs (like MPEG2) use a subsampled image format (YV12) that makes properly blending an interesting challenge.

In short, this is a known xine bug. There have being discussions on improving the blending quality but, so far, nobody implemented a better (scaled) overlay renderer. Contact developers if you want to try doing something about it.

You are probably using a xine-lib version older than 1-rc3. Try upgrading your copy and read the section about unscaled osd.

It is possible, but older xine versions may not support it. There are two alternatives for rendering the subtitles outside the video image:

Also notice that DVD overlays (including subtitles) are meant to be displayed in a fixed position, this is how the DVD menu highlighting works. xine does not support moving them.

xine can use two kinds of fonts:

The font for text subtitles is selected via config option subtitles.separate.font. You can specify xine font name (sans, serif, …) or file name of the TTF font. The directories $prefix/share/xine/libxine1/fonts and ~/.xine/fonts are searched for the fonts, with $prefix being the place xine-lib was installed to. Usually this is /usr/local or /usr. TTF fonts are also searched for in the current directory.

xine's native subtitle fonts can be generated from TTF fonts with the utility xine-fontconv. It isn't compiled and installed by default but you can make it manually. You'll need freetype and zlib packages together with their versions for development plus a compiler, of course ;) Here's how you build xine-fontconv:

You'll need some TTF font for generating. Characters in this font should cover all codepages you want supported, otherwise you'll have missing characters.

Syntax is:

   ./xine-fontconf font.ttf font_name [encoding1 [encoding2 […]]]

For example default font sans was generated with following command:

   ./xine-fontconv Aril_Bold.ttf sans iso-8859-1 iso-8859-2 iso-8859-5 \
                                      iso-8859-9 iso-8859-15 cp1250 cp1251

There are displayed messages about missing characters on the screen during generating. It's OK if the missing characters are U+007f..U+009F. These characters come from iso-8859-1 and they aren't displayable.

The encoding of the external subtitles is expected to be iso-8859-1 by default. You need to set an appropriate encoding in the config option subtitles.separate.src_encoding. Note that you also need a font which contains all characters from the given encoding.

The default font sans and fonts serif and mono cover these encodings:

xine itself is unable to crash X, so when your X server just shuts down or restarts with the login screen, there is something wrong with your X setup. Most common are problems with the Xv extension. Try running xine with the XShm video output plugin:

   xine -V XShm

If that works fine, you just proved, that the Xv extension is buggy. xine will remember the last used video output plugin, so the setting will stay at XShm. You could simply continue using this, but XShm is a lot slower than Xv, so consult the section on Xv and see if you can get it working. Usually you should look for updated versions of the X driver module that belongs to your graphics card.

You can select the audio driver using the -A option. So try:

   xine -A null

If you have ALSA drivers installed, try:

   xine -A alsa

If you run ESD (not recommended), try:

   xine -A esd

If you run artsd, try:

   xine -A arts

You got the Xv extension, but your video card driver doesn't support it. First try to find a driver that does support Xv on your hardware (check your graphics card vendor). If your driver has Xv support but you can't get it working, try at a lower resolution (1024x768 is enough even for anamorphic DVDs).

If all that fails, you can still use plain X11/XShm:

   gxine -V XShm foo.vob

You probably don't have /dev/dvd (check that). If so, simply create a link /dev/dvd that points to your DVD device. Something like…

   ln -s hdc /dev/dvd

… should do the job. Also make sure you have read and write access on the device the symlink points to. See the dvd playback section for more information.

This error can be fixed by recompiling your kernel with the option "Use multi-mode by default" enabled in the IDE settings.

Probably xine can't access your input source. Most commonly this happens when you're trying to play locked/encrypted DVDs. Remember that xine can't play such DVDs out-of-the box for legal reasons (see above).

If it is legal where you live, you can try to install libdvdcss. Once you have done that and re-start xine, it should automatically detect and use it to play back encrypted DVDs.

Another reason could be that your (RPC-2) DVD drive isn't set up for the right region (see above).

First of all, make sure that your OSS Audio drivers are working (i.e. you can play music with other software). Maybe you're using alsa? If so, try gxine -A alsa to see if this helps.

The most common reason for oss not working is that some other program is accesing your audio device. If you're using linux, the command fuser /dev/dsp should give you the PID of the process.

If you are using GNOME, chances are that this is caused by ESD. Now you have two possibilities. Either deactivate ESD (temporarily) by right clicking on the sound monitor applet and selecting "Place Esound in standby" or just kill it. Then xine will use OSS audio output. The other method is to make xine use ESD for audio output with:

   gxine -A esd

This may result in worse playback – exact syncronization is not possible with esd, so using oss should be preferred.

If you are using KDE, there is the possibility that the aRts sound daemon is currently running and thus blocking your sound device. You can check that by starting the aRts control (in your KDE menu it should be under Multimedia). If it is running, you can either use the aRts audio output plugin:

   gxine -A arts

Or you suspend the aRts daemon by checking the appropriate option in your aRts control. (recommended)

Newer versions of arts have an auto-suspend mode – this can lead to some nondeterministic behaviour of xine if it is set up to use the audio device directly. Using arts is recommended in that case; however, you will lose the ability to do four/five channel audio output.

This is a performance related problem. If you have a fast computer and this message is shown from time to time when playing a DVD or CD, it's very likely that DMA is not enabled for your drive.

You have tried to play a stream using a unknown or unhandled codec. Possibly the file uses some obscure proprietary format and no information is available on how to decode it.

If you're on an x86 platform (e.g. PC hardware) you might want to try installing binary-only windows medial, real networks and quicktime codecs (see above).

You probably don't have the win32 dll needed to decode this file.

OK, yes, that shouldn't happen and you're upset. We can understand that. But, to help you and of course to fix this, we need some information. So, let's go through the checklist and maybe prepare a nice bug report for the xine bug tracker: