Cause of variable input lag?

[xeos]

I've been testing a bunch of TVs that I picked up cheap on the used market and have found that the input lag on several of them isn't consistent between tests, but differs by up to 16ms. Have other people seen this? I've never seen it mentioned in a mainstream tv review (rtings or the like). Maybe it's only an issue with older TVs?

Here's an example, and my theory about what's going on:

https://alantechreview.blogspot.com/202 ... g-and.html

While I do suspect I've figured out the cause it's such a weird design choice that I'm wondering if there's another explanation, or at least justification for it.

[deama]

Maybe they vary some internal settings depending on the content they detect? E.g. if it thinks you're playing a game it'll switch on something that'll help with input lag, or if watching a movie it'll enable some stuff reducing input lag, but improving quality.

[xeos]

Have you seen anything like that?

That would be some pretty fancy processing. Definitely beyond what these older TVs could do, but maybe with newer tvs.

[deama]

Have you seen anything like that?

That would be some pretty fancy processing. Definitely beyond what these older TVs could do, but maybe with newer tvs.

One user was complaining that when he used a HDMI cable to plug into his pc it was blurrier, but displayport was sharper, so maybe.

[xeos]

different input lag based on the input is definitely something I've observed. it's because the different inputs (vga vs hdmi) have very different signal processing requirements.

[xeos]

Since nobody has offered a compelling alternate explanation of the drifting input lag I've measured I went ahead and wrote up my explanation in detail: https://alantechreview.blogspot.com/202 ... -dont.html

[Chief Blur Buster]

While I've seen displays with variable lag (sometimes from bugs, sometimes from interpolation), there are many causes of variable input lag but most of them are on the computer/console side. Varying framerate means varying frametimes which means varying lag even for 60fps.

You must exclude such factors by using synthetic lag tests (e.g. photodiodes).

Frametime induced latency change effect
For example, if you have a 60fps cap, you can have 1ms frametimes or 16ms frametimes, and it'd still stay locked 60fps, except with 1ms versus 16ms differences. So you get variable latency at constant framerates for a 60fps VSYNC ON console game, if you have lots of frametime variances before the refreshtime.

VRR range induced latency change effect
Variable latency at the display level can be caused by switching modes (VRR entering/exiting VRR ranges), though that's a driver-and-display cooperation behavior (Present()-to-Photons), as a VRR latency change effect of entering/exiting VRR range.

Game induced lantecy change effect
Software will often do many things that suddenly increase/decrease lag, e.g. more players suddenly in view, requiring more processing in the game, especially with multithreaded rendering, which may decouple frametime latency a bit, etc.

Setting change induced
Changin settings (GAME MODE, strobing, interpolation, HDR on/off, refresh rate change, switcing inputs etc) can change latency of display processing. I've seen HDMI with more lag than DP, and I've seen DP with more lag than HDMI, so there's no hard-and-fast rules for some of them.

VRR granularities
Any weak link in VRR that jitters Present()-to-Photons, including flawed VRR processing in a display, can add variable latency effects to VRR. Usually these are only millisecond-timescales, so won't be 16ms jumps. Not all displays can continually vary their refresh cycles (ideally) in sub-millisecond increments, this is a poorly tested territory, as most sites don't analyze VRR inaccuracies.

There are many others.

Now, if you have excluded the system side, and you haven't been fiddling with display settings, you may have some automatic processing behaviors in the display that enables/disable interpolation processing in realtime, adding/decreasing lag. Also bugs exist in some displays that can cause frames to miss the televisions' internal VSYNC, so creating stutters and/or variable latency from buggy processing, since the internals of display processing may be another station in the assembly line of Present()-to-Photons, and I've seen some televisions do frameskipping. To diagnose this, test www.testufo.com/frameskipping on that television and make sure it is not erratically frameskipping. However, if it is content-based, it may erratically frameskip depending on changed content, and create erratic lag changes. This is more common with interpolation (e.g. smooth for pans, but choppy for complex motion).

Try turning off as much processing as you can
- Go to GAME MODE and/or select PC or COMPUTER mode. You may need to try both (if not allowed simultaneously)
- Disable overscan (so desktop is not cropped/scaled)
- Use the PC input (test different inputs to find which ones are the most PC-optimized inputs)
- Disable sharpness processing (set to neutral sharp setting, that doesn't sharpen or blur)
- Disable HDR (if using commodity non-FALD LCD)
- Disable VRR unless you're using it intentionally (and VRR framepacing is good)
- Test different profiles of the TV that is less likely to induce variable processing behaviors

[xeos]

These are photodiode tests. two different devices (my piLagTesterPRO and the OSSC) have measured this behavior across 5 different TVs.

[Chief Blur Buster]

Try reconfiguring the TVs and seeing if the number of TVs with lag volatility decreases.

Also, always measure the same screen location, because of latency gradients.
Not all pixels refresh Present-to-Photons() at the same time.

VSYNC ON + nonstrobed creates TOP < CENTER < BOTTOM (fixed lag gradient)
VSYNC ON + strobed creates TOP = CENTER = BOTTOM (higher lag but fixed lag offset)
VSYNC OFF + nonstrobed creates TOP = CENTER = BOTTOM (low lag)
VSYNC ON + strobed creates TOP > CENTER > BOTTOM (erratic, sample multiple passes)

If you move the sensor around between tests, you will muddy your results massively. Even moving the sensor by 1 inch can add a 1ms-or-bigger error, so put a piece of tape for your sensor target.

[xeos]

I attach my sensor with tape. It's not going anywhere.