[mythtv] OpenGL vsync issues

[Matt Doran]

Doug Larrick wrote:
> 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.
>   
I figured that.  It just fails badly for me in this one case..... and I 
think I've covered all the bases (see below).
> 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.
>   
It is, I'm watching PAL 25Hz with a 50Hz refresh rate.
> 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
> mph).
>   
I understand this.  I had debugging in the code to understand how the 
doubling of the frame-rate works.

The thing that's confusing here is that the problem occurs when 
de-interlacing is disabled, because a progressive video has been 
detected.  It means that it works when it's under most stress, and it 
fails when the stress is lessened.

I don't really understand how the bob deinterlacing process works, but 
when the video scan is set to progressive, the frame rate is dropped 
down to the normal rate.   I wondered whether if there is a latent bug 
in here somewhere.  e.g. could bob be filtering the output even when the 
frame-rate has been dropped??  If it was, I assume the output would be bad.

What could cause the strange jerkyness and tearing only when the 
deinterlacing has been disabled because we're playing progressive video?!?

I didn't understand all the interactions between filters, video output 
the player, etc.  So had trouble investigating this thought.  Then 
again, as you said ... this works for others, so maybe it's my hardware????
> Some common problems:
> * 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
> retrace.
>   
I am using a recent driver, and I have enabled the "UseEvents" option.   
I did have the vblank options disabled.  I've also tried them on.
> * 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.
>   
I'm using the ubuntu kernel which is compiled as 250 Hz, which should be 
fine for 50Hz refresh rate and 25fps video.

> * 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.
>   
I've got plenty.  AMD X2 3600 ... I only have 20-30% cpu usage with bob 
enabled, and the CPU is in power saving running at 1000Hz instead of the 
full 2000Hz.

I've set the limits so that I can run in real-time priority.

> * 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).
>   
Dunno about this.  But I've never noticed anything.

So it looks like I've covered all the bases, and I still have the 
problem.    And I think I'm getting out of my depth in the video timing 
stuff.   But I'll try to do some more debugging when I get a chance.
>
> 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.
>   
I'll try  :)    I was hoping someone might have an idea of the cause.