Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video audio, etc.
On Wed, Aug 25, 2010 at 11:16:37PM +0300, Prelude wrote: I have suffered this annoying judder in both live and recording viewing. My config_xineliboutput: http://pastebin.com/kxe7RvX0 xorg.xonf: http://pastebin.com/6fCvWvxU sorry, from that configuration alone I can't tell you what's going wrong. When I started to setup my VDPAU machines (end of last year) I first made sure that the Xserver really is running a 50Hz modeline. I mostly play 25/50Hz streams. This way I found an Xserver bug/misbehavior. Only if I explicitly set the modeline params manually in xorg.conf I get real 50Hz output (instead of 60Hz). Please see attached my xorg.conf. Always try: DISPLAY=:0 nvidia-settings --query RefreshRate to verify. Even the Xorg.0.log lies about the fact that 50Hz are active but in reality it uses 60Hz. Maybe nVidia has fixed that in the meantime. After this tuning to a channel with live ticker gives me perfect results. There is not any judder at all. The problem with all this juddering is that the symptom 'judder' alone gives you no hint at all about the root cause of the problem. Maybe you first verify your current nvidia-settings result. cheers Thomas Section Monitor Identifier Monitor0 HorizSync 50.0 - 60.0 VertRefresh 50.0 Option ExactModeTimingsDVI true Option UseEDID false ModeLine 1920x1...@50p 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync EndSection Section Device Identifier Device0 Driver nvidia Option ModeDebug True EndSection Section Screen Identifier Screen0 Device Device0 MonitorMonitor0 DefaultDepth24 SubSection Display Modes 1920x1...@50p EndSubSection EndSection Section Extensions Option Composite Disable EndSection ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video audio, etc.
On Thu, Aug 26, 2010 at 03:06:51PM +0100, Tony Houghton wrote: Are you aware of the interaction between DynamicTwinView and XRandR? The no. But if Xorg.0.log tells me (in the bad case): (II) NVIDIA(0): Validating Mode 1920x1080: (II) NVIDIA(0): 1920 x 1080 @ 50 Hz (II) NVIDIA(0): For use as DFP backend. (II) NVIDIA(0): Mode Source: EDID (II) NVIDIA(0): Pixel Clock : 148.50 MHz (II) NVIDIA(0): HRes, HSyncStart : 1920, 2448 (II) NVIDIA(0): HSyncEnd, HTotal : 2492, 2640 (II) NVIDIA(0): VRes, VSyncStart : 1080, 1084 (II) NVIDIA(0): VSyncEnd, VTotal : 1089, 1125 (II) NVIDIA(0): H/V Polarity : +/+ (II) NVIDIA(0): Mode is valid. [...] (II) NVIDIA(0): 1920x1080_50 : 1920 x 1080 @ 50.0 Hz (from: EDID) [...] (II) NVIDIA(0): Config Options in the README. (II) NVIDIA(0): Setting mode 1920x1080_50 and it uses a 60Hz modeline though this is clearly a Xserver bug for me. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xorg displaying 50 Hz but uses 60 Hz with Nvidia driver (was: Advice on new motherboard, xineliboutput, vdpau, hdmi video audio, etc.)
On Thu, Aug 26, 2010 at 04:31:28PM +0200, Paul Menzel wrote: Do you know if it has been reported to Nvidia? I think the X.org people would not look at it, since you use the proprietary driver. I dont't know if especially this problem has been reported to nVidia. There are heaps of error reports of that kind reported to nVidia that all sound quite similar. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xorg displaying 50 Hz but uses 60 Hz with Nvidia driver
On Thu, Aug 26, 2010 at 11:23:22PM +0200, Paul Menzel wrote: Thomas, having just VertRefresh 50.0 in your `xorg.conf`, did you measure the 60 Hz directly at the output or were you just saying the tools reported 60 Hz? without specifying the modeline directly in xorg.conf (the bad case) the tool reported 60Hz, Xorg.0.log reports 50Hz and at the same time it was juddering like mad. This is clearly a bug for me because the Modes 1920x1080_50 setting is ignored and on top of that Xorg.0.log lies about this. After specifying the modeline directly in xorg.conf (the workaround) the tool and Xorg.0.log reported 50Hz. And live ticker scrolled smoothly without any jumping. For me this is evidence enough the tool reported the right thing in both cases. cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VGA2SCART: circuit diagram with audio pins
On Wed, Aug 25, 2010 at 01:36:34PM +0200, Matthias Fechner wrote: hm, here you are right. Does anyone knows if the POV mainboard (http://www.pointofview-online.com/showroom.php?shop_mode=product_detailproduct_id=97) works with the VGA2SCART adapter? AFAIK all more recent (aka VDPAU compatible) nVidia graphics run VGA2SCART flawlessly. There are found many VGA2SCART success stories at [2]. I myself use an POV ION 330-1 for VGA2SCART. If you should decide to use my favorite VGA-to-SCART adaptor [1] a minor problem could arise. Newer VGA ports often don't provide 5V+ at pin9 (VESA-DCC) any more. In that case you simply use any other 5V+ source instead. cheers Thomas [1] http://lowbyte.de/vga-sync-fields/vga-sync-fields/README [2] http://www.vdr-portal.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VGA2SCART: circuit diagram with audio pins (was: VDR with 50Hz clock output)
On Mon, Aug 23, 2010 at 10:59:52AM +0200, Paul Menzel wrote: I found an updated diagram at [1]. I hope it is what you wanted. [1] http://crashme.cx/vdr-portal-picts/VGA_SCART_RGB_NEWER.png this is just a full blown schematic with charge pump circuit to provide up to 11V at SCART pin 8. If you don't need that you might use my stripped down to the bare minimum circuit shown at [1]. The simple circuit has been proven successful in many cases. It has been sold ready to use at [2]. I don't know if it's still manufactured. cheers Thomas [1] http://lowbyte.de/vga-sync-fields/vga-sync-fields/README [2] http://www.vdr-portal.de/board/thread.php?threadid=84693 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VGA2SCART: circuit diagram with audio pins
On Wed, Aug 25, 2010 at 06:46:54PM +0200, Matthias Fechner wrote: thanks, that are great news (but in the README only the ATI and Intel cards are mentioned :) ). right. The circuit was just a byproduct for the vga-sync-fields project. ok, so you can use +5V from an USB port which I need for infrared too. sure I will keep you up-to-date. Maybe you are interested in [1]. That guy uses also that minimum VGA2SCART circuit. BTW: In the meantime yaVDR [2] includes native VGA2SCART support. cheers Thomas [1] http://www.vdr-portal.de/board/thread.php?threadid=98112 [2] http://www.yavdr.org/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video audio, etc.
On Wed, Aug 18, 2010 at 10:13:56AM +0200, jori.hamalai...@teliasonera.com wrote: Computer hardware usually cannot provide 50.000Hz, 59.940Hz or 23.976Hz outputs to your TV/Monitor. This will cause some judder on display output as MPEG/AVC input-stream is not synchronized to output framerate. it's correct that computer hardware normally cannot provide 50.000Hz. Nor can it adapt the framerate dynamically as I did for some handpicked hardware in my sync-fields-project [1]. But even in the case of non synchronized output framerate (VDPAU) it does not necessarily mean that judder will result. Nvidia graphics use excellent deinterlacers. These produce a stream of progressive frames with field frequency (e.g. 50Hz) out of an interlaced source. Single frame doubler/losses at 50Hz are not visible to the human eye. To put that in other words: VDPAU uses some brute force (deinterlacing) to work around their design flaw (missing synchronization). In practice this works very well. Surely it's not an optimal solution: the price for that is excess graphics power requirement if you think in terms of 5W units. But nonetheless the smoothness of picture flow is excellent. If some people report they observe judder though this mostly is a result of a wrong setup (xorg.conf) or use of temporarily broken beta software (xine derivates). With VDPAU design there exists nothing like inherent judder. For the future I wish there once will become available some graphics with native dynamic framerate support. Never seen such thing until today. cheers Thomas [1] http://lowbyte.de/vga-sync-fields/vga-sync-fields/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdpau experience
On Sat, Oct 24, 2009 at 01:22:42PM +0200, Helmut Auer wrote: xineliboutput is a bit more difficult, because the cvs is changing nearly daily, so there is currently no patch available, but it should work without patches. where is the problem? Just do an cvs -z3 -d:pserver:anonym...@xineliboutput.cvs.sourceforge.net:/cvsroot/xineliboutput co -D '2009/10/13 12:00:00' vdr-xineliboutput and you are fine with current 'xineliboutput-cvs-20091013-vdpau-extensions-v11.diff.gz' Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FRC - RGB/Scart with the Intel 830 driver
On Tue, Sep 08, 2009 at 12:16:30AM +0100, dave cunningham wrote: I've finally tried to get this up and running with the patched Intel xserver on a D945GCLF2 atom board (I see from your readme that you've tried this configuration so assume it should work). right, works very well The desktop's working just fine but I'm having problems with XV. When running in a window xv's fine however when I switch to full screen all I get is a blue screen + audio. probably a xorg.conf configuration issue. Did you use clone mode? That does not work with interlaced timings. Symptoms are like the ones you describe. Attached is a working sample for xorg.conf I use for my D945GCLF2. - Thomas Section Monitor Identifier Monitor0 Modeline 720x576_50i 13.875 720 744 808 888 576 580 585 625 -hsync -vsync interlace Modeline 800x520_50i 17.00800 856 936 1088 520 548 553 625 -hsync -vsync interlace ModeLine 1440x576_50i 27.75 1440 1488 1609 1769 576 580 585 625 -hsync -vsync interlace Modeline 1368x768_60 85.86 1368 1440 1584 1800 768 769 772 795 -hsync +vsync Modeline 1600x1200_60161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync Option PreferredMode1440x576_50i EndSection Section Monitor Identifier Monitor1 Option Ignore true EndSection Section Monitor Identifier Monitor2 ModeLine 1440x576_50i 27.75 1440 1488 1612 1772 576 580 585 625 -hsync -vsync interlace Modeline 1600x1200_50i65.92 1600 1696 1864 2131 1200 1203 1207 1238 -hsync +vsync interlace Option PreferredMode1440x576_50i Option Ignore true EndSection Section Device Identifier Card0 Driver intel Option monitor-VGA Monitor0 Option monitor-LVDS Monitor1 Option monitor-TMDS-1Monitor2 #Option SyncFieldsTrue #Option SF_YScaleFineTune 0 #Option SF_YRGB_VPhase0 #Option SF_UV_VPhase 0 #Option SF_SchedPrio 0 Option SF_Debug 12000 EndSection Section Screen Identifier Screen0 MonitorMonitor0 Device Card0 DefaultDepth24 EndSection ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FRC - RGB/Scart with the Intel 830 driver
On Thu, Aug 27, 2009 at 11:14:22AM +0300, Pasi Kärkkäinen wrote: Hmm.. why without? FRC doesn't work on Intel @ 720x576i ? 720x576i and 1440x576i are both SCART/PAL resolutions with a line frequency of 15.625kHz. VGA2SCART+FRC on Intel requires 1440x576i. VGA2SCART+FRC on ATI also runs directly with 720x576i. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FRC - RGB/Scart with the Intel 830 driver
On Thu, Aug 27, 2009 at 10:44:59AM +0100, dave cunningham wrote: Do standard CRTs handle this increased resolution/clock? I've never tried driving this signal into my TV. I haven't experienced any problems even with very old TVs caused by the higher video signal bandwidth. In fact I use the cable from here http://members.optusnet.com.au/eviltim/scart.htm with the cut off circuit so I'd actually have to build a new cable to use this resolution. you can use any VGA2SCART cable realizing some composite sync circuitry. My favorite cable (the simplest circuit I know from) is described in my README. I don't know why most VGA2SCART cables are composed of so many parts. Not that that's particularly difficult but do you gain any advantage using the higher resolution on the Intel cards vs standard 576i with ATI. If not then I'll probably just save the hassle and buy an ATI card of eBay instead. ATI cards do have a major drawback compared to Intel cards: They can't scale vertically in interlaced mode because they can't scale both fields independently. So your TV must handle format adaptions. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FRC - RGB/Scart with the Intel 830 driver
On Wed, Aug 26, 2009 at 03:40:25PM +0100, dave cunningham wrote: If I'm reading the patches correctly it seems that the ATI chips can currently do 720x576 only, where the Intel chips can be configured for 1440x576 and 1600x1200 only. for VGA2SCART (without FRC) Intel chips can be setup for 720x576i also. The 1600x1200i is just an experimental sample resolution for use of FRC at a DVI/HDMI port. Why exactly 1600x1200i? I do not yet own a HDMI capable monitor. My DVI test monitor accepts interlaced modelines at 1600x1200i only. The Intel driver has been patched to allow a 12MHz dot clock - is it in fact capable of supporting 720x576 interlaced? If so is there a hardware limitation preventing the FRC syncing working at this resolution? The 1440x576i is driven at doubled dot clock. So it effectively represents a regular 720x576i PAL timing too. The reason for 1440x576i is: the FRC gains doubled horizontal timing resolution. As a result variable frame rate can be controlled in finer (twice as much) increments. BTW: With the help of some users of vdr-portal.de it turned out that even this finer frame rate control eventually is to coarse for some particular picky TVs. Though I myself didn't face such a TV yet. (I ask as I'm planning to use a Mini-ITX Atom board with a GMA950 to be hooked up to a standard-def TV. It would be good if I could use the onboard video and leave the PCI slot free.) I just tested i915 and i945 (see [1]). The D945GSEJT board gives you the smallest and most energy efficient VDR currently possible. You can use the plain board as SCART streaming device. Cheers Thomas [1] http://lowbyte.de/vga-sync-fields/vga-sync-fields/README ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD clients for vdr
On Thu, Aug 20, 2009 at 08:31:43AM +1000, Torgeir Veimo wrote: In my experience, you just have to do deinterlacing in vdpau with interlaced content, even when displaying on an interlaced display. If you try to output interlaced material directly, you get ghosting since the weaved frames are copied to the progressive surface, and the output resolution might be different than the weave pattern. the main reason why nvidia chooses to deinterlace always even if you use an interlaced video timing is not the scaling problem you mention. This could be eventually solved (albeit not perfectly) by scaling both fields independently. The main reason is: even with VDPAU there still exists no synchronization between stream and video timing. That means there will be an arbitrary amount of lost/doubled fields with current VDPAU implementation. Nvidias workaround now is to deinterlace all content in any case. As a result these field losses are (mostly) not directly visible to the human eye. Ceasing from deinterlacing here would reveal field sequence problems (caused by missing stream-synchronization) immediately. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD clients for vdr
On Sat, Aug 22, 2009 at 01:12:43PM +0400, Goga777 wrote: is it possible to solve radically this problem with vdpau ? did you discuss with nvidia developpers about this issue ? I don't know if nvidia hardware is capable of such things at all. This issue (among others) once has been discussed somewhere here [1]. - Thomas [1] http://www.nvnews.net/vbulletin/showthread.php?t=123895 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Thu, Jul 02, 2009 at 10:34:09AM +0200, Paul Menzel wrote: Could you test your boards with HD-material, for example some movie trailers? Could you please share your results, what resolutions are no way to play HD-material with this board So is the following summary correct? The hardware is capable to play certain HDTV resolutions, but the xf86-video-intel driver does not the hardware is capable to play most HDTV resolutions (over VGA or DVI) and xf86-video-intel does support this. But the hardware is not capable of decoding H.264. At least not today with current linux drivers. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Fri, Jun 05, 2009 at 11:17:54AM +0200, jori.hamalai...@teliasonera.com wrote: It would mean that no judder and studder on HD-quality. With VDPAU the problem still might be 50Hz vs 50.02Hz -thing so you cannot get frame accurate display. With every 5 seconds you might have duplicated display of frame or dropped frame. This is not acceptable by my I fully agree. The *only* way to overcome this is by synchronizing VGA video timing to DVB-stream clock. I realized this for some ATI-Radeon and Intel-GMA hardware. Even the brandnew Intel D945GSEJT now is fully supported with VGA/SCART/DVI/HDMI output. For further details see: http://lowbyte.de/vga-sync-fields/ http://vga2scart.gw90.de/ http://www.easy-vdr.de/git?p=frc.git/.git;a=summary git clone git://www.easy-vdr.de/git/frc This gives exact 50Hz 1080p mode. But does your VGA-cards internal clock generator allow exactly 148.500MHz. If VGA can only generate f.ex 148.460MHz clock then you with vga-sync-fields patch you always have *exactly* 50Hz since video clock frequency is dynamically controlled and corrected. have 49.99Hz output signal. Also is pulse width divisable by 8 etc. this restriction is no longer true for Intel 945Gxx hardware. cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FRC plugin (was - xineliboutput GIT mirror)
On Sun, Apr 19, 2009 at 12:54:15PM +0200, Tobi wrote: the graphcis card drivers and so on. It just started, so don't expect much content yet. the GIT repos for FRC/VGA2SCART still must be cloned this way: git clone git://vga2scart.gw90.de/git/vga2scart FRC/VGA2SCART WIKI can be found here [1] my personal snapshots of FRC/VGA2SCART GIT repos can be found here [2] - Thomas [1] http://vga2scart.gw90.de/ [2] http://lowbyte.de/vga-sync-fields/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [FRC] Why are patches for framebuffer not needed anymore in release 0.1.0?
On Sun, Mar 29, 2009 at 12:21:18AM +0100, Paul Menzel wrote: you released version 0.1.0 [1]. Could you please explain to me, why the framebuffer patches (intelfb, radeonfb) are not needed anymore? since version 0.1.0 you will not need DRM from GIT anymore. You just can use DRM as provided by the standard kernel shipped with debian 5.0 (lenny). This should ease the handling of the patch (see [2]). In the course of that I concentrated the patches in drm-radeon-intel.patch (version 0.0.11 and older) fb-radeon-intel.patch to one file fb-drm-radeon-intel.patch (since version 0.1.0) Cheers Thomas [1] http://lowbyte.de/vga-sync-fields/vga-sync-fields/ [2] http://lowbyte.de/vga-sync-fields/vga-sync-fields/INSTALL ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [FRC] Why are patches for framebuffer not needed anymore in release 0.1.0?
On Sun, Mar 29, 2009 at 08:32:21PM +0300, Pasi Kärkkäinen wrote: Does Lenny have some extra patches in the kernel, or does it work with all vanilla 2.6.26+ kernels? for sure has Lenny some extra patches in the kernel. But probably they don't interfere with the vga-sync-fields (FRC) patch. I mean you should give vanilla 2.6.26+ a try... Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [VGA sync field] question to fb-radeon-intel.patch
On Wed, Mar 11, 2009 at 06:15:04PM +0100, Paul Menzel wrote: 1. In your patchset the patch fb-radeon-intel.patch [1] does include changes to drivers/video/intelfb/intelfbhw.c although in the install instructions [2] it is stated that intel drivers do not need to be modified. sorry, install instructions are not up to date for the Intel version of the patch. The changelog in 0.11 includes these two items. - patch against intelfb (kernel 2.6.26) to allow for PAL/SCART video timings. You now can use a regular SCART CRT as display for linux console. - fixed a bug in intelfb initialization which sporadically setup video timing with weirdous values I guess the installation instructions need to be updated for release 0.11. right. as said installation instructions have not been touched since a while. I just included the plain Intel patches into the package. There was not yet too much interest in the patches anyway. So I did not want to waste my time for documentation:-) If this is correct I would update the instructions. thank you for that. a) Why is MIN_CLOCK set to 25000 in intelfbhw.h [3]? What would be the downside of setting it to 1? MIN_CLOCK is set to 12000 by the patch. What allows for SCART suitable dotclocks. I don't know why the original driver denies such low clock frequencies. b) Where do I get information about the registers, like what DPLL_A and DPLL_VCO_ENABLE is? In the header file some values are assigned to them, but where is it documented what they mean? DPLL_A (DPLLA_CTRL-DPLL A Control Register) is documented here: Intel® 965 Express Chipset Family, Volume Three Section: Display Clock Control Registers The doc can be found here: http://intellinuxgraphics.org/documentation.html Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [VGA sync field] question to fb-radeon-intel.patch
On Thu, Mar 12, 2009 at 06:31:47PM +0100, Thomas Hilber wrote: a) Why is MIN_CLOCK set to 25000 in intelfbhw.h [3]? What would be the downside of setting it to 1? MIN_CLOCK is set to 12000 by the patch. What allows for SCART suitable dotclocks. I don't know why the original driver denies such low clock frequencies. I forgot to say patching the intelfb is only needed if you even want to run the linux console in VGA2SCART mode. For the Xserver in VGA2SCART+FRC mode it's not needed. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [VGA sync field] question to fb-radeon-intel.patch
On Thu, Mar 12, 2009 at 07:36:01PM +0100, Paul Menzel wrote: I hope, you have seen my message to linux-fbdev-devel [1]. I will try to do what Krzysztof suggested, but will have to read more about that. Maybe we get it into Linux kernel 2.6.30. yeah, I've seen that. Should we continue discussion about this on linux-fbdev-devel, that means, can subscribe there? I subscribed to linux-fbdev-devel. But haven't had the time to adapt the patch as requested. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [VGA sync field] question to fb-radeon-intel.patch
On Thu, Mar 12, 2009 at 07:36:53PM +0100, Torgeir Veimo wrote: Did you look into making your approach work with DirectFB yet? I don't think it's a big deal to port the Intel version of the FRC patch to DirectFB. But sorry, I don't use DirectFB. I can't see much advantage over a plain Xserver unless running something like an embedded system. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVD autoplay
On Fri, Mar 06, 2009 at 10:43:08PM +0100, Petric Frank wrote: i'm looking for a plugin or method to automatically display a play/stop/eject/... menu on the on the screen when a DVD is entered into the drive. Also a possible autoplay DVD via vdr ould be a good idea. first you have to detect tray status. I solved that for me a few months ago by this small program [1]. Dont't know if there are better methods available. - Thomas [1] http://www.vdr-portal.de/board/thread.php?postid=761725#post761725 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] development infrastructur for VGA2SCART patch set
On Mon, Mar 02, 2009 at 10:03:12AM +0200, Pasi Kärkkäinen wrote: Hmm.. so you get 50 Hz interlaced output with this xorg.conf. Are you able to sync to each field separately? of course not on nVidia graphics. They haven't offered their specs for us to implement that. But nevertheless this modeline gives smooth PAL playback because the display (a SCART device) inherently plays 50Hz. The major disadvantage of missing capability to have sync to field is: you must deinterlace by software. Though you use an interlaced VGA output. And software deinterlacers as we all know cause bad picture quality. Sync to separate fields currently only works with ATI Radeon and Intel i9xx chipsets. That's what FrameRateControl (FRC) is based upon in the patches mentioned above. This way you can cease from deinterlacing in software giving you an artifact free picture. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] development infrastructur for VGA2SCART patch set
On Sun, Mar 01, 2009 at 06:43:00PM +0100, Paul Menzel wrote: Reading your README I assume you are familiar with Git. Therefore I choose it as a backend. Thank you for your effort so far. I have no special preferences here. GIT or CVS is ok for me. Concerning the wiki: I would prefer a neutral domain or even better http://www.linuxtv.org/wiki/ for this. IMHO all VDR related documentation and discussion should be collected at one place. 'Hosting' the source is another issue. We could use sourceforge.net for this? - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] development infrastructur for VGA2SCART patch set
On Mon, Mar 02, 2009 at 01:19:53PM +0100, Paul Menzel wrote: Concerning the wiki: I would prefer a neutral domain Sure. I had no other domain handy. Your domain name could also be used, if you set up DNS this way (vga2scart.lowbyte.de) or we register some free domain name vga2scart.de.vu or vga2scart.eu.org? something like vga2scart.eu.org sounds good. Though our project is not limited to vga2scart. In the meantime I successfully use a modified version of the vga-sync-fields patch on DVI/HDMI interface also. Providing me high quality 576i over DVI/HDMI on intel i9xx machines with SDVO ports. Originating from SDTV our project could be important for HDTV also. or even better http://www.linuxtv.org/wiki/ for this. If you are fine with that, great. My reasoning choosing ikiwiki is, that I would expect it to save you (and others) time. I wonder why nobody else joins our discussion. Just to clarify: My major goal was to prove that graphics cards can provide the same picture quality as FF-cards do. But with wider flexibility at fractional cost of a FF-card among many other advantages. And without the need of expensive and time consuming hardware mods like full-TS mod, AV-board, J2 mod etc. We now have a working sample installation for a budget system with FRC based on easy-vdr [4] which has been successfully setup by various people. Reaching this stage I consider my 'mission' completed. You can setup a repos with current source found in vga-sync-fields package at anytime. Everybody is invited to test and contribute. I don't consider it as 'my' project. I just will contribute the initial idea behind frame rate control and a sample implementation for it. And of course I will continue to develop as time permits. 1. Everyone can use his favorite text editor and saves time not having to open a browser and use web forms. 2. Let us say, you implement support for another card(?), than you would update the README right away using the console and your editor of choice and the Wiki is updated, too. Otherwise you would have to log into http://www.linuxtv.org/wiki/ find the page, hit edit, (wait for it to load,), ??? ok, I wouldn't bother much to log in. It depends on what the majority of possible contributers would prefer. Do you care about this? It all depends on your needs and habits. no. On a side note. Do you know if linuxtv.org is also for non-English languages. In my opinion, it would not be so beneficial to have the documentation for one language on one site and for another language on another. I don't know. But I think an english doc should be enough. IMHO all VDR related documentation and discussion should be collected at one place. Is linuxtv.org the place for VDR related documentation? At least they have a wiki. The German VDR wiki [1] refers to [2] when you select the english language button. Do you mean by discussion mailing lists? right. I never used sourceforge.net. So I can not say anything about this. They offer SVN and CVS, do not they? sorry, I can't tell My conclusion from your reply is, that publishing your repository on your server is not an option. unfortunately it's not an option ATM Could you please tell me, how you are managing the VGA2SCART patches right now and if publishing your tree on a server or for example [1] would be an option. 'gitorious.org' appears ok for me. As I worked alone yet on this project I did not use any source code control system until now. As said, I don't consider it as my project. Everybody is invited to improve the project status. There are left many ideas and features still not implemented. I already wrote a to-do list with issues of lesser priority. But features that would improve things a lot. - like writing a tool similar to powerstrip. Which lets you adjust overscan and other parameters in real time by pressing cursor keys. or - derive xine's masterclock from graphics card frame rate. This would provide almost instant sync after a channel switch. The idea for this was published by 'durchflieger' [3] There are still left many things to do. As often in life it's not a matter of ideas but a matter of time:) Cheers Thomas [1] http://vdr-wiki.de/wiki/index.php/Hauptseite [2] http://www.linuxtv.org/vdrwiki [3] http://www.vdr-portal.de/board/thread.php?postid=796538#post796538 [4] http://www.easy-vdr.de/forum/index.php?topic=6072.msg51320#msg51320 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] development infrastructur for VGA2SCART patch set
On Sat, Feb 28, 2009 at 08:04:17PM +0100, Paul Menzel wrote: Why don't you just use the easy-vdr install script I mentioned above which already has been proven successful? I just checked it out. But the main problem in distribution is, that everyone has to register to be able to download attachments. what's wrong with it? If registering is too much effort - nothing doing. I just took a look. On quick look at the homepage and the Wiki I could not find any information on [1] on what Easy VDR does and on what distro it is based. Looking at the script it looks like it is based on Debian Etch. it's a complete VDR distribution based on debian etch. There is no better way to document an installation than a working shell script:-) Of course, but if one has to register at a forum to get the files it will prevent people from getting it and to contributing to the project. but it will guarantee to a certain extend that you will obtain a tested and working setup out-of-the-box after installation has finished. I would be willing to begin to start such a page. But I wanted to know your preferences, so that chances are high, that you will feel comfortable with it. the problem is you can write whole books about the VGA2SCART theme. I *certainly* won't have the time to do that. But for the beginning I could post a plain list of URLs where I finally got my informations from. - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] development infrastructur for VGA2SCART patch set
On Sun, Mar 01, 2009 at 01:13:32AM +0100, Paul Menzel wrote: In general I would have no objections against this. What kind of patches is this all about? I haven't followed this VGA2SCART thing, but a quick lookup showed, that this involves patching XOrg stuff and xineliboutput. That is correct. It requires several programs to be patched. If this is the case, then a single Git repository might not be appropriate. we must distinguish 4 cases. VGA2SCART on: 1. ATI Radeon without FRC 2. Intel i9xx without FRC 3. ATI Radeon withFRC 4. Intel i9xx withFRC software patches required: 1. - xserver-xorg-video-radeon (newer versions may not need it) 2. - xserver-xorg-video-intel 3. - xserver-xorg-video-radeon - xineliboutput (newer versions already adopted the patch) - xine-lib - radeon-drm kernel module 4. - xserver-xorg-video-intel - xineliboutput (newer versions already adopted the patch) - xine-lib FRC stands for frame rate control. That means VGA video timing is synchronized with DVB stream = no software deinterlacing is needed any more. Fields are forwarded directly from softdecoder to VGA port. The simple version without FRC allows conventional operation (with software deinterlacing). It provides the minimum requirements needed for SCART over VGA. I don't know either how to maintain the patch set. So at least I took a few snapshots from my development and collected them at 'http://lowbyte.de/vga-sync-fields/' - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] development infrastructur for VGA2SCART patch set
On Thu, Feb 26, 2009 at 09:12:36AM +0100, Paul Menzel wrote: due to lack of time and interest I do not yet run a full blown homepage. But at least I started to collect the plain patches here [3]. That is what I thought. So maybe other people who are not good or intersted in coding could help set up this web site and repository. Would you be willing to use this. Do you have a favorite system for SCM At least somebody must start such a page.. For the moment it takes less time for me to answer questions in the corresponding threads on easy-vdr.de and vdr-portal.de directly. Why don't you just use the easy-vdr install script I mentioned above which already has been proven successful? If you are interested in what's happening behind the scenes - no problem. The script builds all VGA2SCART + FRC relevant things from source. There is no better way to document an installation than a working shell script:-) Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] development infrastructur for VGA2SCART patch set (was: Re: Options for deinterlacing (or not))
On Wed, Feb 25, 2009 at 01:35:01PM +0100, Paul Menzel wrote: Is there a homepage for the VGA2SCART patch set with information about it? A repository? due to lack of time and interest I do not yet run a full blown homepage. But at least I started to collect the plain patches here [3]. There seems to be some interest from people outside VDR Portal [1] in the patches. So a repository with all the different branches (for example yours and durchfliegers) could be used to manage the files. Would a Wiki page be useful or is the README enough? Surely a Wiki page could be useful. Not only for special frame rate control (FRC) patches. Also for VGA2SCART in general. This site should be run in English. But in the past the most interest in the patches has been shown by german users. That's why I payed more attention to them. BTW: Markus Mahlzeit Küchler already started a german Wiki [2] Or could one ask the project your patches are related to, if they could set up a branch for each of the patches and the information is managed in a Wiki like VDR Wiki [2] or the one of Freedesktop [3]? there is no 'project' my patches are related to. I just wondered why people often are complaining about non smooth playback on graphics cards. On the other hand there is NO official implementation for synchronization between stream and VGA timing until today. Neither for SD nor for HD. So I just started to solve the problem for my own purposes. That's how it begun. I think there are 2 viable ways to distribute the patches: 1.) by generic instructions how to build the system (i.e. a big README) 2.) by some ready-to-use VDR distribution The FRC patches take into account the entire PC. All software components (kernel, xserver, softdecoder) involved must fit together exactly. Finally I decided in favor of 2.) and I started to help to integrate the patches into easy-vdr.de [1] distribution. BTW: this work for me is more interesting than to write documentation about how to install the patches:-) You now can simply download+install an easy-vdr based system. After this you will have a working system out-of-the-box with VGA2SCART + FRC. Successfully tested on D945GCLF and Pundit P1-P5945GC and some other Intel i9xx based boxes. ATI Radeon type systems are not yet included there. Cheers Thomas [1] http://www.easy-vdr.de/forum/index.php?topic=6072.msg51320#msg51320 [2] http://vdr-wiki.de/wiki/index.php/CheapBudget [3] http://lowbyte.de/vga-sync-fields/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] Questions to VGA2SCART cable
On Wed, Feb 25, 2009 at 02:51:05PM +, Tony Houghton wrote: I'm not sure whether C Scheeder is right, but it seems highly likely. Christoph is right. The buyable cables operate the wrong direction for our purposes. Different cards need diffeernt types of cable. For example ATI and Matrox cards can both output the necessary composite sync, but they need slightly diffeernt wiring. Most other cards can't output composite sync so you need a circuit to combine them. with my cable described here: http://www.vdr-portal.de/board/thread.php?postid=742945#post742945 you have a multi purpose solution because it does not take into account special features of some special graphics cards. I never understood why people rely on things like on-chip composite sync. You easily can do that externally by two Rs and one T. I successfully use the VGA2SCART cable above for nVidia, ATI Radeon and Intel graphics. Of course driver initializes separate sync for all three. If you do go ahead and build a cable I'd recommend cutting one end off an existing VGA cable and using a multimeter to work out which wire is that's how I do that. But take care to grab a cable with VGA Pin 9 wired. There are many cables out there with this pin not being connected. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdpau output to pal tv,
On Mon, Feb 16, 2009 at 11:48:50PM +1000, Torgeir Veimo wrote: On 16 Feb 2009, at 23:29, Tony Houghton wrote: And if the video has to be scaled it would have to scale each field separately then reinterlace them line-by-line at the output resolution @Tony Houghton: is it really possible to scale each field separately without producing artifacts? Isn't deinterlacing always neccessary prior to scaling? IMHO scaling does imply that even lines are allowed to blur into odd lines if the scale factor forces this. But artifact free blur of both fields is NOT possible if you either - don't deinterlace prior to scale or - keep even and odd fields separated during scale Ok, I guess this single issue implies that vdpau is not fully suitable for displaying interlaced material with interlaced output. @Torgeir Veimo: not sure about this. Intel series i9xx graphics is able to scale by hardware even in interlaced mode. I use this feature for my intel based frame rate control patches (SCART/RGB/PAL vga-sync-fields patch). - Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdpau output to pal tv,
On Mon, Feb 16, 2009 at 09:05:04PM +, Tony Houghton wrote: not sure about this. Intel series i9xx graphics is able to scale by hardware even in interlaced mode. I use this feature for my intel based frame rate control patches (SCART/RGB/PAL vga-sync-fields patch). VDPAU is currently only on NVidia cards although it's possible Intel and right. But I thought that NVidia could eventually provide the same scale-interlaced-picture hardware feature as Intel does. even ATI may provide backends for it in the future. I think only the most recent Intel chipsets support H.264 decoding, does your patch work with those? Once there's a stable API for their H.264 decoding I guess the patch works with older (pre-avivo) Radeons and recent i9xx Intel chipsets. Currently I only support antiquated RGB/SCART:-) Though 'durchflieger' of vdr-portal.de also supports H.264 compatible video modes with his own patches. we'll have the best of both worlds :-). right! It's nice to see how HDTV finally finds its way to Linux without expensive extension cards. - Thomas ___ 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)
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 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 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 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
Re: [vdr] RGB/PAL over VGA at variable frame rate
a successor of my vga-sync-fields patch (http://lowbyte.de/vga-sync-fields/) now has been released by 'durchflieger' on 'vdr-portal.de' with far more functionality especially for HDTV related things. please see: http://www.vdr-portal.de/board/thread.php?threadid=80567 - sparkie ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Sat, Sep 27, 2008 at 02:55:31PM +, Bruno wrote: Not at all. Because it?s a good motivation to learn one more language :) the primary intention of the patch was not a German language lesson I think:) the patch itself is written in C and the README is in English. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] vga-sync-fields 0.0.8
A new version of the patch 'vga-sync-fields-0.0.8.tgz' now is available at: http://lowbyte.de/vga-sync-fields History since last version announced here: 2008-09-08: Version 0.0.8 - enhanced a standalone tool for testing the Soft-PLL without xine-lib and Xserver - a fix in xineliboutput configuration (see README) greatly improved responsiveness of Soft-PLL to channel switches - implemented a workaround for sporadically lost interrupts on Radeon type hardware - added experimental DRM and tools support for i810. I just started the port from Radeon to i810. It's not yet documented and far from complete 2008-08-23: Version 0.0.7 - added a small patch for recent hg xine-lib (1.1.16) from 2008-08-20. Together with the patch the actual xine-lib gives good results for playback and live-TV. 2008-08-21: Version 0.0.6 - fixed a bug that erroneously could trigger recovery actions as if stray updates would have been occurred - since 40ms enhancement (see below) issues with DVB budget cards are considered as fixed. You now also can watch live-TV with the patch. But the time to switch a channel still should be optimized. It sometimes takes too long for the Soft-PLL to lock. 2008-08-19: Version 0.0.5 - frame rate now adapted every 1/25 second instead of only once per second as before. This should make rate adaptions invisible even if they change by large values - implemented a simple graphic which should give you a better overview of how regularly frame updates are issued from your decoder. And how the Soft-PLL copes with these updates - automatic sync of initial field polarity now has been removed. It's now part of 40ms double buffer update improvement (see vers. 0.0.4) - simplified/changed interface to DRM-module - adapted all tools to new interface have fun! Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PCI fun (RGB/PAL over VGA at variable frame rate)
On Wed, Aug 27, 2008 at 03:08:14PM +0200, Theunis Potgieter wrote: I found this to be useful for me, however I'm using [EMAIL PROTECTED] and not NTSC colour encoding. http://www.linuxis.us/linux/media/howto/linux-htpc/video_card_configuration.html Nice background information. Right - some nice info. But the vga-sync-fields patch now voids some statements. It's no longer true that softdecoders must sync to the graphics card. In our case it's the other way round. As it should be. The patch of course is for [EMAIL PROTECTED] though NTSC should also be possible. In the meantime I issued a few more releases of the vga-sync-fields patch. Version vga-sync-fields-0.0.7 together with xineliboutput Version 1.0.1 or newer and parameter setting xineliboutput.Advanced.LiveModeSync = 0 give very good results for both viewing recordings and Live-TV. The system is already productive here. I will describe the new setup in my next release. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vga-sync-fields 0.0.4
Hi list, A new version of the patch is now available at http://lowbyte.de/vga-sync-fields 2008-08-17: Version 0.0.4 - now widened time window for double buffer updates from 20ms to 40ms. This is done via drm-ioctl() though the chip doesn't provide a native interface for this. - this greatly reduces Soft-PLLs sensitivity to any timing interference - thus we now even can fully enable live-viewing with DVB drivers and a budget card. Though DVB driver timing problems are not yet solved. - changed interface to DRM-module have fun! Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PCI fun (RGB/PAL over VGA at variable frame rate)
On Sun, Aug 17, 2008 at 04:31:58PM +0100, Gavin Hamill wrote: CPU usage rather than userspace. Due to the critical timing nature of the patches, they need to have nearly the whole machine to themselves, the patches are time critical as far as xine itself must time the frames very accurately. Even my old 800Mhz Pentium with AGP-Radeon shows that indeed every 4usecs +-35usecs a frame comes to Xserver's PutImage(). It's by far not neccessary for the patches to work to get frames that accurately but it shows what is possible even on old and slow hardware. On Gavin's machine with PCI DMA problems we instead timed 4usecs +-21000usecs a frame comes to the Xserver's PutImage(). That is way too unstable. I think xine itself also can't cope with that. At least it will show heavy jerkyness. Nonetheless I today released a new version of the patches with 100% lesser sensivity to timing problems (see announcement of today). Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vga-sync-fields 0.0.3
Hi list, the basic function of this patch has already been disussed in thread 'RGB/PAL over VGA at variable frame rate'. A new version of the patch is now available at http://lowbyte.de/vga-sync-fields 2008-08-14: Version 0.0.3 - added a patch that enhances standard radeonfb kernel driver to use your TV-set as a computer monitor. See README for details - added a tool which sweeps up and down the complete frame rate range - explicitly tested a couple of boards with good results, see README - fixed a minor bug during init of PLL have fun! Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Thu, Aug 14, 2008 at 08:50:43AM +0300, Jouni Karvo wrote: your trick is the VGA-SCART cable. I was using the TVout from the card. I have ordered the components for the cable, and I hope I'll be able to solder them together during the weekend. I hope I can then reproduce your success :) ok, I'm sure you will! The picture quality of SCART is way better than TVout. Though there still must be deinterlaced on nVidia. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Wed, Aug 13, 2008 at 09:09:45PM +0100, Gavin Hamill wrote: OK, found a suitable recording, and after a couple of 'play 1 begin' to SVDRP it starts OK. The picture is pretty good, but it still shifts around the screen a bit: that's because PLL encounters very large increments of 'sync point displacement' it must compensate for. We must find the cause where these leaps come from. BTW: If I start a kernel build in the background I get similar effects:) In your case it appears to be the Xserver itself consuming huge amounts of CPU resources for some yet unknown reason (see below). [...] overall compensation: -11 sync point displacement: -685 --+ drift speed:393 | overall compensation: -10 | there is no sync point displacement: 3175 --+ stability drift speed: 8509 | overall compensation: 402 | sync point displacement: 6186 --+ [...] FWIW, the output is not once per second.. there is often a delay of up to 4 seconds before another group of 3 lines is displayed. strange. The output here gets exactly every second directly to the screen. And also is updated every second through 'tail -F /var/log/Xorg.0.log'. I think that could fit to the '40% Xserver-CPU' phenomenon (see below). So, I started looking for other reasons. Whilst X + vdr are running, the Xorg process is taking 40% CPU, with vdr taking 25%. The 'system' CPU usage is 32%, with 16% for user processes. I thought maybe it was using X11 output rather than xv, and thus causing a drain on the system... oh - a very interesting fact. that's different to mine (see my output of top below). Xorg takes only 0.7%(!) CPU on my system. Are there some special patches in ubuntu that causes this? This appears be the root cause of our problem! Does the Xserver poll for some resources not available or something? A value of 40% CPU is way too much. The only process consuming some CPU power should be 'vdr' whilst decoding. Most other processes don't have to do much all over the time. We must dig deeper into that '40% Xserver-CPU' phenomenon! DISPLAY environment variable is set to DISPLAY=:0 ? again a typical Xserver output: sync point displacement:-26 drift speed:-71 overall compensation:-3 sync point displacement:-31 drift speed:100 overall compensation: 2 sync point displacement:-25 drift speed:-57 overall compensation:-2 sync point displacement:-23 drift speed: 12 overall compensation: 0 completed sync point displacement: 24 drift speed: 63 overall compensation: 3 sync point displacement: 6 drift speed:-72 overall compensation:-2 sync point displacement:-10 drift speed:-24 overall compensation:-1 completed sync point displacement: 5 drift speed: 60 overall compensation: 2 while at the same time you get these messages in '/var/log/messages'. You see the correction is only floating a little: kernel: [drm] changed radeon drift trim from 00520101 - 00520105 kernel: [drm] changed radeon drift trim from 00520105 - 00520104 kernel: [drm] changed radeon drift trim from 00520104 - 00520101 kernel: [drm] changed radeon drift trim from 00520101 - 00520103 kernel: [drm] changed radeon drift trim from 00520103 - 00520101 kernel: [drm] changed radeon drift trim from 00520101 - 00520104 kernel: [drm] changed radeon drift trim from 00520104 - 00520102 kernel: [drm] changed radeon drift trim from 00520102 - 00520101 kernel: [drm] changed radeon drift trim from 00520101 - 00520103 at the same time I get following values through 'vmstat 1': procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 349304 11228 10722800 1788 0 286 777 22 1 77 0 0 0 0 349296 11228 10721600 0 0 294 787 22 0 78 0 0 0 0 347364 11232 10901200 1804 0 299 780 22 2 76 0 0 0 0 347364 11232 10902400 0 0 281 767 23 1 76 0 0 0 0 345572 11232 11082400 1796 0 300 782 24 0 76 0 0 0 0 345564 11240 11082000 072 295 799 24 1 75 0 0 0 0 343896 11240 11259600 1800 0 294 781 24 1 75 0 0 0 0 343896 11240 11259600 0 0 287 776 25 0 75 0 0 0 0 342104 11240 11439600 1808 0 293 781 24 2 74 0 0 0 0 342096 11240 11440400 020 291 780 26 1 73 0 0 0 0 340304 11248 11619600 180056 307 779 25 1 74 0 0 0 0 340296 11248 11620400 0 0
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Thu, Aug 14, 2008 at 01:15:58PM +0300, Petri Hintukainen wrote: to, 2008-08-14 kello 11:25 +0200, Thomas Hilber kirjoitti: Does the Xserver poll for some resources not available or something? Maybe the driver is waiting for free overlay buffer ? Some drivers wait for free hardware overlay buffer in simple busy loop. a good idea, but in the case of 'xserver-xorg-video-ati' true hardware double buffers are supported. If a new PutImage() comes in the DDX simply toggles to the other double buffer and starts to write there. No matter this buffer ever has been completely read by CRT controller. So there is no mechanism waiting here for something as far as I can see. Usually this can be seen only when video player draws Xv frames faster than the actual output rate (ex. displaying 50p video with 50p display mode). To see the effect in practice I just set the VGA frame rate to several values slightly below 50Hz (i.e. in the range 49.94 - 49.99HZ). Applying all these 'low' frame rates lead to dropped fields as expected. But Xserver %CPU always stays around 2%CPU maximum. The only exception here is if I press the 'OK' button. The OSD 'time-shift' bar showing up then costs about 16%CPU. Strangely enough if I open the 'recordings' OSD which covers almost the entire screen this takes only about 6%CPU. BTW: my xineliboutput OSD setup is as follows: xineliboutput.OSD.AlphaCorrection = 0 xineliboutput.OSD.AlphaCorrectionAbs = 0 xineliboutput.OSD.Downscale = 1 xineliboutput.OSD.ExtSubSize = -1 xineliboutput.OSD.HideMainMenu = 0 xineliboutput.OSD.LayersVisible = 0 xineliboutput.OSD.Prescale = 1 xineliboutput.OSD.SpuAutoSelect = 0 xineliboutput.OSD.UnscaledAlways = 0 xineliboutput.OSD.UnscaledLowRes = 0 xineliboutput.OSD.UnscaledOpaque = 0 But anyway all these values still are in the 'green area' and are compensated by the patch. A value of 40%CPU as Gavin posted above I never could reproduce on my system. There must be broken something. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Thu, Aug 14, 2008 at 10:22:53PM +1000, Torgeir Veimo wrote: Since you're using the vsync irq in any case, the best solution would be to notify user space at irq time that it should 'PutImage' a new frame. I know what you want to say. But according to my understanding xine has it's own heart beat and from this and stream PTS and some other parameters there is finally derived the rate the images are put to the Xserver. I consider this rate as an 'ideal' rate i.e. free from any hardware contraints. I really don't want to change that. Rather I try my best to program the hardware as close as possible to xines 'ideal' rate. That's the main intention of the patch. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Thu, Aug 14, 2008 at 02:22:46PM +0100, Gavin Hamill wrote: [1] [EMAIL PROTECTED]:~# apt-get install xserver-xorg xserver-xorg-core The following packages have unmet dependencies. xserver-xorg: Depends: x11-xkb-utils but it is not going to be installed PreDepends: x11-common (= 1:7.3+3) but it is not going to be installed xserver-xorg-core: Depends: libfontenc1 but it is not going to be installed Depends: libxau6 but it is not going to be installed Depends: libxdmcp6 but it is not going to be installed Depends: libxfont1 (= 1:1.2.9) but it is not going to be installed Depends: x11-common (= 1:7.0.0) but it is not going to be installed All the Depends: packages are /already/ installed and meet those version requirements! may be a forced purge/uninstall and reinstall of consistent Debian packages would help? Are you suggesting to provide a tarball that I can 'tar xzf' into a freshly-formatted root partition (then run grub) ? right. I would prepare it the next hours leave you a message with the URL where to download. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, Aug 12, 2008 at 10:44:37PM +0100, Gavin Hamill wrote: I have a system not dissimilar to yours.. it's a P3-1GHz with PCI Radeon 7000. OS is Ubuntu hardy with the patches from your 0.0.2 release. ok Now that I've got the patches in place, I get a stable desktop display on the TV. good If I start vdr / xineliboutput, the picture will be Ok for a second.. then it'll move up and down (like camera wobble, but it moves the onscreen logos / VDR menus, too!). I guess it's because it wants to resync the inital field polarity. I see this kind of thing at least once per second : [ 2706.402871] [drm] changed radeon drift trim from 00520125 - 0052018c right. The lowest byte 8c confirms my assumption about field polarity. If I quit vdr (leaving X running), and run the 'drift_control' tool, I see a drift speed of approx -3900 for 4 seconds, then +16000 marked 'excessive drift speed' I think it is the best to gradually step forward. Could you please do the following and report the results. To be on the safe side I just repeated all steps myself with reproducible results: 1. for the moment please encomment both in 'radeon_video.c' and 'drift_control' //#define RESYNC_FIELD_POLARITY_METHOD1 //#define RESYNC_FIELD_POLARITY_METHOD2 because this must clearly be fixed in xine. Though it works in my current configuration. Maybe we can reenable it later. 2. start the Xserver (but still without vdr) 3. run 'drift_control a' this should give you typically an output like this: # drift_control a tv now: 1218633290.553468 tv vbl: 1218633290.538542 vbls: 43163 trim:0x00520100 sync point displacement: 9871 drift speed:-19 overall compensation: 339 o. c. clipped: 339 trim absolute: 339 t. a. clipped: 37 new trim:0x80520125 tv now: 1218633291.553497 tv vbl: 1218633291.539525 vbls: 43213 trim:0x00520125 sync point displacement: 3972 drift speed: -954 overall compensation: 104 o. c. clipped: 104 trim absolute: 141 t. a. clipped: 37 new trim:0x80520125 tv now: 1218633292.553471 tv vbl: 1218633292.540529 vbls: 43263 trim:0x00520125 sync point displacement: 2942 drift speed: -1030 overall compensation:65 o. c. clipped: 65 trim absolute: 102 t. a. clipped: 37 new trim:0x80520125 tv now: 1218633293.553429 tv vbl: 1218633293.541534 vbls: 43313 trim:0x00520125 sync point displacement: 1895 drift speed: -1047 overall compensation:29 o. c. clipped: 29 trim absolute: 66 t. a. clipped: 37 new trim:0x80520125 tv now: 1218633294.553387 tv vbl: 1218633294.542539 vbls: 43363 trim:0x00520125 sync point displacement:848 drift speed: -1047 overall compensation:-6 o. c. clipped: -6 trim absolute: 31 t. a. clipped: 31 new trim:0x8052011f tv now: 1218633295.553358 tv vbl: 1218633295.543374 vbls: 43413 trim:0x0052011f sync point displacement:-16 drift speed: -864 overall compensation: -30 o. c. clipped: -30 trim absolute:1 t. a. clipped:1 new trim:0x80520101 tv now: 1218633296.553329 tv vbl: 1218633296.543358 vbls: 43463 trim:0x00520101 sync point displacement:-29 drift speed:-13 overall compensation:-1 completed o. c. clipped: -1 trim absolute:0 t. a. clipped:0 new trim:0x80520100 tv now: 1218633297.553298 tv vbl: 1218633297.543296 vbls: 43513 trim:0x00520100 sync point displacement: 2 drift speed: 31 overall compensation: 1 completed o. c. clipped:1 trim absolute:1 t. a. clipped:1 new trim:0x80520101 tv now: 1218633298.553269 tv vbl: 1218633298.543262 vbls: 43563 trim:0x00520101 sync point displacement: 7 drift speed: 5 overall compensation: 0
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Wed, Aug 13, 2008 at 12:03:23AM +0400, Goga777 wrote: does your project actually fro dvb 720p channels too ? 720p is 1280x720. At least the part that does the frame rate sync VGA-DVB can be recycled for this. and I have may be stupid question - why frame rate from satellites is not stable ? is it 50i ? real life systems don't work 100% perfect in mathematical sense. That's why we must find a way how to compensate for aberrations. BTW that's exactly how a FF-card it also does. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Wed, Aug 13, 2008 at 04:21:25PM +0100, Gavin Hamill wrote: overall comp floats -1 to 2, but sync point floats -44 to +45, and drift speed floats -40 to +40. ta absolute + clipped are 5 - 7. I find that's pretty good. Same values here. it odd that my 'vbls' value is 15500 when yours is 43000.. no - that's also ok! vbls continuously counts vbl interrupts since Xserver start. Next time you restart you will have again a completely different offset. 4. stop drift_control 5. unload all dvb modules (there are known issues with some) I forgot to mention this before - I'm not using any dvb modules - I'm using the streamdev-client to source live TV via HTTP from my live VDR box. ok. There still is left to do a lot of things until the patch is working on all possible configurations. Sorry - I for now only can speak for my own (simple) configuration. I'll have to wait until I can be in front of the machine to try the other tests.. will follow-up then. Many thanks for your time and effort :) thank you for testing:-) Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, Aug 12, 2008 at 04:44:59PM +0300, Pasi Kärkkäinen wrote: that made me wonder if it would be possible to make these patches friendly enough to get them accepted upstream :) sorry - but I really can't care about this at the current state of development ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, Aug 12, 2008 at 10:29:53AM +0200, Theunis Potgieter wrote: Does somebody have a URL on how to make one? for d-sub to scart or the new DVI (modern graphic cards) to scart? my favorite cable works with all graphics cards supporting RGB. I don't think it's too complex:) you find it in the 'README' of my packages at: http://lowbyte.de/vga-sync-fields or here: == circuit diagram of my favorite VGA-to-SCART adaptor: VGASCART 1 -O--O- 15 R 2 -O--O- 11 G 3 -O--O- 7 B 6 -O---+--O- 13 R Gnd 7 -O---+--O- 9 G Gnd 8 -O---+--O- 5 B Gnd 10 -O---+--O- 17 Gnd +--O- 14 Gnd +--O- 18 Gnd -- 9 -O-| 75R |-O- 16 -- -VS 14 -O---+ | | / --|C -HS 13 -O-| 680R |-B-| BC 547 B --|E | \ | -- +--| 680R |O- 20 -CS -- shell-O--O- 21 shell == Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Sat, Aug 09, 2008 at 11:26:21PM +0400, Goga777 wrote: does your idea actually for new generation cards - ATI HD series, Intel G35/45 chipsets with hdmi output ? currently it does for everything pre-avivo (e.g. before r500 with the exception of rs690 which is a r300-style 3d core but 2d is avivo). I not yet tried with ATI HD or Intel G35/45. Basically I don't see a problem. The devil is in the details:) To ease the port to other graphics hardware I did not use special pre-avivo registers in my current solution. The idea comprises several aspects: The most important feature is to synchronize video output with the stream. Nobody cared about that until today. I do not understand that at all. It just a pleasant by-product of the sync that in some cases you need not to deinterlace anymore. Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Fri, Aug 08, 2008 at 09:23:34PM +0100, Gavin Hamill wrote: Finally I have had a chance to try these patches - I managed to get an old Radeon 7000 PCI (RV100)... nice! I am using a fresh bare install of Ubuntu hardy which ships xine-lib 1.1.11, but the patches don't compile :( The Makefile.am changed a little but I was able to amend that manually, but the video_out_xv.c spews out this: video_out_xv.c: In function ???xv_update_frame_format???: [...] In the meantime I reworked everything from scratch. A patch currently is only applied against radeon-DRM and xserver-xorg-video-ati. Xine library isn't touched any more though this will change in the future. Latest version of the patch is available 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] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, Jul 22, 2008 at 11:17:26PM +0200, Thomas Hilber wrote: Unfortunately with Radeons we currently have 2 problems unsolved: 1. there appears to be a tiny bug in XV overlay scaling code which sometimes mixes even and odd fields at certain resolutions. A workaround to compensate for this is to scale the opposite way. This is done by xineliboutput option 'Fullscreen mode: no, Window height: 575 px' instead of 'Window height: 575 px' (as noted in my configuration example). Overlay XV uses double buffering eliminating any tearing effects. This works pretty good. 2. the other way to use XV video extension is textured mode. This method shows very good results. No scaling problems at all. But this code is so new (a few weeks), there even does not yet exist proper tearing protection for. the first issue has been fixed yesterday! The second one is void then. Thanks to Roland Scheidegger I now get a perfect picture for all source resolutions testet so far. http://lists.x.org/archives/xorg-driver-ati/2008-July/006143.html http://www.vdr-portal.de/board/thread.php?postid=741778#post741778 There currently is only one known issue left: detection of inital field polarity. I don't think this is a big deal. After this I can start productive use of the patch on my living room VDR. Maybe then I find some time to port the patch to other platforms (like intel based graphics cards). Cheers Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, Jul 29, 2008 at 01:40:49PM +0300, Pasi Kärkkäinen wrote: Maybe then I find some time to port the patch to other platforms (like intel based graphics cards). That would rock. maybe this way we could fix current issues with S100. Picture quality dramaticly improves if deinterlacer is switched off. Anyway they made a big step forward these days: http://forum.zenega-user.de/viewtopic.php?f=17t=5440start=15#p43241 btw any chance of getting these patches accepted/integrated upstream? I don't think we get upstream support in the near future. Since TV applications are the only ones that need to synchronize VGA timing to an external signal. -Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Sun, Jul 27, 2008 at 03:53:01PM +0300, Pasi Kärkkäinen wrote: Is it possible to output WSS signal from a VGA card to switch between 4:3 and 16:9 modes? http://www.intersil.com/data/an/an9716.pdf it should be possible to emulate WSS by white dots/lines in a specific scanline. But I did not try this myself yet. BTW: I'm currently experimenting with DirectFB instead of Xorg. Their Radeon driver code does not show the 'Xorg overlay scaling bug' from above. So I could either stick to DirectFB for the moment. Or I could try with help of their code to identify the part of Xorg that caused the bug. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Wed, Jul 23, 2008 at 12:12:46AM +0200, Martin Emrich wrote: I have connected my VDR box to my TV via a DVI-to-HDMI cable, set the resolution to 1920x1080 and let the graphics card do the upscaling instead of the TV, because the quality looks IMHO better this way. But ok. But if doing so you still have to continue deinterlacing in software. This is because any scaling in Y dimension intermixes even/odd fields in the frame buffer. Finally producing a totally messed VGA output signal. Scaling in X dimension however is always allowed. E.g. for switching between 4:3/16:9 formats on a 16:9 TV-set. here still the same problem is present, the refresh rate of the graphics card is not bound to the field rate of the incoming TV signal, so I can either disable sync-to-vblank and have tearing artefacts or enable it and have an unsteady framerate. right. Even if you still must use software deinterlacing for some reason you benefit from the 'sync_fields' patch. You then can enable sync-to-vblank and the patch dynamically synchronizes graphics card's vblanks and TV signal's field updates. Thus avoiding unsteady frame rates at VGA/DVI/HDMI output. I wonder if your patch could be applied to a DVI/HDMI connection, too? Its a Radeon X850 currently with xf86-video-ati 6.6.3 and xorg-server 1.4. In your case the only prerequisite is support of your Radeon X850 by Radeon DRM driver. DRM normally is shipped with kernel. So this is a kernel/driver issue. But I don't expect problems here though I not yet testet the X850 myself (yet). -Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Tue, Jul 22, 2008 at 11:51:13PM +0300, Pasi Kärkkäinen wrote: A bit off topic.. Does any of the video players for Linux switch to a resolution/modeline with a different refresh rate when watching a movie to get perfect synchronization and no tearing? some time ago I accidentally stumbled across these options in my outdated xineliboutput version: xineliboutput.VideoModeSwitching = 1 xineliboutput.Modeline = maybe these are intended for this purpose? I didn't care yet. An example.. your desktop might be at 70 hz refresh rate in normal use (ok, maybe it's 60 hz nowadays with LCD displays), and when you start watching PAL TV it would be better to have your display at 50 hz or 100 hz to get perfect output.. and then, when you start seeing a 24 fps movie, it would be best to have your display in 72 hz mode (3*24).. etc. http://en.wikipedia.org/wiki/XRandR is what you are looking for. At least when talking about Xservers with that capability. Don't know how well it's supported by today's VDR output plugins. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
Hi, On Wed, Jul 23, 2008 at 06:04:29PM +1000, Torgeir Veimo wrote: Your approach is very interesting, I myself have seen the problems that clock drift has on judder when using softdevice with vdr. yes, that's also my experience with certain xineliboutput - xine-lib version combinations. I also experienced that certain DVB drivers sporadically stall the system for inadmissible long period of time. My current configuration however outputs fields *very* regularly at least when doing playback. That's why I currently don't want to update any of these components. Issues with judder are not so noticeable under more common operating conditions. Maybe that's why developers of softdecoder components are not always aware of problems in this area. But with deinterlacing deactivated irregularities are mercilessly exposed. Because after each dropped field subsequent fields are replayed swapped:) A measurement protocol showing you how regularly frames drip in with my current configuration can be found here http://www.vdr-portal.de/board/attachment.php?attachmentid=19208 attached to that post: http://www.vdr-portal.de/board/thread.php?postid=737687#post737687 legend: vbl_received - count of VBLANK interrupts since Xserver start vbl_since - time in usecs since last VBLANK interrupt vbl_now - time (only usec part) when ioctl has been called vbl_trim - trim value currently configured some explanations: vbl_received is incremented by two each line because 2 VBLANK interrupts (== fields) are received each frame. vbl_since is constantly incremented by drift between VBLANK timing based clock and xine-lib's call to PutImage() (effectively stream timestamps). After reaching a programmed level of about vbl_since == 11763 (for this particular example) vbl_trim starts to oscillate between the two values 0 and 200 (only a sample). Representing the two active Xserver modelines. This is only for simplicity. We could also program a much finer grading if desired. We are not limited to 2 modelines. when vbl_trim starts to oscillate Xserver's video timing is fully synchronized with the stream. interesting is minimal judder of vbl_now. It's incremented very regularly by a value very close to 4usec each call. BTW: The measurement took place in the Xserver (at the place where double buffers are switched) not at the patch in xine-lib. Thus comprising all latencies in the data path between xine-lib and Xserver. And even though there are effectively no stray values. I can look a football recording for about 20 minutes (my test material) without any field loss. Have you considered applying your approach to DirectFB? There's a radeon driver which is not too hard to change, it also has a kernel module which could be augmented by using an ioctl command. not yet but it sounds very interesting! Unfortunately I'm not on holiday and can't spend too much time for this project. Though I dedicate each free minute to it:) In addition, you might want to try out your approach with a matrox G550 card. These have field perfect interlaced output using DirectFB, so you'd have that part of the problem solved already. right, a very good idea! You mean AGP G550? I almost forgot there are laying 2 of these boards somewhere around here. Cheers, Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Wed, Jul 23, 2008 at 09:20:08AM +0100, Laz wrote: that the only cards that could be convinced to sync at such low rates, i.e. 50 Hz for PAL, were the Matrox G400, G450, etc. Whenever I tried setting modelines with any other cards, I never got any output or an error when starting X. also Radeons need a special 'invitation' for this by specifying: Option ForceMinDotClock 12MHz I take it that more modern cards are a lot more flexible in this respect! maybe. nVidia cards I tested so far work without special problems. But I've heard that only the closed source driver as capable of 50 Hz for PAL. I did't test myself the open source driver with that low frequency. I hope one day the Nouveau project could give us enough support for PAL on nVidia with adequate drivers. I'm currently using a G450 with softdevice connected to a CRT TV and it works pretty well most of the time with the odd flicker due to dodgy sync every now and than. maybe you can convince the softdevice developers to give the patch a try:) Using hardware to do the deinterlacing is _definitely_ the way forward, for displaying interlaced content it's always the best to use a display with native interlace capabilities. So nobody has to deinterlace at all. You just route the plain fields straight through to the hardware. especially for CRT. (Not sure whether LCDs display an interlaced streame properly or whether they try to interpolate somehow and refresh I've heard modern LCDs do a pretty good job interpreting a conventional PAL signal. At the expense of huge amount of signal processing circuitry. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Wed, Jul 23, 2008 at 05:05:21PM +0300, Pasi Kärkkäinen wrote: I assume RGB NTSC should work as well.. ? basically yes. The devil is in the details:) Just give it a try. When xine-lib calls PutImage() it checks whether to increase/decrease Xservers frame rate. This way after a short adaption phase xine-lib can place it's PutImage() calls right in the middle between 2 adjacent vertical blanking intervals. This provides maximum immunity against jitter. And even better: no more frames/fields are lost due to stream and graphics card frequency drift. Hmm.. can you explain what increase/decrease Xservers frame rate means? you simply adjust the time between two vertical blanking (retrace) intervals to your needs. This is done by lengthening/shortening scan lines that are not visible on the screen. Because they are hidden within the vertical blanking interval. I don't really know how xserver or display drivers work nowadays, but back in the days when I was coding graphics stuff in plain assembly (in MSDOS) I always did this to get perfect synchronized output without any tearing: 1. Render frame to a (double) buffer in memory 2. Wait for vertical retrace to begin (beam moving from bottom of the screen to top) 3. Copy the double buffer to display adapter framebuffer 4. Goto 1 that's very similar to the way a Radeon handles this when overlay method is choosen for XV extension: 1. the Xserver writes the incoming frame to one of its 2 buffers. Strictly alternating between the two. 2. the CRT controller sequentially reads the even than the odd (or the other way round dependend on the start condition) field out of the buffer. And then switches to the next buffer. Also strictly alternating between the two. You just have to take care that data is written the right sequence to the double buffers. So it is always read the correct sequence by the CRT controller. So the video adapter framebuffer was always filled with a full new frame right before it was visible to the monitor.. the same here. Otherwise the CRT controller would reuse already shown data. So I guess the question is can't you do the same nowadays.. lock the PutImage() to vsync? exactly. The patch tries hard to do this:) But to put it in your words: It's only a 'soft' lock. Loading the machine too much can cause problems. -Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] RGB/PAL over VGA at variable frame rate
Hi list, the last few days I made some interesting experiences with VGA cards I now want to share with you. goal develop a budget card based VDR with PAL/RGB output and FF like output quality problem --- as we all know current VGA graphics output quality suffers from certain limitations. Graphics cards known so far operate at a fixed frame rate not properly synchronized with the stream. Thus fields or even frames do often not appear the right time at the ouput. Some are doubled others are lost. Finally leading to more or less jerky playback. To a certain degree you can workaround this by software deinterlacing. At the cost of worse picture quality when playing interlaced material. Also CPU load is considerably increased by that. It appeared to be a privilege of so called full featured cards (expensive cards running proprietary firmware) to output true RGB PAL at variable framerate. Thus always providing full stream synchronicity. I've always been bothered by that and finally started to develop a few patches with the goal in mind to overcome these VGA graphics limitations. solution graphics cards basically are not designed for variable frame rates. Once you have setup their timing you are not provided any means like registers to synchronize the frame rate with external timers. But that's exactly what's needed for signal output to stay in sync with the frame rate provided by xine-lib or other software decoders. To extend/reduce the overall time between vertical retrace I first dynamically added/removed a few scanlines to the modeline but with bad results. By doing so the picture was visibly jumping on the TV set. After some further experimenting I finally found a solution to fine adjust the frame rate of my elderly Radeon type card. This time without any bad side effects on the screen. Just trimming the length of a few scanlines during vertical retrace period does the trick. Then I tried to implement the new functionality by applying only minimum changes to my current VDR development system. Radeon DRM driver is perfectly suited for that. I just had to add a few lines of code there. I finally ended up in a small patch against Radeon DRM driver and a even smaller one against xine-lib. The last one also could take place directly in the Xserver. Please see attachments for code samples. When xine-lib calls PutImage() it checks whether to increase/decrease Xservers frame rate. This way after a short adaption phase xine-lib can place it's PutImage() calls right in the middle between 2 adjacent vertical blanking intervals. This provides maximum immunity against jitter. And even better: no more frames/fields are lost due to stream and graphics card frequency drift. Because we now cease from any deinterlacing we enjoy discontinuation of all its disadvantages: If driving a device with native interlaced input (e.g. a traditional TV Set or modern TFT with good RGB support) we have no deinterlacing artifacts anymore. Since softdecoders now are relieved of any CPU intensive deinterlacing we now can build cheap budget card based VDRs with slow CPUs. Please find attached 2 small patches showing you the basic idea and a description of my test environment. The project is far from complete but even at this early stage of development shows promising results. It should give you some rough ideas how to recycle your old hardware to a smoothly running budget VDR with high quality RGB video output. some suggestions what to do next: - detection of initial field parity - faster initial frame rate synchronisation after starting replay - remove some hard coded constants (special dependencies on my system's timing) Some more information about the project is also available here http://www.vdr-portal.de/board/thread.php?threadid=78480 Currently it's all based on Radeons but I'll try to also port it to other type of VGA cards. There will be some updates in the near future. stay tuned. -Thomas diff -ru xine-lib.org/src/video_out/Makefile.am xine-lib/src/video_out/Makefile.am --- xine-lib.org/src/video_out/Makefile.am 2007-08-29 21:56:36.0 +0200 +++ xine-lib/src/video_out/Makefile.am 2008-07-11 16:29:26.0 +0200 @@ -116,7 +116,7 @@ xineplug_vo_out_xshm_la_CFLAGS = $(VISIBILITY_FLAG) $(X_CFLAGS) $(MLIB_CFLAGS) -fno-strict-aliasing xineplug_vo_out_xv_la_SOURCES = $(X11OSD) deinterlace.c video_out_xv.c -xineplug_vo_out_xv_la_LIBADD = $(XV_LIBS) $(X_LIBS) $(XINE_LIB) $(PTHREAD_LIBS) $(LTLIBINTL) +xineplug_vo_out_xv_la_LIBADD = $(XV_LIBS) $(X_LIBS) $(XINE_LIB) $(PTHREAD_LIBS) $(LTLIBINTL) -ldrm xineplug_vo_out_xv_la_CFLAGS = $(VISIBILITY_FLAG) $(X_CFLAGS) $(XV_CFLAGS) -fno-strict-aliasing xineplug_vo_out_xvmc_la_SOURCES = deinterlace.c video_out_xvmc.c diff -ru xine-lib.org/src/video_out/video_out_xv.c xine-lib/src/video_out/video_out_xv.c --- xine-lib.org/src/video_out/video_out_xv.c 2008-02-07 18:03:12.0 +0100 +++
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, Jul 22, 2008 at 07:12:35PM +0100, Gavin Hamill wrote: In the inevitable shift towards HDTV and progressive scanning, I was becoming increasingly concerned that the countless hours of interlaced content would be forgotten in the scramble for new and shiny. not to forget interlaced formats are still in effect for HDTV. I think you could recycle the basic idea behind my patch for HDTV as well. Indeed, my own VDR FF based system exists in a large desktop PC case only because of the enormous (and antiquated) FF card. This project leads the way for replacing it with something much more compact, since the card runs hot and it's only a matter of time before it dies. that originally was one of my major motivations. I don't like a huge VDR box with a FF card in my living room. At least Radeons are also available in low profile format. So are some budget satellite cards. I hope one day we also could support some on-board graphics (like nVidia or Intel) what would allow tiny VDR boxes with very common hardware. Is it likely to work with any newer Radeons, or is it because the RV2xx series is the last to have useful full open source drivers? I have a couple of RV3xxs (Radeon X300 + X600 Pro) I'd love to try this with :) the patch from above basically should run with all cards supported by the xf86-video-ati driver. Just have a look at one of the more recent man pages: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/tree/man/radeon.man?h=vsync_accel Unfortunately with Radeons we currently have 2 problems unsolved: 1. there appears to be a tiny bug in XV overlay scaling code which sometimes mixes even and odd fields at certain resolutions. A workaround to compensate for this is to scale the opposite way. This is done by xineliboutput option 'Fullscreen mode: no, Window height: 575 px' instead of 'Window height: 575 px' (as noted in my configuration example). Overlay XV uses double buffering eliminating any tearing effects. This works pretty good. 2. the other way to use XV video extension is textured mode. This method shows very good results. No scaling problems at all. But this code is so new (a few weeks), there even does not yet exist proper tearing protection for. So for demonstration purposes I still prefer the overlay instead of textured XV adaptor. Apparently, some hardware doesn't support interlaced mode. If you have sync problems, check the sync signal with an oscilloscope. but we are on the safe side. Radeons do support it:) In fact, my biggest problem with this project before now has been the manufacture of such an adapter - my soldering skills are beyond poor. just recycle a conventional VGA monitor cable. So you just have to fiddle with the SCART side of the cable. I don't suppose you'd be willing to make some VGA - SCART hobby-boxes up for a suitable fee? :) at least this was not my primary intention:) Cheers, Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Tue, Jul 22, 2008 at 08:30:46PM +0200, Theunis Potgieter wrote: currently I'm still using a pentium 4, 2.4GHz machine with nvidia AGP 440MX card, at least the VGA-to-SCART cable (not yet the patch itself) does run here on nVidia hardware without problems. Box is a PUNDIT P1-AH2 with nVidia C51PV [GeForce 6150] graphics. only way to get that to work properly was with the older nvidia drivers 71.86.0 , apparently the newer drivers forces PAL or any other TV Standard to run @60Hz instead of 50Hz, which is what my broadcast is. So I had to downgrade the driver to get the proper output. really? On my Pundit I use NVIDIA-Linux-x86-100.14.19-pkg1.run and the attached xorg.conf with no problems. Option UseEDIDFreqs FALSE Option UseEDIDDpi FALSE I just use one big hammer instead:) Option UseEDID FALSE That works (mostly). -Thomas Section ServerLayout Identifier Default Layout Screen Default Screen 0 0 InputDeviceGeneric Keyboard InputDeviceConfigured Mouse Option BlankTime 0 Option StandbyTime 0 Option SuspendTime 0 Option OffTime 0 EndSection Section Files FontPath/usr/share/fonts/X11/misc EndSection Section Module Load i2c Load bitmap Load ddc Load extmod Load freetype #Load glx Load int10 Load vbe EndSection Section ServerFlags Option AllowMouseOpenFail on EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device /dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true EndSection Section Monitor Identifier Generic Monitor Option DPMS HorizSync 15-16 Modeline 720x576i 13.875 720 744 808 888 576 580 585 625 -HSync -Vsync interlace# pundit p1 --_---_-- EndSection Section Device Option UseEDID FALSE Option UseEvents True Option NoLogo True Identifier Generic Video Card Driver nvidia EndSection Section Screen Identifier Default Screen Device Generic Video Card MonitorGeneric Monitor DefaultDepth 24 SubSection Display Depth 24 Modes 720x576i #RGB EndSubSection EndSection ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
