[MPlayer-users] Re: Framerate vs. monitor refresh rate

[Keean Schupke]

Im new to this list, but have some experience with video. The problem
(and I get it too) would appear to be lack of vblank-interrupt support
by either mplayer or the drm kernel-module for you chipset. In my case i
believe that it is a kernel-driver issue (i965 chipset, with i915 kernel
module). One way to check is to run some openGL applications with the
"driconf" setting set to "force applications to sync with vblank" - then
run say glxgears. If the framerate is the same as the "refresh rate" set
in the Xorg config (even for LCDs!) then you have vblank support (which
would be 60fps for me). If however the application runs full speed
(1200fps for me) then you do not have vblank support, and you need to
bug the kernel driver not mplayer.


Regards,
    Keean.

sci-fi at hush.ai wrote:
> On 2006-11-22 02:27:01 -0600, "ACS" <adrian.bacon at xs4all.nl> said:
>> ----- Original Message ----- From: <sci-fi at hush.ai>
>> To: <mplayer-users at mplayerhq.hu>
>> Sent: Wednesday, November 22, 2006 07:24
>> Subject: [MPlayer-users] Re: Framerate vs. monitor refresh rate
>>
>>> Respectfully, yes I *do* think you are "seriously misinformed"
>>> in that LCDs really do NOT have refresh rates as you seem to
>>> think.  Also please remember my discussion here is in regards
>>> to DVI-D and no other interface.
>> YES and NO
>> NO: there's no refresh. All pixels are constantly lit, so there's no 
>> flicker, unlike CRT sreens, where pixels aren't lit constantly. This 
>> is why you won't notice any flickering on white surfaces on a lcd.
>>
>> YES
>>> Also he made another point which backs _me_ up when I say an
>>> LCD pixel "stays lit" by itself until the VRAM is changed.
>> VRAM  data is constantly copied pixel for pixel, line for line to the 
>> lcd pixels. When a full screen copy is completed, the copy process 
>> restarts at the begin.
>> This copy process takes time, limiting the rate VRAM data is copied 
>> (refreshed!) to the LCD pixels.
>
> ...then I am going to *need* to find the article I read a while back that
> said only modified pixels are copied to the LCD in Apple's case... that
> particular point has stuck in my mind all this time for some reason...
>
>>> Here is a recent thread in which someone lost his cool when
>>> people kept saying LCDs have refresh rates:
>>> http://forumz.tomshardware.com/ce/Consequences-Higher-Refresh-Rates-LCD-ftopict50988.html#362496 
>>>
>
> Read
>>>
>> post from TeraMedia on that topic!
>
> That's precisely where the URL's #362496 label takes you, TeraMedia's 
> post
> _is precisely the one I wanted read_ to make my point.
>
>>> Let me try explaining again:  It's as if "slices" weren't
>>> exactly in-sync in a horizontal fashion.  When they are
>>> slower-to-draw, it's as if a BMP is being drawn in
>>> "slices" -- it begins in the lower sections and goes up,
>>> in each "slice"...........
>>
>> I still think of it as lack of double buffering.
>
> As I eluded to earlier in this thread, -double/-nodouble made no 
> difference.
> Neither did -slices/-noslices, or -dr/-nodr ... I'm out of options 
> IIUC...
>
> but does -vo macosx enforce use of -double regardless if we try to say
> -nodouble?  for that matter, will -vo macosx override the other mentioned
> options likewise?
>
>
>> I you can't make screenshot, use a digicam and set shutter time lower 
>> than your LCD refresh rate ;-)
>
> good grief again I say I can't send you screenshots, I can afford no
> such equipment!  I spent all my wad on the DualG5/23"HD system here!  ;)
>
> and btw pray tell what _is_ this 23"HD's refresh rate???  ;)
>
>> Adrian
>
> Seriously, I wouldn't raise this as a concern if it wasn't so bothersome.
> I was hoping it'd go away after getting all the projects compiled to run
> on this Dual G5 system (2.7GHz).  But now I'm quite able to say we have a
> common situation here seemingly only relegated to the -vo macosx no 
> matter
> which kind of G4/G5 system is running mplayer, CRT and LCD act the same.
> I'm afraid I'll need someone to verify it on other Mac models...
>
> Let's not confuse the LCD-refresh argument with the tearing problem
> of -vo macosx since it's definitely visible on more than one kind of PPC
> system here.
>
> Thanks for trying to help, I'll still try anything as I said within 
> reason...
>
>