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 08:35:23AM +0200, Thomas Hilber wrote: 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 Too bad the text is not english :( -- Pasi ___ 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
please see: http://www.vdr-portal.de/board/thread.php?threadid=80567 Too bad the text is not english :( Not at all. Because it’s a good motivation to learn one more language :) _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx ___ 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
Re: [vdr] RGB/PAL over VGA at variable frame rate
thanks for your answer but for 3d games this problem also actually ? or this issue exists only for video playback ? 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. ___ 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 Thomas does your idea actually for new generation cards - ATI HD series, Intel G35/45 chipsets with hdmi output ? Goga ___ 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 Tue, 2008-07-22 at 18:37 +0200, Thomas Hilber wrote: Hi list, Finally I have had a chance to try these patches - I managed to get an old Radeon 7000 PCI (RV100)... 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’: video_out_xv.c:475: warning: pointer targets in assignment differ in signedness video_out_xv.c:481: warning: pointer targets in assignment differ in signedness video_out_xv.c:482: warning: pointer targets in assignment differ in signedness video_out_xv.c:483: warning: pointer targets in assignment differ in signedness video_out_xv.c: In function ‘xv_deinterlace_frame’: video_out_xv.c:538: warning: pointer targets in assignment differ in signedness video_out_xv.c:543: warning: pointer targets in passing argument 1 of ‘deinterlace_yuv’ differ in signedness video_out_xv.c:547: warning: pointer targets in assignment differ in signedness video_out_xv.c:552: warning: pointer targets in passing argument 1 of ‘deinterlace_yuv’ differ in signedness video_out_xv.c:566: warning: pointer targets in assignment differ in signedness video_out_xv.c:571: warning: pointer targets in passing argument 1 of ‘deinterlace_yuv’ differ in signedness video_out_xv.c:582: warning: pointer targets in assignment differ in signedness video_out_xv.c:583: warning: pointer targets in assignment differ in signedness video_out_xv.c:590: warning: pointer targets in assignment differ in signedness video_out_xv.c:591: warning: pointer targets in assignment differ in signedness video_out_xv.c:598: warning: pointer targets in assignment differ in signedness video_out_xv.c:599: warning: pointer targets in assignment differ in signedness video_out_xv.c: In function ‘xv_display_frame’: video_out_xv.c:845: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘vsync’ video_out_xv.c:845: error: ‘vsync’ undeclared (first use in this function) video_out_xv.c:845: error: (Each undeclared identifier is reported only once video_out_xv.c:845: error: for each function it appears in.) video_out_xv.c:853: error: ‘RADEON_SETPARAM_VBLANK_CRTC’ undeclared (first use in this function) video_out_xv.c:854: error: ‘DRM_RADEON_VBLANK_CRTC1’ undeclared (first use in this function) video_out_xv.c:859: error: ‘DRM_IOCTL_RADEON_VSYNC’ undeclared (first use in this function) video_out_xv.c: In function ‘open_plugin_2’: video_out_xv.c:1769: warning: passing argument 4 of ‘config-register_enum’ from incompatible pointer type make[4]: *** [xineplug_vo_out_xv_la-video_out_xv.lo] I'm no coder so I don't know what I'm looking for.. any advice would be warmly welcomed! Cheers, Gavin. ___ 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] RGB/PAL over VGA at variable frame rate
On Tue, Jul 22, 2008 at 06:37:05PM +0200, Thomas Hilber wrote: goal develop a budget card based VDR with PAL/RGB output and FF like output quality VGA-to-SCART RGB adapter like this: http://www.sput.nl/hardware/tv-x.html Hi again! One more question.. 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 -- Pasi ___ 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] RGB/PAL over VGA at variable frame rate
On Wed, Jul 23, 2008 at 09:21:01PM +0200, Thomas Hilber wrote: 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. Hmm.. I still don't understand why you need to do this in the first place? 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. Ok. 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. Does this mean XV extension (or X itself) does not provide a way to wait for retrace out-of-the-box.. and your patch adds that functionality? Sorry for the stupid questions :) -- Pasi ___ 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 23 Jul 2008, at 02:37, Thomas Hilber wrote: To a certain degree you can workaround this by software deinterlacing. After some further experimenting I finally found a solution to fine adjust the frame rate of my elderly Radeon type card. 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 finally ended up in a small patch against Radeon DRM driver and a even smaller one against xine-lib. Your approach is very interesting, I myself have seen the problems that clock drift has on judder when using softdevice with vdr. 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. 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. -- Torgeir Veimo [EMAIL PROTECTED] ___ 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 Tuesday 22 Jul 2008, Thomas Hilber wrote:
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.
{snippage}
Interesting...
I looked at this sort of thing a few years back and came to the conclusion
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.
I take it that more modern cards are a lot more flexible in this respect!
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.
Using hardware to do the deinterlacing is _definitely_ the way forward,
especially for CRT. (Not sure whether LCDs display an interlaced
streame properly or whether they try to interpolate somehow and refresh
the whole screen at once. I'm not buying one until 1. terrestrial is
available in the UK, 2. my current TV dies, 3. there is a solution like
this which utilises older hardware!).
Looks interesting...
Cheers,
Laz
___
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
On Wed, Jul 23, 2008 at 03:09:29PM +0200, Thomas Hilber wrote: 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. Ok. Sounds like it.. although xineliboutput.Modeline sounds a bit like it only wants to change to one specific modeline.. 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. Thanks. I knew new xservers are able to change resolution/modeline on the fly nowadays.. but didn't remember it was XRandR extension doing it :) -- Pasi ___ 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 06:37:05PM +0200, Thomas Hilber wrote: 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 assume RGB NTSC should work as well.. ? I live in Europe so PAL is the thing for me, but sometimes you have video in NTSC too.. 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. snip 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? 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 So the video adapter framebuffer was always filled with a full new frame right before it was visible to the monitor.. This way you always got full framerate, smooth video, no tearing.. as long as your rendering took less than duration of a single frame :) So I guess the question is can't you do the same nowadays.. lock the PutImage() to vsync? -- Pasi ___ 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] RGB/PAL over VGA at variable frame rate
On Tue, Jul 22, 2008 at 06:37:05PM +0200, Thomas Hilber wrote: 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. Hi and thanks for starting this project! I'm a dxr3 user myself, but of course it would be nice to get good output quality without extra hardware! :) 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. variable framerate.. I tend to watch interlaced PAL streams (50 hz), PAL DVD's and NTSC DVD's.. It would be great to get perfect output for all of these :) 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? 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. -- Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
