On Mon, Sep 26, 2005 at 11:53:09AM +0300, Jan Ekholm wrote:

There seems to be two solutions that are currently used:

Softdevice
http://www.vdr-wiki.de/wiki/index.php/Softdevice-plugin

I think that http://softdevice.berlios.de/ is the official home page.

Xine-plugin
http://www.vdr-wiki.de/wiki/index.php/Xine-plugin

Those seem to be the best homepages for the plugins, but as I'm no native German speaker (I can order a beer, but that's about it) I have a fairly hard time grokking the finer details of pros and cons.

What do you others use when you want to get a good image from VDR? Which of those plugins is the preferable solution in this case? The system in use should cope just fine with some decoding done by the CPU. The system has a Sempron-something 2400+ and an ATI fanless 9250 card (I think it was).

I'm using softdevice with a budget DVB-T card (Hauppauge Nova-T PCI 90002) on a Matrox G450 on DirectFB. For some reason, the Matrox TV-out connection eats more CPU than VGA. The 900 MHz Intel Celeron has enough power to deinterlace the picture. I think that something like 500 or 600 MHz would be the minimum requirement on a Matrox card. Other cards may require more processing power.

I don't have any experience with the Xine-plugin, but softdevice has gotten much more stable during this year. Crashes occur very rarely nowadays, even if the signal is bad.

Marko

Jan Ekholm wrote:

What do you others use when you want to get a good image from VDR? Which of those plugins is the preferable solution in this case?

I tried with a small VGA monitor with good results and with Nvidia s-video out for normal TV but found out soon that deinterlacing and again interlacing for s-video output is not a good idea.

Softdevice + I was able to make good looking 16:9 display settings (crop the nasty blue lines from left of 4:3 video) + Accompanied softplayer plugin uses familiar vdr look & feel for other video formats and music playback + Quite simple to setup for a set-top-box like setup - I have experienced some but fortunately quite rare hang-ups, watchdog restart may trash ongoing recordings - Not as many deinterlacers and post-processing settings as in Xine - Sometimes stuttering in video, especially in 1080i HDTV

Vdr-xine + Very stable, xine-ui or gxine may crash (very rare) but I have never seen vdr crashes or hangs + Smooth playback, normal TV & 1080i HDTV - I was not able to get rid of the blue vertical lines in 4:3 picture when rendered to 16:9 screen with correct aspect ratio. I couldn't find a suitable crop setting. Zoom in feature in xine doesn't help unless 4:3 picture is zoomed to fill entire 16:9 screen. - Requires quite a lot of scripting work for automatic running set-top-box like system, softdevice x11 requires too but here we have a bit more to care about +/- It is possible to use xine or vdr plugins to play other media such as mp3, avi, etc. I've preferred vdr plugins for music and xine for dvd playback.

Both of these are quite good choises in my opinion :^)

Cheers, Seppo

There is also some information in Linuxtv.org VDR Wiki: http://www.linuxtv.org/vdrwiki/index.php

Thanks, I didn't know about that one. Good stuff.

Xine has superior deinterlacing filters such as TomsMoComp and Greedy2Frame, which is very important for video fluidity and quality. I have not followed Sofdevice development recently, but at least with Xine-plugin, the MPEG-2 decoding and video display is separated from VDR to the Xine process. This should prevent VDR from crashing at decoding bugs (if there are any) and you can close Xine and X without worrying about VDR.

Well, as this is a dedicated VDR box without any keyboard, mouse or normal VGA screen restarting Xine is the same as restarting the whole system. I don't have a desktop where Xine will be running and where I can just restart it, it's all on the same headless system.

Good deinterlace is of course important, especially with a projector that natively wants a progressive signal.

ATI's X drivers may give you some gray hairs, but I have heard they've gotten better in the last year or so. Your system is powerful enough to handle HDTV software decoding and deinterlacing if you get XVideo working.

