[vdr] RGB/PAL over VGA at variable frame rate

Thomas Hilber vdr at toh.cx
Wed Jul 23 21:21:01 CEST 2008


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



More information about the vdr mailing list