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

[Reimar Döffinger]

Hello,
On Tue, Nov 21, 2006 at 03:58:51AM -0600, sci-fi at hush.ai wrote:
> ah but I have read enough on DVI-D to know there is no
> "refresh", so that is where most discussion seems to go down
> the wrong trail here  ;)
> perhaps "bandwidth" across the wiring, which necessarily
> involves "time" and "clock" rates as you say, but otherwise
> "refresh" cannot be computed or algorithm'd as in the old
> CRT sense at all, there simply is no blanking signal on
> which to "wait" (as I said in the old CRT sense) ;)

Either LCD technology has completely changed or you have read some
seriously misinformed stuff.
A LCD display still needs to be refreshed regularly, otherwise it
becomes all white (CRTs become all black obviously), and this
refreshing is still like with CRTs done line by line. Thus there
obviously is a refresh rate, namely 1/time it needs to refresh all
lines. Which IIRC usually is 60 Hz, though at least those with a VGA
connector allow some Hz variance to adjust to the graphics cards refresh
(of course they also work if the refresh from the cards is not 60 Hz, it
just is suboptimal).

> If Apple & OSX designed this 23" Cinema HD display (I
> actually have here) to have a "fixed" refresh rate in the
> CRT sense, we should see a number in the Displays panel
> (System Preferences), a number that cannot be changed since
> it would be "fixed".
> But instead we _actually_ see "Refresh Rate: n/a" i.e. NOT
> APPLICABLE and greyed-out (cannot be changed as well).

OS X is not exactly known for exposing the user to the raw, unpolished
truth to the possibly technically challenged user...

[...]
> Apple's specs would only say it goes fast enough to keep up
> with HDTV movies, but that doesn't say their o.s. and
> compiled code from third parties will do so.  ;)

Wow, that is a useless thing to say. There are several things involved
1) DVI bandwidth
2) max. refresh rate of the LCD controller
3) time to change the colour of a single pixel, which is usually has at
least two different factors
  a) time to change from black to white and the other way
  b) time to change between different levels of gray
  These are different because AFAIK some techniques make only one of
  these faster.

[...]
> >Try to visualize what happens when display switches halfway in its scan 
> >from top to bottom from previous to next decoded frame.
> 
> I cannot visualise this when there is no refresh rate here
> with DVI-D as there is with CRT -- the pixels are changed on
> the LCD as fast as DVI-D can send them from the ATI card.  ;)

All I read and know indicates that LCDs do not work at all the way you
imagine...
And I also think that DVI can only update the whole screen at once, it
can not cherry-pick only the pixels changed on the graphic card, which
is enough to allow for a tearing effect.

[...]
> Let me try to describe the tearing a bit more.
> I know what interleaved lines look like, this isn't it at
> all.  The tearing seems to be horizontal by nature, usually
> starting in the lower areas of the frame, as a BMP might be
> drawn (bottom-up).  It's almost as if the slice-blitter
> inside mplayer can't keep up when using -vo macosx -- so I
> played with -noslices which didn't help either.

You mean e.g. the lower part of the screen shows the next frame and the
upper part show the old one? That is classic tearing.
I have no idea why it happens with -vo macosx, I really think it
shouldn't (though I don't know the code).

Greetings,
Reimar Döffinger