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

[Thomas Hilber]

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 40000usec 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