[mythtv] [mythtv-commits] mythtv commit: r26314 - in trunk/mythtv by markk

[Mark Kendall]

On 19 September 2010 14:18, Mark Spieth <mark at digivation.com.au> wrote:
>  On 9/19/2010 2:08 PM, Mark Kendall wrote:
>> Out of interest, what video renderer and video card combination are you
>> using?
>
> I use a 8400GS on both my systems. 1 32 bit (i3 530) and 1 64 bit (AMD).
> video renderer is xv-blit on both. both on nvidia 256.53. everything is rock
> solid except the odd blackness (<5 secs) on the amd system above nvidia
> 169.12 driver which I suspect is temp related above 72C as I have case fan
> low and cpu fan controlled (mostly off).

All you should need to do on either system is enable Sync to Vblank
for XVideo in nvidia settings. If that is already enabled, anything
else for you are using - such as opengl vsync - is entirely
superfluous.

> It was my understanding that the vsync stuff just controls the frame/field
> generation and its XV that controls the toggling of the double buffer
> (assuming XV is in use). the videoout->Show() controls the flip. naturally
> if the thread gets preempted or suspended between vsync calc and the flip,
> then all bets are off.

The primary function of the vsync code is to time the presentation of
fields/frames. The 'basic' subclasses such as USleep, BusyWait and RTC
simply try and ensure that frames are presented at regular intervals.
They do not care or know about the vertical blanking period etc and
with no other means of regulation, will produce tearing.

The OpenGL and DRM vsync subclasses also, in theory, only return at
the beginning of a vertical blanking period and hence any subsequent
buffer swap (which is triggered immediately after the vsync
WaitForFrame method returns) should be within that blanking period and
hence you get no tearing.

The Show method in the video output classes simply triggers buffer
swaps. Depending on your hardware, drivers and settings, it may
however block until the next vertical blanking period and hence
produce tear free presentation. This happens if you are using the
OpenGL video renderer and have sync to vblank enabled for OpenGl, for
XVideo (and XvMC) as mentioned and Direct3d on windows. VDPAU
schedules the buffer swaps independently within the driver (presumably
in a separate thread) and handles its own vertical syncing.

99% of my video playback is with VDPAU and it just uses one or other
of USleep or BusyWait (I forget which) to control the rate of
presentation of frames to the driver and playback is smooth. By and
large the same for applies for opengl on different OS's, XVideo on
different linux open source and proprietary drivers and direct3d.

regards

Mark