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

[Keean Schupke]

sci-fi at hush.ai wrote:
>
> Hi again,
>
> (btw we're not suppose to top-post in these discussion groups)
>
> On 2006-11-22 06:05:03 -0600, Keean Schupke <k.schupke at imperial.ac.uk> 
> said:
>> 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.
>
> As I said in another reply to you:
> "Remember this is Apple."  ;)
>
> I've tried to explain the kind of tearing is along many
> trapezoidal slices all at the same time.  This suggests that
> DVI-D has several scanlines being updated all at the same
> instant in parallel, which doesn't fit the quoted material you
> provided, presuming "line by line" means SEQUENTIALLY as seen
> by the human.
>
> Also the same kind of tearing is seen with a normal CRT
> monitor on a VGA connection, not DVI-D.  Now surely there is
> only one e-beam inside the CRT, which would produce a kind of
> half-way-done frame -- not the 10 or 20 or 30 separately torn
> trapezoidal slices being seen even when using the CRT.
>
> The tearing being seen just does not fit this "normal" way of
> thinking about refresh rates, no matter what kind of monitor /
> interface being used.
>
> Pressing mplayer's '.' key instantly stops the frame, but this
> gives time for the torn regions to clear themselves up.  Which
> reminds me that I have seen tearing while single-stepping by
> hitting '.' for each frame, but the tearing clears right up.
> Something is going on here, and it's frustrating to not be
> able to analyse it (how would one put a freeze/trace on the
> OSX kexts while watching the monitor?).
>
>
> Bottom line:  None of this explains why tearing only happens on
> -vo macosx, while the other -vo's are okay, no matter if using
> a LCD or CRT.
>
> yeah I know I'm once again repeating myself here...
>
> Thanks again.  I'll stay tuned if things don't fall down here.  ;)
>
>
>
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
You _do_ get tearing on CRTs with both DVI-D and VGA connections... the 
connection makes
no difference at all (I have seen it with my own eyes)...

Yes, when you single step, the tear will clean itself up, it only occurs 
when the image is changing. If the image
is static, the tear is still there - but you cannot see it because the 
images are the same. The same goes for video the
tear effect is most visible when the image changes a lot frame to frame.

Everything you describe is entirely consistant with a lack of 
syncronisation to the VBlank period, except that it occurs
at multiple vertical positions at the same time... So I dont know whats 
causing it... but my problem is definitely a vblank
one, and I really just wanted to point out that DVI-D still uses a 
normal CRT-like scan pattern for the display updates.

Another possibility is that the video is interlaced and scaled down, 
Then the tearing would be an interlacing artifact,
but the scaling would mean you don't necessarily see every line of the 
deinterlaced image...

Mac or not it makes no differece, and the cable type (DVI-D, VGA) also 
makes no
difference. (remember macs now run on intel, and MaxOS-X is a derivative 
of FreeBSD, so in terms of OS kernel
it is more like linux than it is like windows). There is nothing special 
about the mac hardware or how it runs the
framebuffer updates... although it could always be a bug in the driver 
for the hardware...


    Keean.