Return to README CVS log

Up to [DVB] / libsoftmpeg

- make the README more verbose about the fact that you should apply the
FusionSound realtime priority patch

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
------------------------

Currently, there is

- a demonstration application called "dfb_ts" that reads from the
DVR device or a recorded transport stream (.TS file) from a file
and displays that using DirectFB and FusionSound 

- a vdr plugin called "softmpeg".

Most likely you'll get warnings like this when using "libsoftmpeg":
 (!!!)  *** CAUTION [device buffer underrun?] *** core_sound.c (354)

Please apply the "fusionsound_realtimepriority_reset_on_flush.diff"
patch to FusionSound and compile again.

> cd ../FusionSound
> patch -p0 < ../libsoftmpeg/fusionsound_realtimepriority_reset_on_flush.diff
> make && make install

This adds realtime priority to the audio feeding thread. If you omit
this, the audio thread might starve and sound will be jerky.

Before you proceed, make sure that your framebuffer device is set
to 720x576 at 50Hz refresh rate. A suitable fb modes entry looks like
this:
mode "720x576-50"
    geometry 720 576 720 576 16
    timings 31208 144 40 32 10 128 3
endmode

Make sure to use "fbset -a 720x576-50" after each startup -- the sync code
currently relies on this.

4a) "dfb_ts"
------------

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

4b) The vdr plugin "softmpeg"
-----------------------------

There is a vdr plugin called "softmpeg" in the "softmpeg" directory,
which basically works (osd is supported, too) but is in very alpha
stage.

First copy the whole directory the source directory of you vdr installation:
(Substitute <vdr-dir> with the name of your main vdr directory)

> cp -r softmpeg <vdr-dir>/PLUGINS/SRC/

Then you need to rebuild all plugins:

> cd <vdr-dir>
> make plugins

Then you can run vdr and tell it to use the softmpeg plugin to display
the output:

> ./vdr -P"softmpeg"

If you cannot see any overlay windows, try to set the environment variable
DIRECTFB_VIDEO_IS_OVERLAY like this and start again:

> export DIRECTFB_VIDEO_IS_OVERLAY=1

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
<ecartis@linuxtv.org> with "subscribe linuxtv-softmpeg" in the subject
to subscribe.