[vdr] Success with VDR and EPIA-M motherboard + h/w decoding /XINE plugin

["Colin Paton" <ac2crp@blueyonder.co.uk>]

Hi all,

I'm reporting the following in case it is of any interest to anybody...

After being slightly confused by all the talk on the VIA Linux forum I
decided I'd take the plunge and see if I could get an EPIA-M motherboard
working with VDR using a Nova-T card without hardware decoding. This has the
CLE266 chipset.

My findings are as follows:

XINE PLUGIN
----------------

I tried the xine plugin from Reinhard Nissl (Thanks very much for
implementing that). That seems to work quite well, apart from the following
issues:

  - Intermittent crashing of xine. By crash I mean xine exits randomly. I
haven't yet tried to debug this (I don't know if I have the guts to delve
into xine!).
  - The documented buffer problems when changing channel/fast forwarding.
  - The documented 'stopping' of xine - 'play' restarts this.
  - xine crashes when a channel with lots of errors is received. I get lots
of those thanks to my aerial :-( It fails with an error in demux_pes.c:686 -
parse_pes_for_pts: Assertion '0' failed. This is probably fair enough if it
is trying to find the pts in a dodgy stream. I guess xine assumes that the
received signal is error free!

xine plays back fine through the TV out with about 40-60% CPU utilisation.
It seems that it is therefore possible to use a 1GHz Nehemiah EPIA-M for
software only usage with dvr, taking into account the issues above.

I'm using a standard RedHat 8.0 install, but with kernel 2.4.23-pre4-epia2.
This kernel seems to work with xv as long as the VIA binary X driver is
used.

HARDWARE DECODING
-----------------------------

I didn't quite feel I had the guts to delve into xine today so I started
looking at the mpeg2dec code which I found somewhere while looking through
the VIA Linux forums (but I can't remember where) - this seems to have been
patched by VIA to make calls out to the hardware decoder.

After a bit of patching I've got it to work. It plays back a 720x576 MPEG at
60 frames per second using only 50% of the CPU.

To get mpeg2dec to work I used 'vdrsync.pl' to extract the video stream from
a .vdr file. I then played it with 'mpeg2dec /tmp/e0.mpv'

I've only tried the hardware decoding with the standard redhat 8 kernel and
via binary v4l driver. I believe that somebody has posted a patched kernel
containing the v4l source, so I will try that later.

- mpeg2dec is only a very simple decoder which doesn't play sound, or
synchronise to the correct rate. (I assume that is why I got 60fps. Bit fast
to watch programs with...)
- Looking at the vdr plugin architecture I can create my own driver, by
subclassing one of the vdr plugin classes (cDevice or something. I forget
offhand). I should implement 'playVideo' and 'playAudio'.

Making a custom VDR plugin based around mpeg2dec seems attractive to me, as
it means that:

- X is not required - the plugin can interface with the VIA framebuffer
code.
- The 'custom' plugin can also use the alpha blending functionality of the
CLE266 for an on-screen display.

However, I have some questions which perhaps somebody can help me with:

- I assume that I can find a library to do the audio decoding in
software/pinch this from xine/mplayer etc. Can anybody think of an easy
option to do this - something which takes MP2 frames and spits them straight
out to alsa?
- Would I have to do all the A/V sync myself?

I'm trying to decide the correct way forward.

The advantages of the custom plugin are:

- Don't have to go through fixing xine/mplayer to make it cope with errored
data. This is the biggest issue for me - for DVD use we probably do want the
assertions in there, but not for DVB use.
- Fairly clean design, also allows the hardware alpha blending overlay.

The disadvantages are:

- Tied to specific hardware. This is probably not a bad thing though, as
that's half the point - we want to use the hardware to its full potential.

- It sounds suspiciously like I'm trying to re-implement the whole of xine
which I must admit sounds to be a tad stupid. However, it seems that all
that would need to be added to mpeg2dec would be some audio playback code,
and possibly a/v sync code (which is a bit iffy in mplayer and a bit in xine
too it seems).

I have a horrible feeling that what I am proposing is a bit mad. However,
I'm just excited having seen the board playback 60 frames per second with
50% CPU usage. Perhaps one of you more sane people can comment?

Thanks,

Colin








-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.