Difference between revisions of "Frame display timing"

Revision as of 15:57, 7 April 2010

Frame Display Timing Methods

MythTV can make use of several timing methods to control how often frames are drawn in a process known as "page flipping" or "double buffering. Essentially, each frame is drawn to an off-screen buffer that is then "flipped" with the buffer that is being used for the on-screen frame. The next frame is then drawn into the buffer that contained the previously on-screen image while the frame that was just drawn into the off-screen buffer is being displayed.

The flipping of each buffer is controlled by one of the following methods:

• Video card (driver-provided function, OpenGL, or DRI)
• RTC (Real-Time Clock)
• usleep

Of the three, the video card method is often the most preferable, as buffer flipping should take place during a time when no image is being drawn (during the Vertical Blanking Interval, commonly abbreviated VBI) to prevent the buffer from being flipped before it has been fully drawn. However, the video card method is usually not available on the majority of cards. At the moment, it would appear that only some nVidia drivers support the feature to an extent that MythTV can utilize.

Second to the video card method, it is debatable whether RTC or usleep is better, although usleep is considered to consume more CPU time. Furthermore, some feel that usleep is not as accurate. Again, this is also debateable.

Side Effects of Poor Timing

The most obvious side effect of improper timing in MythTV is an effect known as "frame tearing", and can be seen during horizontal pans in scenes or in scenes where there is a high amount of horizontal motion, as in this example image provided by Intel in their article on video frame synchronization:

Currently, there do not seem to be any other noticeable side effects of poor buffer flip timing other than tearing, but tearing alone can sometimes mean the difference between an enjoyable show and an extremely distracting synchonization problem.

Determining the Active Timing Method

To determine the method that is currently in use by MythFrontend, start it from a console with the "-v playback" command-line argument, and begin watching a show, either one that is live or one that has been recorded earlier. Then, stop watching and switch back to the console. Scroll back through the console and look, after all the initial playback messages regarding finding decoders and setting up video surfaces, for something similar to the following:

2005-01-04 18:21:25 Video timing method: RTC
2005-01-04 18:21:25 Refresh rate: 40000, frame interval: 40000

Receiving the above message would indicate that RTC timing is being used. If the user has an nVidia card, the following message indicates that timing support is broken or unimplemented in the active driver release, and that MythTV will fall back to another method (usually RTC):

2005-01-04 18:21:25 nVidiaVideoSync: VBlank ioctl did not work, unimplemented in this driver?

A user has indicated that nVidia broke support for this feature some time after the 4xxx series of drivers. OpenGL Vsync can be enabled in MythTV to supplement this functionality, however, in the most recent driver release (8178 as of this writing), OpenGL Vsync is known to horribly thrash CPU usage and possibly cause playback problems. It is recommended to use driver releases 7676 or 7667 for this and other reasons.

Adjusting the RTC Interrupt Frequency

If MythTV will be using the RTC to time the display, it will usually request a high interrupt frequency, allowing it to time frames more precisely. However, unless MythFrontend is a privileged process, the highest frequency that it can request by default is 64 Hz. This is usually not sufficient for CRT monitors that are often set to a higher frequency, usually 85 or 100 Hz, as well as some LCD screens and projectors that can accept various frequencies, producing the tearing artifacts as mentioned earlier. The most common solution is simply to increase the maximum frequency that an unprivileged process can request from the RTC.

Using cat + /proc

To determine what the current maximum frequency for an unprivileged process is set at, run (as root or using sudo):

cat /proc/sys/dev/rtc/max-user-freq

By default, this will be 64 on most systems. To increase it, issue the following (again, as root):

echo 1024 > /proc/sys/dev/rtc/max-user-freq

Verify that it has changed by issuing the "cat" command (above).

NOTE: You may not find the setting like described above, on my system (KnoppMyth R5D1/debian) it is here:

/proc/sys/dev/hpet/max-user-freq

And on Ubuntu 9.04

echo 2048 >/sys/class/rtc/rtc0/max_user_freq
echo 2048 >/proc/sys/dev/hpet/max-user-freq

In some cases, /proc/sys/dev/hpet/max-user-freq may instead be found at /sys/devices/pnp0/00:05/rtc/rtc0/max_user_freq which changes the modification to the following:

 echo 1024 >  /sys/devices/pnp0/00\:05/rtc/rtc0/max_user_freq 

This may change depending on your hardware. The PCI id may change, for example. According to this link the change of sys nodes is an artifact of newer kernels.

Using sysctl

Viewing:

sysctl dev/rtc/max-user-freq

Setting:

sysctl dev/rtc/max-user-freq=1024

/etc/sysctl.conf

Add the desired configuration to /etc/sysctl.conf to apply the values at startup.

$ cat /etc/sysctl.conf
dev.rtc.max-user-freq = 1024