If someone is able to produce a Linux driver for the hardware decoder on this board, the latest VIA Epia EX looks like the vdr setup for the future.
http://techreport.com/onearticle.x/11511
Hardware accelerated MPEG2, MPEG4 and WMV9, 720p and 1080i output via DVI, S-Video composite and component and 13.5W of power.
Regards,
Richard
On 30 Dec 2006, at 08:36, Richard Scobie wrote:
If someone is able to produce a Linux driver for the hardware decoder on this board, the latest VIA Epia EX looks like the vdr setup for the future.
http://techreport.com/onearticle.x/11511
Hardware accelerated MPEG2, MPEG4 and WMV9, 720p and 1080i output via DVI, S-Video composite and component and 13.5W of power.
For 1080i output it's important that the chipset can properly deinterlace if outputting 1080p or 720p. Via's earlier solutions (CL266, CN400, maybe also the CN700) has been resolution limited to 1024x1024 (when doing XvMC decoding) as well, which made them unsuitable for use with HDTV material. ATIs and NVIDIAs latest chipset can do adaptive deinterlacing (simple BOB or WEAVE doesn't suffice), and has a much higher resolution available for HDTV decoding and scaling when doing XvMC decoding.
In CFDC7DC2-B458-461F-A98A-9F42B66CAC41@pobox.com, Torgeir Veimo wrote:
ATIs and NVIDIAs latest chipset can do adaptive deinterlacing (simple BOB or WEAVE doesn't suffice), and has a much higher resolution available for HDTV decoding and scaling when doing XvMC decoding.
How good is Linux support for these? I was under the impression that XvMC doesn't work with ATI at all, and is broken in many versions of NVidia's Linux drivers. And that the latter don't support deinterlacing even though the hardware has been capable for quite a while now (since 6600 I heard).
Tony Houghton wrote:
How good is Linux support for these? I was under the impression that XvMC doesn't work with ATI at all, and is broken in many versions of NVidia's Linux drivers. And that the latter don't support deinterlacing even though the hardware has been capable for quite a while now (since 6600 I heard).
A list of NVidia hardware capabilities is here:
http://www.nvidia.com/page/purevideo_support.html
As for current XvMC support, only IDCT and Motion Compensation with MPEG2 (and possibly MPEG1) are available in hardware - no hw deinterlacing.
Full support may happen eventually, judging by a comment here from NVidia staff:
http://macslow.thepimp.net/ (see bottom of "UDS 2006 recap, Google, nVIDIA etc." article.)
"Furthermore I hinted them towards us OpenSource folks wanting to see nVIDIA’s PureVideo HD chip-features exposed in the Linux-drivers too. They have plans for that, but not in the immediate future."
Regards,
Richard
Too bad it only has 1 expansion slot. That means only 1 tunner board. I wouldn't even concider anything with less then 2-3 slots.
----- Original Message ----- From: "Richard Scobie" r.scobie@clear.net.nz To: "Klaus Schmidinger's VDR" vdr@linuxtv.org Sent: Saturday, December 30, 2006 1:36 AM Subject: [vdr] New VDR hardware
If someone is able to produce a Linux driver for the hardware decoder on this board, the latest VIA Epia EX looks like the vdr setup for the
future.
http://techreport.com/onearticle.x/11511
Hardware accelerated MPEG2, MPEG4 and WMV9, 720p and 1080i output via DVI, S-Video composite and component and 13.5W of power.
Regards,
Richard
On Saturday 30 December 2006 19:53, Richard Scobie wrote:
Timothy D. Lenz wrote:
Too bad it only has 1 expansion slot. That means only 1 tunner board. I wouldn't even concider anything with less then 2-3 slots.
It does have 4 x USB 2.0 which seems to be becoming popular for tuners now.
Nice idea but...
I've never managed to get two USB2 Nova-T devices working together for extended periods of time hanging off an Epia board. After a few hours, both of the USB boxes will randomly disconnect themselves leaving a very unhappy vdr because the DVB devices have disappeared form under its nose!! i did try various driver debugging options but never came to any conclusion about why they did this. Most of the time a reboot will restore them; other times, they need unplugging and a reboot so that they get the firmware reloaded.
Maybe this is down to a buggy USB chip on the motherboard or maybe I'm just unlucky and for some reason my two USB devices won't play happily together (on their own, they can work seamlessly for weeks!), or maybe it's down to a firmware bug or something. I also have a Nova-T 500 which is a PCI card containing two USB DVB devices with an on-board USB controller: that works perfectly (in conjunction with one of the USB Nova-T devices!).
Other USB devices might work well together, though...
Just my experiences!
My spare USB device is currently hanging off a Linksys NSLU2, a.k.a. Slug, but that's a story for another day!
;)
Cheers,
Laz
Laz kirjoitti:
Maybe this is down to a buggy USB chip on the motherboard or maybe I'm just unlucky and for some reason my two USB devices won't play happily together (on their own, they can work seamlessly for weeks!), or maybe it's down to a firmware bug or something. I also have a Nova-T 500 which is a PCI card containing two USB DVB devices with an on-board USB controller: that works perfectly (in conjunction with one of the USB Nova-T devices!).
Now that this came up. I was wondering in my earlier post today about twin tuner cards and if I understood correctly Nova-T 500 is such a card. And if I again understood correctly it works with linux and VDR?
\Kartsa
On 3 Jan 2007, at 20:45, Kartsa wrote:
Now that this came up. I was wondering in my earlier post today about twin tuner cards and if I understood correctly Nova-T 500 is such a card. And if I again understood correctly it works with linux and VDR?
Some people including me are experiencing usb disconnection with the nova-t 500 (it has an internal usb bus), which in some cases can make your machine freeze, and in the best case causes you to loose a few seconds of playback / recording. See the linux-dvb mailing list for more details.
On Wednesday 03 January 2007 21:44, Torgeir Veimo wrote:
On 3 Jan 2007, at 20:45, Kartsa wrote:
Now that this came up. I was wondering in my earlier post today about twin tuner cards and if I understood correctly Nova-T 500 is such a card. And if I again understood correctly it works with linux and VDR?
Some people including me are experiencing usb disconnection with the nova-t 500 (it has an internal usb bus), which in some cases can make your machine freeze, and in the best case causes you to loose a few seconds of playback / recording. See the linux-dvb mailing list for more details.
Hmmm...I've got one of these and I've never seen it disconnect yet (a few months so far...fingers crossed!).
When I've seen USB disconnections with two USB2 Nova-T devices, I was getting things like /dev/dvb/adapter0, /dev/dvb/adapter2, /dev/dvb/adapter3, i.e. adapter1 missing from where one of them had been originally before disconnecting and then being reassigned as adapter3! in this situation, vdr only sees the first DVB device because it starts at adapter0 and stops counting when the next number doesn't exist.
Cheers,
Laz
On 4 Jan 2007, at 09:20, Laz wrote:
On Wednesday 03 January 2007 21:44, Torgeir Veimo wrote:
On 3 Jan 2007, at 20:45, Kartsa wrote:
Now that this came up. I was wondering in my earlier post today about twin tuner cards and if I understood correctly Nova-T 500 is such a card. And if I again understood correctly it works with linux and VDR?
Some people including me are experiencing usb disconnection with the nova-t 500 (it has an internal usb bus), which in some cases can make your machine freeze, and in the best case causes you to loose a few seconds of playback / recording. See the linux-dvb mailing list for more details.
Hmmm...I've got one of these and I've never seen it disconnect yet (a few months so far...fingers crossed!).
It looks like this (am not sure why it actually causes my machine to crash, it might be something related to irq sharing):
Jan 2 19:33:45 fink kernel: MT2060: PLL freq=562000kHz f_lo1=1782000kHz f_lo2=1183850kHz Jan 2 19:33:45 fink kernel: MT2060: PLL div1=111 num1=24 div2=73 num2=8115 Jan 2 19:33:45 fink kernel: MT2060: PLL [1..5]: 56 6f 3 fb 93 Jan 2 19:33:48 fink kernel: usb 8-1: USB disconnect, address 2 Jan 2 19:33:48 fink kernel: ehci_hcd 0000:03:01.2: qh f7c40100 (#82) state 4(has tds) Jan 2 19:33:48 fink kernel: mt2060 I2C write failed Jan 2 19:33:48 fink kernel: mt2060 I2C write failed Jan 2 19:33:48 fink kernel: dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully deinitialized and disconnected. Jan 2 19:33:48 fink kernel: BUG: unable to handle kernel paging request at virtual address 2e313212 Jan 2 19:33:48 fink kernel: printing eip: Jan 2 19:33:48 fink kernel: f8a23177 Jan 2 19:33:48 fink kernel: *pde = 00000000 Jan 2 19:33:48 fink kernel: Oops: 0000 [#1] Jan 2 19:33:48 fink kernel: SMP Jan 2 19:33:48 fink kernel: last sysfs file: /class/drm/card0/dev Jan 2 19:33:48 fink kernel: Modules linked in: i915 drm autofs4 hidp rfcomm l2cap bluetooth sunrpc ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables fuse video sbs i2c_ec button battery ac ipv6 parport_pc lp parport bt878(U) tuner(U) tvaudio(U) snd_hda_intel snd_hda_codec snd_seq_dummy snd_seq_oss sg snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm bttv(U) mt2060(U) snd_timer 3c59x ide_cd snd video_buf(U) cdrom soundcore ir_common(U) compat_ioctl32(U) i2c_i801 i2c_algo_bit btcx_risc(U) dvb_usb_dib0700 (U) tveeprom(U) snd_page_alloc ohci1394 mii sky2 dib7000m(U) dib7000p (U) dvb_usb(U) dvb_core(U) dvb_pll(U) dib3000mc(U) dibx000_common(U) videodev(U) pcspkr ieee1394 v4l2_common(U) v4l1_compat(U) serio_raw i2c_core dm_snapshot dm_zero dm_mirror dm_mod sata_sil24 ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Jan 2 19:33:48 fink kernel: CPU: 0 Jan 2 19:33:48 fink kernel: EIP: 0060:[<f8a23177>] Not tainted VLI Jan 2 19:33:48 fink kernel: EFLAGS: 00210246 (2.6.18-1.2869.fc6 #1) Jan 2 19:33:48 fink kernel: EIP is at dvb_frontend_poll+0x1a/0x66 [dvb_core] Jan 2 19:33:48 fink kernel: eax: 2e31303a ebx: 00000001 ecx: f8a2315d edx: eea25c58 Jan 2 19:33:48 fink kernel: esi: eea25c58 edi: ee4e3a80 ebp: eea25e98 esp: eea25c1c Jan 2 19:33:48 fink kernel: ds: 007b es: 007b ss: 0068 Jan 2 19:33:48 fink kernel: Process vdr (pid: 3553, ti=eea25000 task=eea3fa30 task.ti=eea25000) Jan 2 19:33:48 fink kernel: Stack: 00000008 c04e49f2 00000001 eea25ea0 ee4e3a80 c047baa3 eea25fb0 b5f65270 Jan 2 19:33:48 fink kernel: b5f65278 00000000 eea25e98 eea25e98 eea25e98 eea25ea8 eea25c58 c047c5cb Jan 2 19:33:48 fink kernel: 00000000 00000000 00000000 00000002 eea25dc8 f5760558 eea25dd4 00020100 Jan 2 19:33:48 fink kernel: Call Trace: Jan 2 20:25:26 fink syslogd 1.4.1: restart.
On Thursday 04 January 2007 09:30, Torgeir Veimo wrote:
On 4 Jan 2007, at 09:20, Laz wrote:
Hmmm...I've got one of these and I've never seen it disconnect yet (a few months so far...fingers crossed!).
It looks like this (am not sure why it actually causes my machine to crash, it might be something related to irq sharing):
Jan 2 19:33:45 fink kernel: MT2060: PLL freq=562000kHz f_lo1=1782000kHz f_lo2=1183850kHz Jan 2 19:33:45 fink kernel: MT2060: PLL div1=111 num1=24 div2=73 num2=8115 Jan 2 19:33:45 fink kernel: MT2060: PLL [1..5]: 56 6f 3 fb 93 Jan 2 19:33:48 fink kernel: usb 8-1: USB disconnect, address 2 Jan 2 19:33:48 fink kernel: ehci_hcd 0000:03:01.2: qh f7c40100 (#82) state 4(has tds) Jan 2 19:33:48 fink kernel: mt2060 I2C write failed Jan 2 19:33:48 fink kernel: mt2060 I2C write failed Jan 2 19:33:48 fink kernel: dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully deinitialized and disconnected. Jan 2 19:33:48 fink kernel: BUG: unable to handle kernel paging request at virtual address 2e313212 Jan 2 19:33:48 fink kernel: printing eip: Jan 2 19:33:48 fink kernel: f8a23177 Jan 2 19:33:48 fink kernel: *pde = 00000000 Jan 2 19:33:48 fink kernel: Oops: 0000 [#1]
{snip}
I don't think I ever saw a kernel oops when my USB2 devices disconnected themselves, just a non-descriptive USB disconnect message. I think unplugging the cable from a working device does, though, so maybe my external USB devices weren't disconnecting fully, somehow. This only ever really happens when I hang two of the external USB2 Nova-T devices from the same system.
Cheers,
Laz
On Thursday 04 January 2007 10:20, Laz wrote:
Hmmm...I've got one of these and I've never seen it disconnect yet (a few months so far...fingers crossed!).
When I've seen USB disconnections with two USB2 Nova-T devices, I was getting things like /dev/dvb/adapter0, /dev/dvb/adapter2, /dev/dvb/adapter3, i.e. adapter1 missing from where one of them had been originally before disconnecting and then being reassigned as adapter3! in this situation, vdr only sees the first DVB device because it starts at adapter0 and stops counting when the next number doesn't exist.
This is something I would like to change. Just let vdr iterate over (number only an example) the first 8 dvb-adapters and try them.
For now you can also have your runvdr give vdr the parameters -D 0 -D 2 -D 3 (script loop) to use all adapters.
Or better: Ask hal (if available) to enumerate them. That could even enable us to get vdr hotplug-able. My long term goal is to get the dvb-driver no longer crash on disconnect, but just signalize The error ENODEV. And that vdr cope with device plug/unplug.
Matthias
In 200701041125.02643.zzam@gentoo.org, Matthias Schwarzott wrote:
On Thursday 04 January 2007 10:20, Laz wrote:
Hmmm...I've got one of these and I've never seen it disconnect yet (a few months so far...fingers crossed!).
When I've seen USB disconnections with two USB2 Nova-T devices, I was getting things like /dev/dvb/adapter0, /dev/dvb/adapter2, /dev/dvb/adapter3, i.e. adapter1 missing from where one of them had been originally before disconnecting and then being reassigned as adapter3! in this situation, vdr only sees the first DVB device because it starts at adapter0 and stops counting when the next number doesn't exist.
This is something I would like to change. Just let vdr iterate over (number only an example) the first 8 dvb-adapters and try them.
For now you can also have your runvdr give vdr the parameters -D 0 -D 2 -D 3 (script loop) to use all adapters.
Or better: Ask hal (if available) to enumerate them. That could even enable us to get vdr hotplug-able. My long term goal is to get the dvb-driver no longer crash on disconnect, but just signalize The error ENODEV. And that vdr cope with device plug/unplug.
Unfortunately HAL doesn't seem to support DVB devices. Nor is there a generic way to find a device's /dev node AFAICT; it can only provide that information for devices with a class it knows about. If there's a way to get HAL uids based on /dev node and vice-versa, eg through udev, HAL might work though.
-
Kartsa -
Laz -
Matthias Schwarzott -
Richard Scobie -
Timothy D. Lenz -
Tony Houghton -
Torgeir Veimo