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

[Keean Schupke]

Hi,

    whilst the LCD has a stateful framebuffer (if you stop sending it
pixels it will just continue to display the same image) it _does_ have a
refresh rate. Pixels are send over the DVI-D as 24bit data values:

QUOTE:

The picture is transmitted line by line with blanking intervals between
each line and each frame, and without packetization

/QUOTE

In other words the signal timings on DVI-D are the same as for analogue
VGA, the only difference with a DVI connection is that the pixel values
are digitized (24bits) and the sample clock for the monitor (pixel
clock) is sent with the signal.

So the problem would appear to be lack of vblank synchronization exactly
as it would be on a CRT.

    Regards,
    Keean.

sci-fi at hush.ai wrote:
> On 2006-11-21 08:23:31 -0600, Reimar Döffinger 
> <Reimar.Doeffinger at stud.uni-karlsruhe.de> said:
>> 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).
>
> 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.
>
> 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 
>
>
> So
> ... "frame grabs" YES but not refresh rates as people have
> been accustomed to think all these years.  ;)
>
> Also he made another point which backs _me_ up when I say an
> LCD pixel "stays lit" by itself until the VRAM is changed.
>
> I'm also trying to find an Ars Technica blurb on this, too,
> which was written to explain Apple's LCDs and ATI/nVidia cards
> in particular, but right now I can't remember the exact
> keywords to hit it.  I distinctly remember it saying that
> _only_ the _changed_ pixels need refreshing on the LCD, which
> lowers bandwidth greatly, and the DVI spec does have such
> features (i.e. not just a whole-frame grab).  This means the
> LCD support electronics has some sort of memory bank itself,
> if each pixel doesn't act like a memory cell at that level.
> And it might explain why Apple's gear is more expensive (and
> boy I'd like to see their patent sheets ;) ).
>
> Yes this makes things more complex -- OR MUCH SIMPLER --
> -- depending on how driver software etc. are written.  For
> example, I cannot find a 'ModeLine' file anywhere for Apple's
> X11, because we are told it does not use it anyway.  Their X11
> fits snugly with CoreVideo or Quartz anymore, uses the native
> OpenGL, SDL, etc.
>
> I therefore _truly_ think these LCDs & cards really do not have
> refresh rates in the sense we've always thought for years...
> and maybe this kind of thinking is messing up the -vo macosx
> in some manner...
>
>
>
>
>>> 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...
>
> I wish Apple had a hardware maillist or discussion group
> without having to be a $paid$ ADC member, because I'd surely
> get these questions sent to them... but ATM I feel I am
> quite right to say these LCDs do *not* have a refresh rate
> as we all have understood such for years...
>
>
>> [...]
>>> 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.
>
> I was trying to put disrespect on Apple's development tools.
> Did you see the winky there?  ;)
> (good grief man, I *do* know all that, and I'm sure Apple was
> only trying to simplify all that technical stuff to say these
> LCDs can be your hi-def display, but of course since they
> can't do HDCP... so this is going to cause me to search hi & lo
> for the _true_ specs of these LCDs...)
>
>
>> [...]
>>>> 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.
>
> ... I'll continue to search for those Apple-specific tech
> articles; do keep in mind that Apple tends to enforce higher
> specs than plain-jane generic PC boxes do... ;)
>
>
>> [...]
>>> 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.
>
> Okay some new news on this:
> it also happens on a slower single G4/AGP2x tower I
> have, which does use a more "normal" ATI card & CRT.  I'm a
> bit amazed that even plain standard-def .ts TV shows I've
> recorded myself act about the same on both machines (G4 &
> Dual G5).  So different versions of OSX are involved, as are
> different versions of XCode/gcc/etc., vastly different
> motherboard/CPUs/RAM/etc., and due to different ATI cards,
> different ATI drivers are involved as well.  (I don't know
> anyone to try swapping out these cards with, say, a
> supported nVidia card, our only other vendor choice...)
>
> 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".
>
> Over the whole video frame, the lower parts and right-hand
> quarters are more prone to this ISTM.  So I'm trying to
> explain multiple levels of how this acts up.
>
> Once more:  Over the whole video frame, the lower+right areas
> seem more prone to this, and inside the slices they're slightly
> slower to draw from the lower lines upwards inside each slice,
> altogether simultaneously all slices.
>
> When scaling to enlargen the view on the monitor, the torn
> slices are definitely inside the enlarged video interlaced
> lines (not aligned to them), and the slices are not smoothed.
>
> The slice-drawing-upwards is still very fast, but discernably
> slower than the rest of the video action going on.
>
> To be clear: multiple slices are doing this, sometimes 10, 20,
> 30 such slices, across quite a wide area but still usually within
> the lower areas of the video frame, all seen together ... and so
> this can't really be explained as a CRT refresh/sync problem.
>
> I can almost count the size (tallness) of the slices, they seem
> uniform, but the start-/end-points can change.  Each slice
> almost looks "trapezoidal" in shape, parallel along horizontal
> lines, very wide, and skinny-tall.  Corners almost never match.
>
> Such slices are almost never completely across the whole frame.
> It's usually only during high-motion areas, too, but again the
> lower+right areas are more prone, altho the tearing has been
> seen to happen anywhere.
>
> It might be the non-changing areas of the frame that fools
> the shape & size of each trapezoidal slice.  Meaning each
> slice _might_ go clear across the frame.  But there are
> usually so many slices (slower-drawing regions) visible
> simultaneously that they don't seem to be related to one-
> another.  In-between regions are being drawn at same rate
> as rest of frame.  So the slices look trapezoidal.
>
> I'm quite inclined to blame OSX itself but I also want to
> see if -vo macosx is written within specs of Tiger and
> Leopard as documented, since -vo's sdl quartz x* seem okay.
> (since I can't afford to be a $paid$ ADC member, testing on
> Leopard is going to need to wait...)
>
> Yeah it's weird to describe.  And there's no way to let
> you-all see this except to try it on a similar hardware
> set-up for yourselves.
>
>
>
>> I have no idea why it happens with -vo macosx, I really think it
>> shouldn't (though I don't know the code).
>
> Well, since I have two rather different (but still 100% Apple)
> systems here, and the tearing is seen only with -vo macosx on
> both, I'd sure like to help figure out what's going on.
>
> In meantime, I could put vo=sdl or vo=quartz in my
> ~/.mplayer/config file, but that will mess-up testing our
> GUI project (MPlayerOSX in its own SVN tree there).
>
>
>> Greetings,
>> Reimar Döffinger
>
> I think the LCD-refresh issue is misleading us a bit, but I'd
> sure like to find the proof I've read and show it to you.  ;)
>
> If anyone has ideas for the -vo macosx slices problem, I won't
> mind testing them (within reason of course).
>
> Thanks for discussing this.
>
>