On Fri, 2005-03-04 at 12:57 +0100, Nicolas Huillard wrote:
Laurence Abbott a écrit :
How easy was it to get your Epia M1000 going with hardware MPEG decoding? Is it as simple as: boot, start vdr with xine plugins, start X sending out the S-video connector, start xine fullscreen?
I start X using the startx command as a special-purpose user, then it uses it's .xinitrc that run xine with all needed options (that's a standalone STB, so no regular X on this). Softdevice is a better alternative : no need to run a display client + the vdr server : just launch vdr and you're done. No HW MPEG2 decoding, though.
I now have an Epia MII-12000 and I'm in the process of setting it up. I'm assuming that others on here have tried these things so I thought I'd save a bit of time and share the answers with others who may be interested (and Google didn't really give me any straight answers!).
As I understand it, there are two methods of getting accelerated MPEG decoding with vdr:
1. Using X (as described above) with a kernel DRM module and a (patched?) version of xfree86 or xorg. Use xine output plugin.
2. DirectFB in conjunction with a kernel module. Use softdevice output plugin.
Is either of these preferable? I would have thought the second because there is no overhead of running X as well but the post above says that DirectFB wouldn't use hardware decoding. Is this still correct? Or is DirectFB still very flakey? From what I've seen, there are about 3 different possible kernel modules, and the newest kernel patch I've found is for 2.6.8 (and I can't find a DVB kernel patch for that old a kernel!).
As I say, I have yet to try any of the above and was after some pointers before I delve into the realms of testing different options!
;-)
Cheers,
Laz
Laurence Abbott a écrit :
I now have an Epia MII-12000 and I'm in the process of setting it up. I'm assuming that others on here have tried these things so I thought I'd save a bit of time and share the answers with others who may be interested (and Google didn't really give me any straight answers!).
As I understand it, there are two methods of getting accelerated MPEG decoding with vdr:
- Using X (as described above) with a kernel DRM module and a
(patched?) version of xfree86 or xorg. Use xine output plugin.
- DirectFB in conjunction with a kernel module. Use softdevice output
plugin.
Is either of these preferable? I would have thought the second because there is no overhead of running X as well but the post above says that DirectFB wouldn't use hardware decoding. Is this still correct? Or is DirectFB still very flakey? From what I've seen, there are about 3 different possible kernel modules, and the newest kernel patch I've found is for 2.6.8 (and I can't find a DVB kernel patch for that old a kernel!).
As I say, I have yet to try any of the above and was after some pointers before I delve into the realms of testing different options!
Your summary is good.
What I'd say (I still didn't switch back to softdevice, so I'm not up-to-date wrt the latest release) : * use X / vdr-xine / XvMC when you have a regular PC (mouse, keyboard, etc.) : this is actually necessary to run Xine, VDR, X, etc. Xine needs 200MB memory and X approx. 40MB (a lot is shared, and works with 256MB RAM). Add that to the 40MB for VDR... * use softdevice / DirectFB / software decoding if you have a STB-like HTPC (no keyboard, no mouse, just the remote) : runvdr will handle running VDR *and* the display, restarting, etc. Software decoding is not a problem for your 1.2GHz processor (indeed, less a problem than running Xine separately)
Subscribe to the softdevice mailing-list (softdevice-devel@berlios.de). There are interesting developments and skilled developers there.
The subject of you post mentions "tv-out" : this is a great subject, and you should really consider the output quality in your planning. The TV-encoder on the EPIA board (VT162x) is driven by data tables, present in the frame-buffer kernel module for the CLE266, and also present in the X driver for the CLE266. These tables contains many parameters for the video output (PAL, NTSC, anti-flicker, etc.), and come from VIA. The parameters are actually far less than optimal (in the versions I have, dated a few months back) : the image has large black borders around (each 4 sides), is largely anti-flickered, thus blurred, etc. This lead to a huge loss in resolution. 720x576 should be full PAL display, but is actually far less with these tables. Ville Syrjälä from the DirectFB ML sent me the doc for the VT162x encoders, but I don't have time to dig into better parameters. I can send it if anyone want to improve that. The alternate TV-out method is to generate SCART RVB signal from the VGA output of the board, which should be good, if one can find the correct timing for the frame-buffer driver and/or X driver.
On Thu, 2005-03-10 at 11:21 +0100, Nicolas Huillard wrote:
{snippage}
Your summary is good.
Cool: it's quite difficult to get answers to things I was looking for!
What I'd say (I still didn't switch back to softdevice, so I'm not up-to-date wrt the latest release) :
- use X / vdr-xine / XvMC when you have a regular PC (mouse, keyboard,
etc.) : this is actually necessary to run Xine, VDR, X, etc. Xine needs 200MB memory and X approx. 40MB (a lot is shared, and works with 256MB RAM). Add that to the 40MB for VDR...
- use softdevice / DirectFB / software decoding if you have a STB-like
HTPC (no keyboard, no mouse, just the remote) : runvdr will handle running VDR *and* the display, restarting, etc. Software decoding is not a problem for your 1.2GHz processor (indeed, less a problem than running Xine separately)
This is probably the route I will aim for: my current box has a dxr3 for output but it does have X for doing a bit of coding in front of the tele'! I can live without that, though.
Subscribe to the softdevice mailing-list (softdevice-devel@berlios.de). There are interesting developments and skilled developers there.
Doing it now...
The subject of you post mentions "tv-out" : this is a great subject, and you should really consider the output quality in your planning. The TV-encoder on the EPIA board (VT162x) is driven by data tables, present in the frame-buffer kernel module for the CLE266, and also present in the X driver for the CLE266. These tables contains many parameters for the video output (PAL, NTSC, anti-flicker, etc.), and come from VIA. The parameters are actually far less than optimal (in the versions I have, dated a few months back) : the image has large black borders around (each 4 sides), is largely anti-flickered, thus blurred, etc. This lead to a huge loss in resolution. 720x576 should be full PAL display, but is actually far less with these tables. Ville Syrjälä from the DirectFB ML sent me the doc for the VT162x encoders, but I don't have time to dig into better parameters. I can send it if anyone want to improve that.
I saw some posts about that when I was looking for info!
The alternate TV-out method is to generate SCART RVB signal from the VGA output of the board, which should be good, if one can find the correct timing for the frame-buffer driver and/or X driver.
This is another option I was going to look into. Presumably Epias can't put out a composite sync signal so I would have to combine the horizontal and vertical syncs. Component RGB output from my stand-alone DVD player is noticeably better than S-video output from it. I have seen modelines for doing this with a PAL or NTSC signal but have never got around to trying it. I'm hoping that is these boards can drive a PAL or NTSC output directly, the same sync signals are available at the SVGA connector!
Cheers,
Laz
-
Laurence Abbott -
Nicolas Huillard