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 _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
