File:  [DVB] / libsoftmpeg / README
Revision 1.3: download - view: text, annotated - select for diffs
Fri Feb 13 09:10:29 2004 UTC (20 years, 3 months ago) by hunold
Branches: MAIN
CVS tags: HEAD
- add a short description that explains how to set up the
framebuffer device correctly (just wondered about his on my home system... ;-)

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.

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.

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

LinuxTV legacy CVS <linuxtv.org/cvs>