Science: Why Strobe Crosstalk Varies during ELMB-SYNC
Posted: 29 Jul 2020, 13:58
Vertical Total is not the only thing. Strobe phase is another problem. Also the size of VBI varies (the Vertical Blanking Interval -- the pause between refresh cycles). Lower frame rates have more milliseconds to hide GtG curves, while higher frame rates has fewer milliseconds to hide GtG curves.
First, we under LCD GtG -- the transition of a pixel from one color to the next (a pixel will fade between colors over a finite time period), as seen in Pixel Response FAQ: GtG versus MPRT
Based on the information from my old 2014 strobe backlight hacking FAQ, as well as Strobe Crosstalk Animations, I am reusing the images here:
Simulated images of www.testufo.com/crosstalk when strobe pulse phase is adjusted relative to timing of the refresh cycles (VBI). Phase is the time offset of the strobe flash relative to start of refresh cycle.
Simulated images of large vertical total's effect on crosstalk. Large VT creates more time between refresh cycles for LCD GtG to finish transitioning between refresh cycles.
However, in a flicker-reduction manoever, ELMB-SYNC adds extra strobes (multple strobe phases!) during one refresh cycles at lower frame rates. So you have some amplified varying crosstalk effects as a compromise for reducing uncomfortable flicker during ELMB-SYNC.
Avoiding crosstalk is the art of cramming the GtG elephant in the drinking straw of a VBI. VBIs are usually less than a millisecond, not enough time to fit GtG between refresh cycles. But you also have to watch the strobe flash timing too.
Screens refresh like this (high speed video of 60Hz):
That fade zone that wipes from top to bottom, is the GtG fade. The problem is we need the GtG fade zone to complete at the bottom of the screen before the GtG fade zone begins anew at the top. Unfortunately on older screens, GtG started again at the top edge before GtG finished at the bottom, the GtG fade is essentially pixel momentum lagging behind the refresh. So you can have multiple refresh cycles overlapped (witness: 33ms 60Hz LCDs), where multiple refreshes are fading on top of each other -- pixel response can exceed refresh time. Fortunately GtG today is fast enough to mostly hide between refresh cycles. That's what makes good strobing possible today, even if it is isn't 100% perfect, since GtG doesn't quite go fully 100% perfectly between refresh cycles. But it's remarkably good nowadays.
Screens refresh one pixel row at a time, top to bottom, as seen in videos at www.blurbusters.com/scanout ... So that eats into time that could be spent in the VBI (the Vertical Blanking Interval). One can scan faster (use a lower strobe refresh rate, e.g. 120Hz on a 240Hz monitor, and use 1/240sec sweep. That means 1/240sec scanning out, 1/240sec in VBI, for a 120Hz strobe. That's a 4.2ms VBI, much better for strobing.
When strobed, they look like this:
Good strobe require GtG to (nearly) fully hide in the VBI, unseen by human eyes. Strobe backlights eliminated the motion blur limiting factor of LCDs when the first LCDs came out that had GtGs fast enough to nearly fit in a VBI -- that happened just barely ten years ago for the first time. Finally, LCDs could achieve CRT motion clarity when (most of) GtG could be hidden in the VBI.
But, only most. The problem is LCD GtG 100% is still too slow to 100% fully perfectly fit in the VBI between refresh cycles, so one has to accept at least a minor amount of crosstalk, since perfect strobe requires VBI (the pause between refresh cycle scanouts in milliseconds). Changing VBI-size and/or strobe phase, will affect crosstalk. Unfortunately both is majorly affected simultaneously during ELMB-SYNC.
VRR throws two monkey wrenches:
- The varying size of the VBI, means varying time-allowance for GtG-finishing
- The varying time intervals between refresh cycles, means potential for variable flicker effects.
Engineering solutions that attempt to solve both of these, come with compromises (but I know it could be better)
There is more ELMB-SYNC optimizing work that can potentially be done, especially if the pulse controller can be 100% fully decoupled from refresh cycles, so that the backlight controller can create proper strobe pulses that overlaps the VBI, temporally offset to compensate for the GtG duration and GtG latency (processing latency too). Not all monitors have sufficient strobe phase flexibility, so there's limits to how good strobe tuning can become. And flicker-reduction algorithms for variable strobing won't work to their full potential without full strobe-phase flexibility.
Tuning strobe has to be done separately for different refresh rates, and often compromises has to be made for in-between refresh rates to use the nearest tuning setting. Also, consider temperature and panel lottery effects will change crosstalk between panels, to the point where the 100Hz tuning setting may have been better for the 120Hz mode. (This is one large part why 119Hz PureXP looks better on many panels: It uses the 100Hz PureXP tuning).
Now trying to do for VRR where there is infinite refresh rates, while trying to eliminate the flicker from framerate transitions -- that is extremely challenging especially with limitations of many backlight controllers.
For predictable crosstalk, fixed-Hz strobe is currently hugely better.