Heh, you expect us to see HDTV in Finland for a few years? Of course some HDTV content is available through satellite and could be fun to play with (still need to bite the gory tools and install a dish for that)... :)

Thanks for the feedback, it was much appreciated.

On Mon, 26 Sep 2005 15:06:07 +0300 (EEST) "Jan Ekholm" chakie@smultron.net wrote:

Well, as this is a dedicated VDR box without any keyboard, mouse or normal VGA screen restarting Xine is the same as restarting the whole system. I don't have a desktop where Xine will be running and where I can just restart it, it's all on the same headless system.

If the MPEG-2 decoder or some other display component in Xine crashes on a corrupted packet, VDR would still stay up. Also simultaneous recordings wont be interrupted. And even on a "headless" system (you still have the head which you use Xine on, don't you), with some scripting, you can shut Xine down when you are not actually watching anything, but there are recordings going on. This further improves stability.

Heh, you expect us to see HDTV in Finland for a few years? Of course some HDTV content is available through satellite and could be fun to play with (still need to bite the gory tools and install a dish for that)... :)

I meant that you don't have to worry about your system being fast enough for software MPEG-2 decoding. Our HDTV will be using MPEG-4 AVC format, which requires a couple times more horsepower though. I think we'll probably have to wait 3-5 years for terrestrial broadcasts.

-- Niko Mikkilä

Le lundi 26 septembre 2005 à 15:33 +0300, Niko Mikkila a écrit :

If the MPEG-2 decoder or some other display component in Xine crashes on a corrupted packet, VDR would still stay up. Also simultaneous recordings wont be interrupted. And even on a "headless" system (you still have the head which you use Xine on, don't you), with some scripting, you can shut Xine down when you are not actually watching anything, but there are recordings going on. This further improves stability.

I have a button on the desktop which when clicked starts xine full screen and connected to the VDR live TV stream. From then on everything is controlled via the remote including switch off and playing back recordings. I have gnome configured to start xine full screen when I insert a DVD too and from then on everything is controlled via the remote.

The main advantage of running X windows is that the box can be used for other things than watching TV. And on LCD or DLP projectors the quality of small text is just fine. My dream is a big LCD and a wireless keyboard to replace the ugly desk in my SOHO.

I meant that you don't have to worry about your system being fast enough for software MPEG-2 decoding. Our HDTV will be using MPEG-4 AVC format, which requires a couple times more horsepower though. I think we'll probably have to wait 3-5 years for terrestrial broadcasts.

And then it will be so locked down by DRM that you will need a Nokia box to see it...

Cheers

Tony

Jan Ekholm wrote:

Well, as this is a dedicated VDR box without any keyboard, mouse or normal VGA screen restarting Xine is the same as restarting the whole system. I don't have a desktop where Xine will be running and where I can just restart it, it's all on the same headless system.

you can use irexec and lircd to execute a script from your remote :-) Thus keeping a keyboard free zone.

Good deinterlace is of course important, especially with a projector that natively wants a progressive signal.

so right. The thing I really wish for in xine is a magic deblocking filter to remove artifacts in high motion scenes on dvb. This situation has improved a little over the last two years.

A good PJ can highlight even the most subtle artifacts in mpeg :-/ good video processing plugins are very important and xine provides the flexibility and choice here.

Simon

Jan Ekholm a écrit :

Can one run DirectFB with a card that doesn't have a direct driver? AFAIK

You can still use vesafb with the generic software renderer, but you will lack most hardware optimizations, specialy pixel format conversions.

only Matrox cards and some Epias really work with DirectFB, others have no drivers. I fought quite a lot with DirectFB about a year and a half ago when it was investigated for another purpose, but in the end DFB

There is an ATI driver since this time, I think. And DirectFB improves regularly.

didn't really work too well (and that was with a more or less supported CLE266 chip). Somehow DFB also felt a bit heavy and CPU intensive compared to using normal X11.

