Hi all,
I'd like to report that I'm really impressed by the new setup I now have. The most problematic thing was proper transparent OSD which would not eat much CPU. I must tell that the xxmc (XVMC-VLD) decoding is nearly perfect, the OSD is fully transparent on this, and does not take any CPU at all, and the system is on par with softdevice.
My current setup : * diskless system : EPIA ML6000 / 600MHz, 512MB, diskless, 100Mbps Ethernet, 12V power supply, no fan, no noise : 25W off the wall while decoding video * NFS root FS on the always-on server : fully Debian etch with e-tobi repository, no self compiled package, except kernel-source package for LIRC * VDR 1.6.0-2 * xineliboutput 1.0.3 * streamdev-client 0.3.4 * skinsoppalusikka 1.6.2 * femon 1.6.3
BTW : CPU usage was 2% when decoding SDTV MPEG2 video only, with no Alsa sound setup, and climbed to 20% when Alsa was finally configured and working. That's a bit strange to think that audio is 9x more CPU-intensive than video ;-) (I think it may also be a big slice of synchronization delays)
Kudo to everyone involved in VDR, at all levels !
(problems/crashes reports will be for another day/post)
On 22 Nov 2008, at 21:04, Nicolas Huillard wrote:
I must tell that the xxmc (XVMC-VLD) decoding is nearly perfect, the OSD is fully transparent on this, and does not take any CPU at all, and the system is on par with softdevice.
What cpu usage did you get when running softdevice with the cle266 output option with this hardware setup?
Torgeir Veimo a écrit :
On 22 Nov 2008, at 21:04, Nicolas Huillard wrote:
I must tell that the xxmc (XVMC-VLD) decoding is nearly perfect, the OSD is fully transparent on this, and does not take any CPU at all, and the system is on par with softdevice.
What cpu usage did you get when running softdevice with the cle266 output option with this hardware setup?
I didn't use softdevice on this ML6000, but on an older M10K. I don't remember the exact details (this M10K is also using xineliboutput at the moment), but it was quite the same, ie. I didn't bother with CPU usage since it was largely within safe limits (<=20%).
M10K is currently at 15-18% CPU for VDR (plus a bit for kdvb-fe-*)
Software decoding with softdevice was OK (with transparent OSD on DirectFB), but is clearly out of question with xineliboutput (software OSD makes most of the frames drop).
- diskless system : EPIA ML6000 / 600MHz, 512MB, diskless, 100Mbps
Ethernet, 12V power supply, no fan, no noise : 25W off the wall while decoding video
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards? And how much does the server (NFS, DVB-card(s)) use power?
PCH power requirements:
I happened to have my Kill-A-Watt nearby and this is what I found: With the HD spinning: 180mA / 12Watts With the HD idle and the PH in standby: 100mA / 6Watts
And PCH supports upto 1080p (or 1920x1200 with 16/10 monitor) with no micro judders.. :) Just the UI is needed for full VDR-usage.
- Jori
jori.hamalainen@teliasonera.com a écrit :
- diskless system : EPIA ML6000 / 600MHz, 512MB, diskless, 100Mbps
Ethernet, 12V power supply, no fan, no noise : 25W off the wall while decoding video
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards? And how much does the server (NFS, DVB-card(s)) use power?
No use of PCI in the client.
The server is powered by an UPS, which tells me 115VA delivered to : * EPIA EK8000 (fanless) * 4x 250GB spinning disks * 1x 8 ports ethernet switch (powered off the PC 5V line) * the ADSL triple play box (FreeBox, powered off the PC 12V line) * audio amplifier in standby * no DVB devices yet
The server being there and useful, adding VDR services to it is just a net gain. Finally moving DVB devices to it will also allow me to power off other clients, which is also a net gain.
PCH power requirements:
I happened to have my Kill-A-Watt nearby and this is what I found: With the HD spinning: 180mA / 12Watts With the HD idle and the PH in standby: 100mA / 6Watts
And PCH supports upto 1080p (or 1920x1200 with 16/10 monitor) with no micro judders.. :) Just the UI is needed for full VDR-usage.
I guess you're talking about PopcornHour. This is another path : much more power efficient, much more integrated, but much less open and fun than DIY x86 PC hardware ;-)
On Monday, 24. Novemberta 2008 11:37:20 Nicolas Huillard wrote:
jori.hamalainen@teliasonera.com a écrit :
- diskless system : EPIA ML6000 / 600MHz, 512MB, diskless, 100Mbps
Ethernet, 12V power supply, no fan, no noise : 25W off the wall while decoding video
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards? And how much does the server (NFS, DVB-card(s)) use power?
No use of PCI in the client.
The server is powered by an UPS, which tells me 115VA delivered to :
- EPIA EK8000 (fanless)
- 4x 250GB spinning disks
- 1x 8 ports ethernet switch (powered off the PC 5V line)
- the ADSL triple play box (FreeBox, powered off the PC 12V line)
- audio amplifier in standby
- no DVB devices yet
The server being there and useful, adding VDR services to it is just a net gain. Finally moving DVB devices to it will also allow me to power off other clients, which is also a net gain.
PCH power requirements:
I happened to have my Kill-A-Watt nearby and this is what I found: With the HD spinning: 180mA / 12Watts With the HD idle and the PH in standby: 100mA / 6Watts
And PCH supports upto 1080p (or 1920x1200 with 16/10 monitor) with no micro judders.. :) Just the UI is needed for full VDR-usage.
I guess you're talking about PopcornHour. This is another path : much more power efficient, much more integrated, but much less open and fun than DIY x86 PC hardware ;-)
Hi! If we are talking about just plain vdr client with DVB cards somewhere in network (NFS).. How about "Samsung SyncMaster 460MXn 46" Full HD LCD with in builded PC" (LH46MGTLBC/EN) * AMD Athlon X2 3400+ 1.8GHz * 1GB DDR2 * 4MB Flash * ATI Radeon HD 3200 * GBit LAN * Realtek ALC262 sound * 3x USB2.0 * Windows what could be changed to Linux... ;-)
Price here at Finland .. ~2100€
JJussi a écrit :
On Monday, 24. Novemberta 2008 11:37:20 Nicolas Huillard wrote:
jori.hamalainen@teliasonera.com a écrit :
I happened to have my Kill-A-Watt nearby and this is what I found: With the HD spinning: 180mA / 12Watts With the HD idle and the PH in standby: 100mA / 6Watts
And PCH supports upto 1080p (or 1920x1200 with 16/10 monitor) with no micro judders.. :) Just the UI is needed for full VDR-usage.
I guess you're talking about PopcornHour. This is another path : much more power efficient, much more integrated, but much less open and fun than DIY x86 PC hardware ;-)
If we are talking about just plain vdr client with DVB cards somewhere in network (NFS).. How about "Samsung SyncMaster 460MXn 46" Full HD LCD with in builded PC" (LH46MGTLBC/EN)
- AMD Athlon X2 3400+ 1.8GHz
- 1GB DDR2
- 4MB Flash
- ATI Radeon HD 3200
- GBit LAN
- Realtek ALC262 sound
- 3x USB2.0
- Windows what could be changed to Linux... ;-)
Neat! Pros: * integrated IR receiver that can power up the PC * no audio, IR cables, etc. * Flash disk (is it really it?) for a quick local boot Cons: * no real hardware choice * potential driver/config problems (radeon, flash drive, TV-PC relationship) * have to change the TV set at the same time * power draw (330W vs. 240W for a similar PC-less 46" LCD)
On Monday, 24. Novemberta 2008 12:10:20 Nicolas Huillard wrote:
Neat! Pros:
- integrated IR receiver that can power up the PC
- no audio, IR cables, etc.
- Flash disk (is it really it?) for a quick local boot
Cons:
- no real hardware choice
- potential driver/config problems (radeon, flash drive, TV-PC
relationship) * have to change the TV set at the same time
- power draw (330W vs. 240W for a similar PC-less 46" LCD)
I was thinkin more situation where you are planning to buy "big full HD" TV.. You could "loose" some equipments from living room (wifes like that) when you combine big tv and computer..
On 24 Nov 2008, at 19:37, Nicolas Huillard wrote:
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards? And how much does the server (NFS, DVB- card(s)) use power?
No use of PCI in the client.
Do you put the DVB cards in the server?
Torgeir Veimo a écrit :
On 24 Nov 2008, at 19:37, Nicolas Huillard wrote:
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards? And how much does the server (NFS, DVB- card(s)) use power?
No use of PCI in the client.
Do you put the DVB cards in the server?
The temporary current setup is weird : * server only handles NFS root FS and NFS /video share * 1 client have a PCI DVB-S card, and an USB DVB-T card, with streamdev-server * another client have a PCI DVB-T card, with streamdev-server * the most recent client have no DVB device
Every DVB device will move to the server, requiring a bit of antennae rewiring.
On Mon, Nov 24, 2008 at 11:11 AM, jori.hamalainen@teliasonera.com wrote:
- diskless system : EPIA ML6000 / 600MHz, 512MB, diskless, 100Mbps
Ethernet, 12V power supply, no fan, no noise : 25W off the wall while decoding video
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards?
Ever heard about PCI risers? Like this one: http://linitx.com/viewproduct.php?prodid=10568 Works splendidly with Epia boards.
-Petri
Petri Helin a écrit :
On Mon, Nov 24, 2008 at 11:11 AM, jori.hamalainen@teliasonera.com wrote:
- diskless system : EPIA ML6000 / 600MHz, 512MB, diskless, 100Mbps
Ethernet, 12V power supply, no fan, no noise : 25W off the wall while decoding video
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards?
Ever heard about PCI risers? Like this one: http://linitx.com/viewproduct.php?prodid=10568 Works splendidly with Epia boards.
I have an active 3-slot one hanging around, but didn't yet find the proper solution to fit it in a standard tower case: cards will be 90° (vertical upside-down), not easy to attach reliably. Did anyone already built this ?
On 24 Nov 2008, at 20:05, Petri Helin wrote:
On Mon, Nov 24, 2008 at 11:11 AM, jori.hamalainen@teliasonera.com wrote:
- diskless system : EPIA ML6000 / 600MHz, 512MB, diskless, 100Mbps
Ethernet, 12V power supply, no fan, no noise : 25W off the wall while decoding video
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards?
Ever heard about PCI risers? Like this one: http://linitx.com/viewproduct.php?prodid=10568 Works splendidly with Epia boards.
If you want more pci slots, look for a digitainer motherboard, aka MSI MS-6723 on Ebay.de. They go cheaply, yet have a cle266 and vt1623 onboard which can output RGB through the scart output socket and has 3 PCI slots. That MB lacks a built in ethernet port though.
Hi,
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards?
Asrock A780FullDisplay without DisplayPort card AMD Athlon X4 3850e 2GB DDR2-800 DVD/RW 300W 80+ Green 1x Momentus 7200.3 250GB 2,5" 3x WD Caviar Green 1TB 3,5" Terratec Diversity (Dual Tuner) USB DVB-T 2x extra Fans
While recording two DVB-T channels ~ 60W (UPS tells it).
The WD drives build up a RAID5.
The A780 chipset is nice for low-power needs.
Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI slots for DVB-cards?
Asrock A780FullDisplay without DisplayPort card AMD Athlon X4 3850e 2GB DDR2-800 DVD/RW 300W 80+ Green 1x Momentus 7200.3 250GB 2,5" 3x WD Caviar Green 1TB 3,5" Terratec Diversity (Dual Tuner) USB DVB-T 2x extra Fans
While recording two DVB-T channels ~ 60W (UPS tells it). The WD drives build up a RAID5. The A780 chipset is nice for low-power needs.
Yes, I have AMD 780G also in my vdr server and in clients I am currently using the vdr-xineliboutput.
What I have now tried to search for is a fast booting client for my old P700, that could boot automatically to X with dummy user and then launch the vdr-xineliboutput.
The ideal would be that once bios checks have been done, rest of the boot would for getting X and vdr client running would take less than 30 seconds from the bios checking, but currently I am very far from that and I am not sure what would be the best option for the client.
1) local harddisk for booting and launching X and vdr-sxfe 2) nfs mount from server for booting and launching X and vdr-sxfe 3) local harddisk booting X and connecting to server with XDMCP. (would video and audio work over XDMCP from server?) 4) lpts5 where some apps would be run from server, while multimedia like vdr-sxfe would be run from client harddisk
What kind of solutions what boottimes you have for the clients?
Mika
Mika Laitio a écrit :
What I have now tried to search for is a fast booting client for my old P700, that could boot automatically to X with dummy user and then launch the vdr-xineliboutput.
The ideal would be that once bios checks have been done, rest of the boot would for getting X and vdr client running would take less than 30 seconds from the bios checking, but currently I am very far from that and I am not sure what would be the best option for the client.
- local harddisk for booting and launching X and vdr-sxfe
- nfs mount from server for booting and launching X and vdr-sxfe
- local harddisk booting X and connecting to server with XDMCP. (would video and audio work over XDMCP from server?)
- lpts5 where some apps would be run from server, while multimedia like vdr-sxfe would be run from client harddisk
What kind of solutions what boottimes you have for the clients?
From kernel first log line in the syslog server (I guess timestamps are when rcS.d/ scripts start to run, ie. does not include kernel load time + initrd), to LIRC accepting the VDR client (including a 5s sleep I had to add): * 31s on the ML6000 * 16s on a Athlon 2200+ * 18s on the M10k
That's with a single NFS root filesystem and network boot (no local storage). It does not include kernel + initrd load time over the network, BIOS time, etc. It also does not include specific imrpovement, except "not install unneeded things".
The best timing would be from power-on to live-TV on the display. BIOS + PXE (network boot) are ugly in this regard... Initrd is also time-consuming.
On Mon, Nov 24, 2008 at 3:24 PM, Nicolas Huillard nicolas@huillard.netwrote:
From kernel first log line in the syslog server (I guess timestamps are when rcS.d/ scripts start to run, ie. does not include kernel load time
- initrd), to LIRC accepting the VDR client (including a 5s sleep I had
to add):
- 31s on the ML6000
- 16s on a Athlon 2200+
- 18s on the M10k
Guys, How about putting the system in suspend mode instead of powering it off and on again? Should take few seconds. Some of you were talking about UPS, so its even safer than I can have... VDR can resume from suspend to record programs.
Alex Betis a écrit :
On Mon, Nov 24, 2008 at 3:24 PM, Nicolas Huillard nicolas@huillard.netwrote:
From kernel first log line in the syslog server (I guess timestamps are when rcS.d/ scripts start to run, ie. does not include kernel load time
- initrd), to LIRC accepting the VDR client (including a 5s sleep I had
to add):
- 31s on the ML6000
- 16s on a Athlon 2200+
- 18s on the M10k
Guys, How about putting the system in suspend mode instead of powering it off and on again? Should take few seconds. Some of you were talking about UPS, so its even safer than I can have... VDR can resume from suspend to record programs.
I'll try that ;-) Suspend to RAM as always been a pain in my various trials, but this is a much simpler goal than a complete laptop. Virtually no device to take down/bring up on a pure streamdev client. NFS handles must just survive the long delay, but it should be OK.
This also works around an annoying bug in the (non-upgraded) EPIA BIOS: the PXE LAN boot does not always initialize the network interface after a shutdown. One have to unplug power to boot correctly next time...
On Mon, 24 Nov 2008 21:41:54 +0100, Nicolas Huillard wrote
Alex Betis a écrit :
On Mon, Nov 24, 2008 at 3:24 PM, Nicolas Huillard > > Guys, How about putting the system in suspend mode instead of powering it off and on again? Should take few seconds.
Suspend to RAM as always been a pain in my various trials, but this is a much simpler goal than a complete laptop. Virtually no device to take down/bring up on a pure streamdev client. NFS handles must just survive the long delay, but it should be OK.
7 seconds until I get a picture on my EPIA 6000. And this is still pretty long, as I need to upload DXR3 firmware first, then start VDR.
This also works around an annoying bug in the (non-upgraded) EPIA BIOS: the PXE LAN boot does not always initialize the network interface after a shutdown. One have to unplug power to boot correctly next time...
Current via-rhine drivers have a module option to fix this: via-rhine.avoid_D3=1 For older kernes there's a patch: http://lkml.org/lkml/2004/9/17/242
Frank
Frank Schmirler a écrit :
On Mon, 24 Nov 2008 21:41:54 +0100, Nicolas Huillard wrote
This also works around an annoying bug in the (non-upgraded) EPIA BIOS: the PXE LAN boot does not always initialize the network interface after a shutdown. One have to unplug power to boot correctly next time...
Current via-rhine drivers have a module option to fix this: via-rhine.avoid_D3=1 For older kernes there's a patch: http://lkml.org/lkml/2004/9/17/242
I was sure it wouldn't hurt to ask on this ML...
Next question : where should I put this ?
https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=thread&top... says I should insert it in the initrd, but it's a bit difficult in my case (the same kernel/initrd is shared by many clients)...
I'd try to insert it on the PXE kernel command-line, but it's explicitely ignored by the kernel : ml6000 kernel: Unknown boot option `via_rhine.avoid_D3=1': ignoring ...or implicitely, when I just add "avoid_D3=1" (ie. PXE does not boot after the next shutdown)
On Tue, 25 Nov 2008 14:39:19 +0100, Nicolas Huillard wrote
Frank Schmirler a écrit :
Current via-rhine drivers have a module option to fix this:
via-rhine.avoid_D3=1
For older kernes there's a patch: http://lkml.org/lkml/2004/9/17/242
I was sure it wouldn't hurt to ask on this ML...
Next question : where should I put this ?
https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=thread&top...
says I should insert it in the initrd, but it's a bit difficult in my case (the same kernel/initrd is shared by many clients)...
Clients which do not have a via_rhine card will ignore the parameter. So it's safe to enable it for all clients.
I'd try to insert it on the PXE kernel command-line, but it's explicitely ignored by the kernel : ml6000 kernel: Unknown boot option `via_rhine.avoid_D3=1': ignoring ...or implicitely, when I just add "avoid_D3=1" (ie. PXE does not boot after the next shutdown)
You would use "via_rhine.avoid_D3=1" if the driver was builtin to the kernel.
When built as a module, it depends on how the modules are loaded.
In an initrd sometimes insmod is used. It accepts module options on the commandline (insmod via_rhine avoid_D3=1).
If modprobe is used, specify "options via-rhine avoid_D3=1" in /etc/modprobe.conf (or a file in /etc/modprobe.d/). You must do it in the /etc/ directory which is mounted by the time modprobe is executed (so probably inside of your initrd).
Regards, Frank
Frank Schmirler a écrit :
On Tue, 25 Nov 2008 14:39:19 +0100, Nicolas Huillard wrote
I'd try to insert it on the PXE kernel command-line, but it's explicitely ignored by the kernel : ml6000 kernel: Unknown boot option `via_rhine.avoid_D3=1': ignoring ...or implicitely, when I just add "avoid_D3=1" (ie. PXE does not boot after the next shutdown)
You would use "via_rhine.avoid_D3=1" if the driver was builtin to the kernel.
When built as a module, it depends on how the modules are loaded.
In an initrd sometimes insmod is used. It accepts module options on the commandline (insmod via_rhine avoid_D3=1).
If modprobe is used, specify "options via-rhine avoid_D3=1" in /etc/modprobe.conf (or a file in /etc/modprobe.d/). You must do it in the /etc/ directory which is mounted by the time modprobe is executed (so probably inside of your initrd).
Thanks for the answer.
The solution I used is the following, using Debian etch tools : * add a /etc/modprobe.d/via-rhine file in the running client filesystem * it contains the said "options via-rhine avoid_D3=1" line (along with my usual 60% comments) * then recreate the initrd on the client machine (the one which sees the new file) : update-initramfs -u -k 2.6.18-6-486 * don't forget to copy the initrd file in the tftp directory on the server, so the client can use it
I'll compile a fine-tuned kernel if I need to reduce boot time, but suspend-to-RAM could be much better.
On Tuesday 25 November 2008, Frank Schmirler wrote:
7 seconds until I get a picture on my EPIA 6000. And this is still pretty long, as I need to upload DXR3 firmware first, then start VDR.
Hmm, any particular reason why you need to do that? Recent em8300 driver versions should be able to load the microcode on demand, and vdr-dxr3 tries to load it at startup and in various other scenarios "manually" anyway.
On Tue, 25 Nov 2008 20:30:59 +0200, Ville Skyttä wrote
On Tuesday 25 November 2008, Frank Schmirler wrote:
7 seconds until I get a picture on my EPIA 6000. And this is still pretty long, as I need to upload DXR3 firmware first, then start VDR.
Hmm, any particular reason why you need to do that? Recent em8300 driver versions should be able to load the microcode on demand, and vdr-dxr3 tries to load it at startup and in various other scenarios "manually" anyway.
Yes, you're right. The manual upload was necessary when I started back in 2005. In the meantime the firmware is loaded automatically along with the dxr3 module. But anyway: it takes a few seconds until the dxr3 is ready. It's a pitty that the dxr3 doesn't survive suspending.
Frank
Suspend to RAM as always been a pain in my various trials, but this is a much simpler goal than a complete laptop. Virtually no device to take down/bring up on a pure streamdev client. NFS handles must just survive the long delay, but it should be OK.
7 seconds until I get a picture on my EPIA 6000. And this is still pretty long, as I need to upload DXR3 firmware first, then start VDR.
Nice...
Are you using just a normal distro like rhat or ubuntu for getting this fast resume and does the system survive from multiple suspend/resumes without need for the coldboot?
Hmm, maybe the nfs mounted system with suspend/resume is also a way to go for me... Now just needs to decide what distro to install for nfs bootable directory.
Mika
On Wed, 26 Nov 2008 00:00:27 +0200 (EET), Mika Laitio wrote
Suspend to RAM as always been a pain in my various trials, but this is a much simpler goal than a complete laptop. Virtually no device to take down/bring up on a pure streamdev client. NFS handles must just survive the long delay, but it should be OK.
7 seconds until I get a picture on my EPIA 6000. And this is still pretty long, as I need to upload DXR3 firmware first, then start VDR.
Nice...
Are you using just a normal distro like rhat or ubuntu for getting this fast resume and does the system survive from multiple suspend/resumes without need for the coldboot?
My production VDR client is a busybox system living on a 32 MB CF card, EPIA 6000. Kernel, busybox and VDR are selfmade, other binaries are from Debian (distro on my server). No need for reboots, no matter how often it is suspended/resumed.
My new HD extension client uses the same base, but this time PXE booting and on an EPIA 10000. Unfortunately I haven't been able to resurrect the HD extension after suspend/resume yet, but apart from that everything is fine. Multiple no problem with multiple suspend/resumes, no problem with PXE booting after setting the via_rhine module parameter.
I'm going to switch my DXR3 client to PXE booting, soon, but I'll keep the CF card. My server isn't running 24/7 - would be idle most of the time - so my clients needs to be able to wake it up with WOL. This is no problem when I resume a client. But after a power failure, the client obviously cannot PXE boot without the server. In this case the client is going to boot off the CF card, wake up the server and reboot - now PXE is available.
Frank
On Mon, 24 Nov 2008 11:58:22 +0100 Holger Rusch holger@rusch.name wrote:
The A780 chipset is nice for low-power needs.
That's not what I found. I tried to install an Asus MA738EMH last week and had to give up in the end and replace it with a similar board with NVidia 8200 graphics (that choice based on the VDPAU announcement), MN738VM.
Xorg's radeonhd driver (I used their latest release version, which is in debian experimental) didn't enable even basic Xv acceleration for the 3200 graphics, so the Athlon X2 4850e CPU I used could barely manage 720p. Fglrx was OK with MPlayer but Xv didn't work at all with xine and with OpenGL it caused unrecoverable screen garbling when switching from full-screen to windowed mode. The whole system would regularly crash when not doing anything too, and I think that even happened once or twice with the radeonhd driver.
The new board has worked flawlessly from day one and I expect VDPAU will be nice and stable and well supported by the time I really need it (for 1080p), whereas it's hard to imagine the ATI ever getting usable acceleration even for H.264.
-
Alex Betis -
Frank Schmirler -
Holger Rusch -
JJussi -
jori.hamalainen＠teliasonera.com -
Mika Laitio -
Nicolas Huillard -
Petri Helin -
Tony Houghton -
Torgeir Veimo -
Ville Skyttä