[vdr] RGB/PAL over VGA at variable frame rate
vdr at toh.cx
Wed Jul 23 17:53:01 CEST 2008
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
attached to that post:
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
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
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.
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.
More information about the vdr