DFB must be way lighter than X. In my case, it is nearly 80MB RAM less (counting X + Xine - softdevice). CPU utilization depends on hardware acceleration, WTR MPEG2. Nothing should impact CPU in DFB per se.

Le lundi 26 septembre 2005 à 17:07 +0200, Nicolas Huillard a écrit :

I sometimes need to reload DVB driver since Skystar looses IRQ handling (apparently solved in 2.6.13), so VDR is not really 24/7, but keeps working many days in a run.

Hmmm... I think this may be the issue that I am having with 2.6.11.10 Guess I'll try newer modules

Tony

On Mon, Sep 26, 2005 at 05:07:35PM +0200, Nicolas Huillard wrote:

The softdevice developers are really productive : there is a recent "suspend-patch" for VDR, that allows to stop MPEG routing to the display when not in use. This should apply to any output method (FF-card, Xine, softdevice...) This is linked to a key on the remote, to allow easy suspend/resume.

I wouldn't consider myself a softdevice developer. I've merely submitted some bug reports and suggestions, and Stefan Lucke and Martin Wache have been doing the hard work.

My suspend patch and the relay control plugin (available from http://www.funet.fi/~msmakela/software/vdr/) work on vdr 1.3.30 and above. I've tested the most recent versions on vdr 1.3.32 and 1.3.33.

I cannot recommend the suspend patch for users of hardware-based MPEG decoders. The proper way to suspend the video output would be to send an encoded black picture to the output device, like the suspendoutput plugin does. Some day, I might try to improve that plugin, but don't hold your breath.

Maybe vdr 1.5 will get a suspend feature out of the box, given that software-based decoding solutions can decode HDTV channels on powerful processors with advanced power saving features. On my Celeron system, suspending the video output will reduce power intake by about 15 watts - perhaps a little more if the VGA output were somehow switched off.

Marko

I demand that Nicolas Huillard may or may not have written...

[snip]

DFB must be way lighter than X. In my case, it is nearly 80MB RAM less (counting X + Xine - softdevice). CPU utilization depends on hardware acceleration, WTR MPEG2. Nothing should impact CPU in DFB per se.

Something else to try: GTK+ (fb port) with gxine. I'd be interested in knowing how well this works and in any patches for gxine which are needed to make this work (if it doesn't already).

Jan Ekholm skrev:

Hi, snip

What do you others use when you want to get a good image from VDR? Which of those plugins is the preferable solution in this case? The system in use should cope just fine with some decoding done by the CPU. The system has a Sempron-something 2400+ and an ATI fanless 9250 card (I think it was).

What about subtitling? Will ttxtsubs work with Softdevice?

/t

On Mon, 2005-09-26 at 21:26 +0100, Darren Salt wrote:

I demand that Jouni Karvo may or may not have written...

...

Btw. if someone has any hints on how to reduce used cpu cycles, they are warmly welcome. And yes, I use the fglrx driver - without that the picture is jerky.

Something's evidently not right with your setup. Are you using Xv? Have you tried the native R200 support in a recent 2.6 kernel and X?

A patch which recently went into xine-lib CVS HEAD helps somewhat (it optimises the video buffer allocation somewhat, which affects things like software deinterlacing).

There's also a new R200 driver in DirectFB CVS. http://www.directfb.org/index.php/viewcvs.cgi/DirectFB/gfxdrivers/r200/

I haven't tested it myself nor heard from anyone who would have, though. If someone has tried it, reports would be appreciated.

On Tue, 2005-09-27 at 20:38 +0300, Jan Ekholm wrote:

On Tuesday 27 September 2005 18:43, Ville Skyttä wrote:

...

There's also a new R200 driver in DirectFB CVS. http://www.directfb.org/index.php/viewcvs.cgi/DirectFB/gfxdrivers/r200/

I haven't tested it myself nor heard from anyone who would have, though. If someone has tried it, reports would be appreciated.

Any ideas wether the CVS version normally is useable?

No idea.

