Re: [vdr] Options for deinterlacing (or not)
Thomas Hilber v...@toh.cx wrote: Maybe some day FrameRateControl will allow for a pure open source HDTV solution. Running with adequate picture quality on moderately powered CPUs. I think it is very important for HDTV without any other solution. One of my main reasons for buying a eHD was that whilst xine / coreavc was great for watching films (progressive source) etc, it was not good for watching sport (interlaced source) and even with a Core2 Duo 3Ghz enabling good interlacing (tvtime) resulted in the processor becoming bound and huge amount of frame drops. Taking this problem out of the equation would be a big help. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On 21 Jan 2009, at 15:02, Thomas Hilber wrote: patch version II: http://www.vdr-portal.de/board/thread.php?postid=769703#post769703 I tried patching the i810 driver that comes with fedora 9, which i use, but I'm getting patching file ./src/i830_driver.c Hunk #1 FAILED at 319. Hunk #2 FAILED at 352. Hunk #3 succeeded at 1663 (offset -56 lines). 2 out of 4 hunks FAILED -- saving rejects to file ./src/ i830_driver.c.rej patching file ./src/i830_video.c Which driver source is suitable for patch II? -- Torgeir Veimo torg...@pobox.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On 22 Jan 2009, at 21:12, Torgeir Veimo wrote: On 21 Jan 2009, at 15:02, Thomas Hilber wrote: patch version II: http://www.vdr-portal.de/board/thread.php?postid=769703#post769703 I tried patching the i810 driver that comes with fedora 9, which i use, but I'm getting patching file ./src/i830_driver.c Hunk #1 FAILED at 319. Hunk #2 FAILED at 352. Hunk #3 succeeded at 1663 (offset -56 lines). 2 out of 4 hunks FAILED -- saving rejects to file ./src/ i830_driver.c.rej patching file ./src/i830_video.c Which driver source is suitable for patch II? It looks like the patch references a version of the driver that supports OPTION_RENDERACCEL, but v 2.3.2 doesn't support that. Which version of the driver is the patch for? -- Torgeir Veimo torg...@pobox.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Thu, Jan 22, 2009 at 10:07:57PM +1000, Torgeir Veimo wrote: It looks like the patch references a version of the driver that supports OPTION_RENDERACCEL, but v 2.3.2 doesn't support that. Which version of the driver is the patch for? as described in http://www.vdr-portal.de/board/thread.php?postid=769703#post769703 the patch originally is against debian 'xserver-xorg-video-intel_2.3.2-2+lenny5_i386.deb'. There occur only some trivial rejects with your version of xserver-xorg-video-intel. The patch does not interfere much with the original code. I hope you can resolve them manually. On Thu, Jan 22, 2009 at 09:12:12PM +1000, Torgeir Veimo wrote: I tried patching the i810 driver that comes with fedora 9, which i use, but I'm getting But please keep in mind it only works for i9xx chipsets (not the i810/i815) - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
Thomas Hilber a écrit : On Wed, Jan 21, 2009 at 04:23:59PM +1000, Torgeir Veimo wrote: There's no english howto anywhere? sorry, not yet. Is the below rough summary correct ? What it currently is : * a patch set to DRM kernel modules, xine-lib and xineliboutput * that adds proper interlaced output from ATI and Intel GPUs * it also adds FrameRateControl under some conditions * it's stable and works on VGA, but seems to also work on HDMI * only works with Xv (does/can not make use of XvMC) * can work with any display device (CRT, LCD, plasma) * make most use of the display device capability (interlaced display on a SD CRT, picture enhancers on HD LCD/Plasma) Ideal goal would probably imply : * output mode change upon source mode change (output 720x576i on the VGA when playing SDTV, output 1920x1080i/p when playing HDTV contents, etc.) * make use of hardware decoding capabilities when available (specially for HDTV) Side-needs : * add support for nVidia, VIA chips, etc. (feasability ?) * integrate these patches upstream (feasability, propagation delays?) -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, Jan 21, 2009 at 06:02:23AM +0100, Thomas Hilber wrote: It seems German related sites show more interest in VGA2SCART things. So I did not spend further time to translate all things I developed for VGA2SCART into english. Sorry for that;-) I think there's demand for this functionality all over the world :) not just in germany. I think someone should step ahead and help with the english docs.. unfortunately I can't do that atm, too busy with other things.. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, 21 Jan 2009 17:07:40 +0200 Pasi Kärkkäinen pa...@iki.fi wrote: On Wed, Jan 21, 2009 at 06:02:23AM +0100, Thomas Hilber wrote: It seems German related sites show more interest in VGA2SCART things. So I did not spend further time to translate all things I developed for VGA2SCART into english. Sorry for that;-) I think there's demand for this functionality all over the world :) not just in germany. I think someone should step ahead and help with the english docs.. unfortunately I can't do that atm, too busy with other things.. It is excellent, but I can't help thinking it's come a bit too late. CRTs and SCART are being replaced by LCD and HDMI, and given an interlaced picture, an LCD has to deinterlace it rather than take advantage of phosphor decay. In theory a decoder such as VDPAU can deinterlace better than the TV because it has access to extra info such as motion vectors in the MPEG. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, Jan 21, 2009 at 12:55:19PM +0100, Nicolas Huillard wrote: Is the below rough summary correct ? What it currently is : * a patch set to DRM kernel modules, xine-lib and xineliboutput ...not to forget the Xserver-DDX (hardware specific module) itself. For pre-avivo Radeons you need to patch in all four areas. For Intel i9xx chips patches in DRM kernel modules are obsolete since certain functionality is already implemented in graphics hardware. * that adds proper interlaced output from ATI and Intel GPUs right * it also adds FrameRateControl under some conditions yes. For pre-avivo Radeons and i9xx Intels FrameRateControl is possible * it's stable and works on VGA, but seems to also work on HDMI for some people at vdr-portal and me it already works stable:-) Compared to a FF card WSS is not yet implemented for Radeons. You currently must use one of the available SCART Pin 8 solutions there. Intel graphics allow hardware scaling in Y dimension even in interlaced mode (if needed). So WSS is obsolete there. Still lacking an HDMI capable device I mainly focused on VGA/SCART output method. But also some working configurations already exist with FrameRateControl over HDMI. Please see link to 'durchfliegers' thread above. * only works with Xv (does/can not make use of XvMC) currently it only works with Xv since this is the lowest common denominator for video things under X available as open source. I don't think MPEG2 decoding is worth all the effort to implement that in firmware. Even on very slow processors MPEG2 decoding alone (with NO deinterlacing) is running sufficiently fast. * can work with any display device (CRT, LCD, plasma) should work with most VGA or SCART capable display devices. I tested with several CRT-SCART-TVs and LCD-SCART-TVs and experienced no problems yet. Some other people also could successfully rebuild the system. * make most use of the display device capability (interlaced display on a SD CRT, picture enhancers on HD LCD/Plasma) that's the main intention behind the idea. At least it should relieve the software of deinterlacing because todays PC architectures still can't do that efficiently by means of the main CPU. Ideal goal would probably imply : * output mode change upon source mode change (output 720x576i on the VGA when playing SDTV, output 1920x1080i/p when playing HDTV contents, etc.) this interesting theme has already been addressed by 'durchflieger' from vdr-portal. I even think Petri has adopted some parts of durchflieger's patch for xineliboutput. But I don't know exactly. Thread: http://www.vdr-portal.de/board/thread.php?threadid=80573 * make use of hardware decoding capabilities when available (specially for HDTV) for HDTV use of hardware decoding capabilities are a future goal. For SDTV as already mentioned I don't think it's worth the additional effort. I never understood all these discussing about MPEG2 decoding in hardware/firmware. Even low end machines as SMT7020 decode with CPU with no problems. Side-needs : * add support for nVidia, VIA chips, etc. (feasability ?) most nVidia chips are VGA2SCART capable out-of-the-box even with recent open source Xserver-DDX. I threw a quick glance at this a few weeks ago. As specifications are not available for nVidia chips there is no way to implement FrameRateControl there. So VGA2SCART provides no special benefits for nVidia chips except that you drive an real 50Hz-capable (PAL) device. I never dealt with VIA chips so far. * integrate these patches upstream (feasability, propagation delays?) although ATI and Intel Xorg developers always kindly answered my questions they seem not to be very interested in abusing a VGA port for SCART. Even simple interlaced modelines are often not supported yet without additional patches. Current upstream development mainly focuses on conventional TV-out ports. Probably because todays graphics hardware is not directly designed with VGA2SCART in mind. Not to mention VGA2SCART+FrameRateControl which can only be achieved by playing some tricks. I think special VDR distributions like easy-vdr currently are the only means to make the patches available to everyone in a convenient way. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, Jan 21, 2009 at 05:07:40PM +0200, Pasi Kärkkäinen wrote: I think someone should step ahead and help with the english docs.. unfortunately I can't do that atm, too busy with other things.. after travelling over 5 weeks in Australia this now is my major problem too:-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, Jan 21, 2009 at 04:03:37PM +, Tony Houghton wrote: It is excellent, but I can't help thinking it's come a bit too late. not if it comes to HDTV. Basically it should be feasible to recycle some of the ideas there. BTW I wanted to prove that simple graphics hardware together with low end processors are capable to provide the same picture quality as do those cumbersome FF cards. But at much lower cost besides many other advantages. Unfortunately nobody cared about developing alternatives to FF cards the past years. advantage of phosphor decay. In theory a decoder such as VDPAU can deinterlace better than the TV because it has access to extra info such as motion vectors in the MPEG. you certainly are right with this but VDPAU is no open source. Maybe some day FrameRateControl will allow for a pure open source HDTV solution. Running with adequate picture quality on moderately powered CPUs. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, 21 Jan 2009 18:35:00 +0100 Thomas Hilber v...@toh.cx wrote: Maybe some day FrameRateControl will allow for a pure open source HDTV solution. Running with adequate picture quality on moderately powered CPUs. Yes, hopefully one day Intel will have a fully operational VA or something, including MPEG 4, and include HDMI or DVI on the motherboard instead of having an adaptor taking up a valuable PCI-e slot. I wouldn't consider FrameRateControl absolutely vital, playback of live TV is smooth enough without it IME, but ironically libxine seems better at playing live TV than VDR recordings which always seem to me to suffer more frame jumps, loss of AV sync and pops in the sound than live TV. When playing back recordings it doesn't matter if the video output frame rate isn't quite right, you can avoid dropping or repeating frames by resampling the audio if sync starts to drift - this appears to be an option in xine's config, but it doesn't seem to work correctly on recordings for me. I already sometimes use resampling in mplayer to watch 24fps videos smoothly at 25fps and the sound quality is still subjectively OK - certainly less intrusive in the overall experience than jumping video frames. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
Hi Scott! 2009/1/19 Scott Waye sc...@waye.co.uk: If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do any de interlacing in xine, why is this not the same as what my digibox does? I'm guessing it has something to do with xine outputting a complete frame when the broadcast sends each field? What you state above is NOT correct. When you use your digiboxx, your TV panel does all interlacing and scaling. To do what your digibox does, you should alwways set the output in the same (interlaced) resolution as the broadast, NOT in the TV's native resolution. And no vertical scaling is allowed before deinterlacing! (but horizontal is allowed) Someone correct me if I'm wrong What I'd hope happen (for interlaced material) is that xine receives a field from VDR, scales it to the X resolution (halfed vertically of course) and sends it to the the graphics card which just passes it on to the TV which draws that field. That doesn't seem to happen so where have I gone wrong? In changing the resolution. To achieve what you want, you need to set X to a PAL modeline (720 x 576 interlaced for PAL). However, this is not as straightforward for a VGA card as for full featured DVB cards or set tob boxes. Even after setting the right modeline, a few problems remain: 1) You need to enable sync on vblanck. 2) There is no way to automatically switch the resolution when/if the standard changes 3) The timigns are not exact on VGA (HDMI etc.) outputs The first is not possible on all drivers (i.e. fglrx). For the second problem there are no ready made solutions (but you can of course manually change between modes, and perhaps restart some sowftware when needed). For the third problem, see thread RGB/PAL over VGA at variable frame rate for more discussion and patches. Someone correct me if I'm wrong. -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Mon, Jan 19, 2009 at 09:54:18PM +, Scott Waye wrote: I want to replace my UK Sky digital box with VDR (I only want the free to air channels) for watching/recording TV over HDMI on my plasma. So far everything is working OK, I have vdr 1.7.3 and xine running on an ASUS M2N VM-HDMI (nvidia) mobo with the s2-liplianin drivers for my Nova SD2 card. My problem is interlacing. I've googled back through the archives and got a lot of info from there, however I still have one question and one request. If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do any de interlacing in xine, why is this not the same as what my digibox does? I'm guessing it has something to do with xine outputting a complete frame when the broadcast sends each field? What I'd hope happen (for interlaced material) is that xine receives a field from VDR, scales it to the X resolution (halfed vertically of course) and sends it to the the graphics card which just passes it on to the TV which draws that field. That doesn't seem to happen so where have I gone wrong? There's a lot of options for tvtime in xine, TomsMoComp and full framerate seem popular. What settings are others using? Hello. Please check this thread: http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html Original patches: http://lowbyte.de/vga-sync-fields/ New version: http://www.vdr-portal.de/board/thread.php?threadid=80567 Those might help.. they're about getting pure 1:1 interlaced (576i) RGB output from a VGA card.. and the new version also has some HDTV stuff, I guess. I don't read german so i'm not familiar with that.. There are also patches to maintain perfect field sync to DVB stream to avoid tearing/stutter/jerkiness. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Tue, 20 Jan 2009 18:19:49 +0200 Ville Aakko ville.aa...@gmail.com wrote: 1) You need to enable sync on vblanck. [Snip] The first is not possible on all drivers (i.e. fglrx). Absolutely not possible? I know OpenGL, DRI and NVidia drivers all have APIs for waiting for vblank and ISTR seeing a xine option for vblank sync with Xv. Do none of these work with fglrx? Nvidia's settings tool has options to disable vblank sync for OpenGL and video, but I don't know whether by setting it off it disables syncing altogether or by setting it on it forces flip operations to automatically wait for vblank. Another problem is that in interlaced modes on standard graphics cards you get a vblank interrupt for each field with no way of distinguishing between top or bottom fields; getting them the wrong way round is really messy! Certain Matrox cards let applications distinguish between top and bottom fields, but it's only (officially) supported on the TV-out (SDTV) on the second head using DirectFB. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Tue, 20 Jan 2009 18:23:21 +0200 Pasi Kärkkäinen pa...@iki.fi wrote: Please check this thread: http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html Original patches: http://lowbyte.de/vga-sync-fields/ New version: http://www.vdr-portal.de/board/thread.php?threadid=80567 Those might help.. they're about getting pure 1:1 interlaced (576i) RGB output from a VGA card.. and the new version also has some HDTV stuff, I guess. I don't read german so i'm not familiar with that.. There are also patches to maintain perfect field sync to DVB stream to avoid tearing/stutter/jerkiness. Varying the output frame rate to keep in sync with the input stream is very clever, but I don't understand how it solves the problem of distinguishing between top and bottom fields to sync to. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
2009/1/20 Tony Houghton h...@realh.co.uk: On Tue, 20 Jan 2009 18:19:49 +0200 Ville Aakko ville.aa...@gmail.com wrote: 1) You need to enable sync on vblanck. [Snip] The first is not possible on all drivers (i.e. fglrx). Absolutely not possible? I know OpenGL, DRI and NVidia drivers all have APIs for waiting for vblank and ISTR seeing a xine option for vblank sync with Xv. Do none of these work with fglrx? Nvidia's settings tool has options to disable vblank sync for OpenGL and video, but I don't know whether by setting it off it disables syncing altogether or by setting it on it forces flip operations to automatically wait for vblank. AFAIK this is a known issue with fglrx drivers. The API is there, but with fglrx the detection is (currently) broken, at least on 8.11 (which is what I'm using currently). I think I saw someone in some forum getting vsync working with fglrx but only for 'mplayer -vo gl'. But that was an exception- -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Tue, Jan 20, 2009 at 05:21:53PM +, Tony Houghton wrote: Varying the output frame rate to keep in sync with the input stream is very clever, but I don't understand how it solves the problem of distinguishing between top and bottom fields to sync to. surely you can distinguish top and bottom fields on older (pre-avivo) Radeon cards. My vga-sync-fields patch exactly uses this feature: ---8--- #define RADEON_CRTC_STATUS 0x005c #define RADEON_CRTC_CURRENT_FIELD(1 3) field = INREG(RADEON_CRTC_STATUS) RADEON_CRTC_CURRENT_FIELD; ---8--- BTW: I meanwhile could port the Radeon VGA2SCART thing to Intel i9xx chipsets too. Description of my Intel patch can be found here (sorry only in German): patch version I: http://www.vdr-portal.de/board/thread.php?postid=766459#post766459 patch version II: http://www.vdr-portal.de/board/thread.php?postid=769703#post769703 For Intel chipsets you even don't have to tamper with kernel modules like radeon-drm since they already have builtin some key features needed for VGA2SCART frame rate control. This way you now can build very cheap budget VDRs based on modern hardware like Intel D945GCLF/D945GCLF2 or Pundit P5945GC. With SCART output quality equaling a FF card but at fractional cost. As with former Radeon vga-sync-fields patch even/odd fields are routed straightly from softdecoder to VGA port. No software deinterlacing takes place thus saving CPU power and resulting in an artifact free picture. All you additionally need is a special VGA2SCART adapter cable like this: http://www.vdr-portal.de/board/thread.php?postid=742945#post742945 Because VGA2SCART patches now appear to become more popular in this FF dominated VDR-world:-) VDR distribution easy-vdr just started to integrate Radeon and Intel VGA2SCART patches for everyone use. Please see also http://www.easy-vdr.de/forum/index.php?board=63.0 It seems German related sites show more interest in VGA2SCART things. So I did not spend further time to translate all things I developed for VGA2SCART into english. Sorry for that;-) Due to -ENOTIME I have not yet integrated my last Intel patches to vga-sync-fields patch version found at http://lowbyte.de/vga-sync-fields/ Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On 21 Jan 2009, at 15:02, Thomas Hilber wrote: This way you now can build very cheap budget VDRs based on modern hardware like Intel D945GCLF/D945GCLF2 or Pundit P5945GC. With SCART output quality equaling a FF card but at fractional cost. Does it work with 915 hardware as well? -- Torgeir Veimo torg...@pobox.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, Jan 21, 2009 at 03:22:15PM +1000, Torgeir Veimo wrote: Does it work with 915 hardware as well? Yup, a few days ago I successfully testet the patch on my Asus EEE 701. Even replaying interlaced SD content the 900MHz CPU idles at about 60%. Please see table at http://www.vdr-portal.de/board/thread.php?postid=784548#post784548 It appears that most of recent Intel based (i9xx graphics) netbooks are suitable for VGA2SCART with frame rate control (synced fields). A complete list of VGA2SCART capable chipsets is under contruction here: http://www.vdr-portal.de/board/thread.php?postid=782181#post782181 legend: a '+' in 'PAL' column means: unsynced (with software deinterlacing) VGA2SCART is possible. a '+' in 'FRC' column means: synced (i.e. frame rate control obsoleting software deinterlacing) VGA2SCART is possible. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On 21 Jan 2009, at 16:17, Thomas Hilber wrote: On Wed, Jan 21, 2009 at 03:22:15PM +1000, Torgeir Veimo wrote: Does it work with 915 hardware as well? Yup, a few days ago I successfully testet the patch on my Asus EEE 701. Even replaying interlaced SD content the 900MHz CPU idles at about 60%. Please see table at http://www.vdr-portal.de/board/thread.php?postid=784548#post784548 It appears that most of recent Intel based (i9xx graphics) netbooks are suitable for VGA2SCART with frame rate control (synced fields). A complete list of VGA2SCART capable chipsets is under contruction here: http://www.vdr-portal.de/board/thread.php?postid=782181#post782181 legend: a '+' in 'PAL' column means: unsynced (with software deinterlacing) VGA2SCART is possible. a '+' in 'FRC' column means: synced (i.e. frame rate control obsoleting software deinterlacing) VGA2SCART is possible. Ok, I have this hardware; http://www.silentpcreview.com/article311-page1.html an asus mainboard i915ga-hfs, with 915G graphics and onboard YPbPr and DVI outputs. I figure with some tweaking, it should be possible to run pure RGB or YPbPr out without using any vga to scart adapter. There's no english howto anywhere? -- Torgeir Veimo torg...@pobox.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Options for deinterlacing (or not)
On Wed, Jan 21, 2009 at 04:23:59PM +1000, Torgeir Veimo wrote: Ok, I have this hardware; http://www.silentpcreview.com/article311-page1.html an asus mainboard i915ga-hfs, with 915G graphics and onboard YPbPr and DVI outputs. I figure with some tweaking, it should be possible to run pure RGB or YPbPr out without using any vga to scart adapter. yeah! I guess you even could run interlaced HDMI (with a DVI to HDMI adaptor) with synced fields using that hardware. This would be especially useful for HDTV applications as software deinterlacing there is a real pain. On german vdr-portal 'durchflieger' already published some working configurations with synced fields (frame rate control) over HDMI. The radeon-frc patch README and description is written in English. Please refer to: http://www.vdr-portal.de/board/thread.php?threadid=80567 There's no english howto anywhere? sorry, not yet. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Options for deinterlacing (or not)
I want to replace my UK Sky digital box with VDR (I only want the free to air channels) for watching/recording TV over HDMI on my plasma. So far everything is working OK, I have vdr 1.7.3 and xine running on an ASUS M2N VM-HDMI (nvidia) mobo with the s2-liplianin drivers for my Nova SD2 card. My problem is interlacing. I've googled back through the archives and got a lot of info from there, however I still have one question and one request. If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do any de interlacing in xine, why is this not the same as what my digibox does? I'm guessing it has something to do with xine outputting a complete frame when the broadcast sends each field? What I'd hope happen (for interlaced material) is that xine receives a field from VDR, scales it to the X resolution (halfed vertically of course) and sends it to the the graphics card which just passes it on to the TV which draws that field. That doesn't seem to happen so where have I gone wrong? There's a lot of options for tvtime in xine, TomsMoComp and full framerate seem popular. What settings are others using? -- Scott ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
