libsoftmpeg =========== 1) The idea ----------- Many people have recently decided to work on software only mpeg decoderes. The goal is to have a cheap DVB x86 box with vdr or MythTV on it, but only using a so-called budget DVB card without onboard mpeg decoder. 2) The problems --------------- The "linuxtv-softmpeg" project tries to provide the "libsoftmpeg" library, a thin library on top of existing technologies that adresses the following problems: - low-delay buffering (for fast channel switches) - mpeg audio decoding - audio and video syncronization - audio rendering - video rendering - long term playback stability 3) Existing "solutions" ----------------------- In the past, there have been different approaches to solve these problems, but they are not quite satisfying yet. For example, while "mplayer" and "xine" are excellent movie players, they use huge buffers for buffering and therefore make channel switching nearly unbearable. Additionally, they lack long-term stability, because they don't synchronize to the incoming stream and buffer over- and underrums quite frequently occur. (see below for details) The "softdevice" plugin from VDR is on the right way, but unfortunately it is bound to VDR. Other projects like "mythtv" and the like need to duplicate the code or invent the wheel again, 4) libsoftmpeg -------------- In order to use this project, you need: - DirectFB and a supported gfx adapter (cle266 or Matrox G200/4x0/5x0 is fine, vesafb is only enough if you have a horibbly fast machine ;-) - FusionSound, which needs OSS or ALSA (with oss emulation) sound drivers - libavcodec, version 0.4.8 from http://ffmpeg.sf.net is fine "libsoftmpeg" already does the following: - low-delay buffering for audio and video, adjustable audio prebuffering (currently 500ms, channel switching is usually done in less than a second) - mpeg audio decoding via libavcodec from "ffmpeg" project - mpeg video decoding via libavcodec from "ffmpeg" project - audio and video synchronization using a "sync-to-audio-pts" approach and "free flowing video display" (see below for a detailed description of my ideas) - video rendering using DirectFB (http://www.directfb.org), a thin library ontop of the Linux framebuffer device. DirectFB hosts a "cle266" driver which drives the tv out of the EPIA/cle266 boards very well - audio rendering using FusionSound (http://www.directfb.org/fusionsound.xml), a thin library on top of DirectFB and Fusion (fast interprocess communication), which supports sound mixing, pitch adjustment and other neat features. Sound mixing is very important, other applications can overlay system sounds onto the live tv audio. 4) How to get it to work ------------------------ All this is working fairly well, a demonstration application is included with the library that reads from the DVR device (so you need "szap" for example to tune to a service and have the data put to the DVR device) and displays audio and video. It should be easily possible to use "libsoftmpeg" in "vdr", too. Please apply the "fusionsound_realtimepriority_reset_on_flush.diff" patch to FusionSound first via "patch -p0 < [...]) in the FusionSound directory and compile again. This adds realtime priority to the audio feeding thread. If you omit this, the audio thread might starve and sound will be jerky. If you do a "./autogen.sh ; make install" you'll get a demo application called "dfb_ts", which reads a transport stream from the DVB dvr device. You need to tune your frontend with "szap" for example and redirect the data to the dvr device with the "-r" switch. For example: > szap -r "Das Erste" Then you can start the demo application and provide the video and audio pids for the service you like to watch (have a look at "szap", it tells you the correct pids): > ./dfb_ts /dev/dvb/adapter0/dvr0 0x7ff 0x800 4) The future ------------------------ What's currently completely missing is long-term playback stability. As you probably know, the problem arises due to the different clocks used for dvb encoding and decoding. See below for a detailed description of the problem and my ideas on how it can be solved on x86. The next major step would be to add the ideas of long-term playback stability and the cle266 mpeg decoder stuff to the library, so that EPIA users can use the hardware acceleration. "IDEAS" contains a description of the concepts currently implemented for audio/video synchronization and the ideas for long-term playback stability. 5) If you want to participate ----------------------------- There is a mailing list for this project. Write a mail to with "subscribe linuxtv-softmpeg" in the subject to subscribe.