[mythtv] OpenGL vsync issues
doug at parkercat.org
Mon Jun 4 12:00:37 UTC 2007
Matt Doran wrote:
> Hi there,
> I recently had an issue where a DVD had very poor playback - jerky
> (almost like it was missing frames) and there was visible tearing. When
> I changed the video sync from progressive to interlaced the problem
> disappeared. I originally thought Myth was incorrectly detecting the
> DVD's scan type, but after some experimentation and help of Stanley
> Kamithi I've come to the conclusion that the problem is with OpenGL
> vsync (and possibly it's interaction with the bob-deinterlacer??).
It's unlikely there's anything horribly wrong with this code -- it's
worked well for many folks for years.
OpenGL vsync (and DRM vsync, and nvidia vsync which no current video
card uses anymore) wait for the actual vertical retrace. RTC vsync and
usleep-with-busywait vsync are simply trying to wait an appropriate
amount of time based on the video's actual framerate, and let the
display driver sort out what picture corresponds to what refresh.
The advantage of syncing to vertical retrace is that you get exactly one
frame per retrace, so motion is smooth.
As I've gone over a few times on the users list recently, the
retrace-syncing methods require that your display's framerate be pretty
close to a multiple of the video's framerate. So watching a 25 Hz PAL
recording on a 60 Hz display is unlikely to be good.
Bob stresses the vsync system (and indeed the entire video out system)
by doubling the effective framerate, exposing problems that are
otherwise masked (like when your car only makes that funny noise over 60
Some common problems:
* Bad refresh rate as compared to your video's framerate. A good
feature for Myth longterm might be the ability to choose a video mode
based on framerate as well as on video size, but for now getting it set
up properly once is the user's responsibility. This is gonna become
annoying in the US in a few years when we have the analog switchoff and
the HD broadcasters move from 59.94 Hz to 60 Hz; not every source is
going to switch at the same time, so every 1001 frames we'll see a
hiccup on some material no matter what refresh rate we choose.
* Driver issues. The nVidia driver needs a combination of
sync-to-vblank options that seems to vary based on hardware model;
symptoms are similar to what you describe. Also, recent nVidia drivers
require "UseEvents" option or they suck all CPU waiting for vertical
* Insufficient Linux kernel HZ setting. A lot of systems use a
timeslice of 100 Hz; this is really not fine-grained enough for a
multithreaded application like MythTV to decode & display a 60 Hz video,
but might work OK at 30 Hz. Up it to 500 or 1000 and build a new kernel.
* Borderline CPU power. If your system works OK w/o bob but hiccups
with bob turned on, you might not have enough CPU to get the job done
reliably. Enabling real-time priority (by setting up pam
/etc/security/limits.conf rtprio on a modern distro) can help, but might
instead exhibit the dreaded "prebuffering pause" on high-motion scenes.
Insufficient CPU power is unlikely if your CPU is less than a couple
years old, unless there's something else happening on your system.
* Soundcard issues. I never fully understood what's going on here, but
some people's soundcards / drivers don't play the audio at the right
rate, screwing things up immensely (since by default Myth uses soundcard
timing as the gold standard).
I do recommend reading the code as you've done (and the comments too) to
understand what's going on here... and if you see a bug (despite my
assurances), fix it and submit a patch. When I started looking at this
stuff 3 1/2 years ago I figured the existing code couldn't be *too*
broken, but there were some bad assumptions in there and if you look for
my name in the archives you'll see that I touched a fair amount of it,
not without some discussion.
I'd recommend dumping gettimeofday() calls to a logfile at particular
points in the code; that's the most effective way I found to debug these
The project has a number of strong developers, but their time is limited
and they likely don't have your hardware / setup, so the easiest for all
concerned (except maybe for you :-) ) is to debug & fix it yourself.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20070604/61899a67/attachment.pgp
More information about the mythtv-dev