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

Pasi Kärkkäinen pasik at iki.fi
Thu Jul 24 12:49:18 CEST 2008


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



More information about the vdr mailing list