Some projects mostly check in stuff that could be a release, while some projects check in stuff that doesn't even compile. My playing time is very limited so I rather not test with something that doesn't even have a chance of working.

Yep, that's why I haven't bothered to test it either :)

hi,

Darren Salt writes:

...

The reason why a separate xine is nice is that currently the setup eats up all the CPU cycles. [...]

Hmm? I'm seeing around 30% CPU usage with gxine (2GHz Athlon, Radeon 9200, 266MHz bus, AGP 4x).

I used earlier a 2.6GHz P4 HT processor, and the processor load was approx 20% or less. It was really a surprise that a 2.4GHz non HT P4 would be so much slower. So yes, I suspect too that there is something weird going on.

It might be some setting in the kernel compilation parameters (no so obvious as MTRR, though). Top reports quite low percentages for different processes. 60% is shown to be user and 40% sy time, which is weird since the highest %CPU is with XFree86 at approx 6%.

Perhaps something about copying data unoptimally or weird context switching frenzy? (DMA?) I checked the kernel timer settings already (now use HPET).

...

Btw. if someone has any hints on how to reduce used cpu cycles, they are warmly welcome. And yes, I use the fglrx driver - without that the picture is jerky.

Something's evidently not right with your setup. Are you using Xv? Have you tried the native R200 support in a recent 2.6 kernel and X?

Yes, I use xv (xshm simply is too slow). I have not tried kernel radeon driver - and the current kernel is 2.6.9 (I have not yet been able to get the ATI driver to work on newer kernel versions)

A patch which recently went into xine-lib CVS HEAD helps somewhat (it optimises the video buffer allocation somewhat, which affects things like software deinterlacing).

There is something else fishy, since changing software deinterlacing options does not change cpu usage considerably.

Thanks for your comments.

yours, Jouni

Hi,

Darren Salt wrote:

Something else to try: GTK+ (fb port) with gxine. I'd be interested in knowing how well this works and in any patches for gxine which are needed to make this work (if it doesn't already).

This is a bit off-topic but perhaps not totally:

I haven't tried fb but instead a minimal X running as 2nd session by enabling one more session and automatically logging in user vdr through gdm.conf settings. The problem with gxine is that command line parameter "-f" doesn't work trough my .xsession script. I think I got a full screen mode but no video (black screen, I don't remember what happened to audio). Gxine also seems to require a window manager so I started metacity as well. This same .xsession script works without "-f" for gxine. Similar script works with xine-ui and it doesn't require a window manager. Gxine has a very nice user interface, it would be good if this could be corrected.

The versions I tested were about two weeks old cvs versions of libxine and gxine.

Here is my .xsession

--

#!/bin/sh

## Start a window manager /usr/bin/metacity &

## TV-out setttings /usr/bin/nvidia-settings -l

## Run Gxine in fullscreen mode /usr/local/bin/gxine -f -S -V xv -A alsa vdr:/tmp/vdr-xine/stream#demux:mpeg_pes

## Run xine in fullscreen mode #/usr/local/bin/xine --no-splash --hide-gui --fullscreen -V xv -A alsa vdr:/tmp/vdr-xine/stream#demux:mpeg_pes

--

Best regards, Seppo

hi,

Darren Salt writes:

...

The reason why a separate xine is nice is that currently the setup eats up all the CPU cycles. [...]

Hmm? I'm seeing around 30% CPU usage with gxine (2GHz Athlon, Radeon 9200, 266MHz bus, AGP 4x).

<...>

Something's evidently not right with your setup. Are you using Xv? Have you tried the native R200 support in a recent 2.6 kernel and X?

Finally, after upgrading to 2.6.13.2, I found the problem! (what a relief) After upgrading, the CPU cycles were properly reported and top gave the crucial hint...

FYI:

If you start xine in background directly from init scripts with --stdctl it seems to hog all your spare CPU cycles. Removing this (unnecessary in this case) option did drop CPU usage from constant 100% to a total of about 20%.

yours, Jouni