measurement of input lag delta without high speed cam

[flood]

so I'd like to estimate the difference in input lag between my gsync vg248qe and my fw900 crt.

all I have is my iphone 5 which can record up to 60fps.

since my phone has rolling shutter, I can just stack my monitors vertically, orient the phone so that it sensor's scanout occurs horizontally (right to left for mine).

then when a frame shows two broken lines, measure how many pixels apart the breaks are horizonatally, divide by 720, multiply by 16.7ms and that's it!!!!!!!!!!

and by virtue of the fw900's large physical size, it's completely easy to stack the monitors ;d

original elaborate idea:

suppose I have the following program:

vsync off, some really high framerate... 10000 should be doable
every frame: fill entire screen with white with probability 0.0001, fill entire screen with black with probability 0.999
so about every second, one sees a white strip appear across the screen.

clone the program on both monitors.

suppose the lcd has x input lag.
then with probability x/T, where T = exposure time, the appearance of a white strip on the lcd will be delayed by one video frame.

then observe a few hundred white strips from a recording to estimate x/T and thus x.


one complication: my iphone 5's video recording is rolling shutter. still thinking about the implications of this, but one way to mitigate is to just move the phone far away.

[spacediver]

This seems like a really cool idea, but I need help grasping some of the concepts:

so I'd like to estimate the difference in input lag between my gsync vg248qe and my fw900 crt.

all I have is my iphone 5 which can record up to 60fps.

suppose I have the following program:

vsync off, some really high framerate... 10000 should be doable
every frame: fill entire screen with white with probability 0.0001, fill entire screen with black with probability 0.999
so about every second, one sees a white strip appear across the screen.

I follow this perfectly.

suppose the lcd has x input lag.
then with probability x/T, where T = exposure time, the appearance of a white strip on the lcd will be delayed by one video frame.

Here's where my brain starts to hurt.

Let's assume the LCD has an input lag of 10 ms.

Suppose the camera starts "rolling" at the moment the program runs. And suppose at 5 ms, a single white frame is sent to the display.

Since the camera has an exposure time of 16.7 ms (I'm assuming exposure time is the reciprocal of frame rate? I could be wrong here, I know very little about cameras), this white strip on both displays will be captured on the first camera frame. The FW900 at 5 ms (assuming 0 ms input lag), and the LCD at 15 ms.

Now the larger the input lag, the more likely it is that the strip will be delayed a frame (assuming the input lag is smaller than the frame duration: if it's larger, then sometimes it will be delayed more than one frame).

The larger the frame duration (i.e. exposure time), the less likely that the strip will be delayed a frame.

So the probability is proportional to x/T.

If x = T (e.g. input lag = 16.7 ms), then the strip will always be delayed a frame, so probability = 1, which means that the probability EQUALS x/T, as you said.

Ok, I think I get it

phenomenal idea!

[flood]

visual derivation of x/T:

horizontal axis is time.
C is when crt stripe appears, L is when lcd stripe appears.

|<----------T---------->|<----------T---------->|<----------T---------->|
.....................C<--x-->L.........................C<--x-->L..........
........................^diff frames....................^same frame.

L appears in the same frame if C occurs during the first (T-x) moments of the frame.
L appears in the next frame if C occurs during the last x moments of the frame.
the location of C is uniformly distributed in the frame, since vsync is off.

if the framerate is high, each event. should be independent


some more thoughts:

since the strips aren't infinitely thin, only the top portions of the strips should be considered when comparing whether they appear on the same frame. this should remove any dependence on the frame rendering time.

because my phone has rolling shutter, i'll orient my phone vertically so that every vertical stripe contains the same time information.


wait wait wait ffffffff ignore everything I just wrote.
it's completely trivial to measure the lag

since my phone has rolling shutter, I can just stack my monitors vertically, orient the phone so that it sensor's scanout occurs horizontally (right to left for mine).

then when a frame shows two broken lines, measure how many pixels apart the breaks are horizonatally, divide by 720, multiply by 16.7ms and that's it!!!!!!!!!!

[flood]

gtx 750 ti
windows 7

vg248qe (gsync) input lag vs crt
note: does not include pixel transition time. this is just comparing the starts of the pixel transition.

black to white: 1.9 +- 0.2ms


^^^^^^ignore

see next post.

[spacediver]

Can you post an image of a captured frame so we can better understand the setup and method?

[flood]

vg248qe (gsync) on top of fw900.

both 1920x1080 @ 85hz.






lcd stripe begins to appear about 80 pixels to the left.

the lcd's stripe appears as a gradient mostly because of pixel persistence. the pixel transition time contributes a little as well.

the measurement is really limited by image quality here. maybe i'll use some pattern instead of a solid color for the stripe.


edit: kk so it turns out 720 pixels =/= 16.7 ms. instead i can use the diagonal lines of the crt as references. the horizontal width of that (638px)corresponds to 1000/85=11.76 ms

so 80 / 638 * 1000/85 = 1.5 ms of input lag.

that's more in line with prad.de's measurements

The latency is an important value for players, we determined as the sum of the signal delay time and half the middle picture change time. The VG248QE shows generally a very short signal delay: at 60 Hz, there are still 1.6 milliseconds at 120 Hz and then 1.2 at 144 Hz even only 0.7.

[flood]

PROOF THAT GPU SCALING DOESNT ADD (SIGNIFICANT) INPUT LAG:

at least for my system:
gtx 750ti, nvidia 340.43


cloned resolution of 1280x720
lcd has it scaled up to 1920x1080
both monitors at 120hz.

offset is still ~80 pixels.

so the input lag added by gpu scaling is <1ms for sure.

[spacediver]

I'm not really following the logic behind this test. Can you break it down step by step? And how were u able to capture the scanline of that stripe so clearly? And what are those diagonal lines all about?

[flood]

in a video frame, each column of pixels (video frame pixels, not screen pixels) contains information from a certain time interval.

my phone camera works by rolling shutter:
so if the right edge of pixels gives us information about the light hitting the sensor in the time interval (R,R+x) where x is the exposure time, which turns out to be just under 16.67ms for my videos, but that doesn't matter.

the left edge of pixels gives information from the time interval (L, L+x). originally I naively inferred that L - R= x based on the assumption that the left edge in the video frame corresponds to the left edge in the sensor's scanned region. actually it turns out that the scanned region is cropped slightly to make the video frame, and thus the left edge of the video is somewhere in the middle of the scanned region. so L-R < x and it's actually around 13ms.

so why are there diagonal lines on the crt? well the image drawn by a crt is effectively a bright line moving downwards. moving downwards is perpendicular to the direction the camera sensor scans out, so it's basically the rolling shutter effect

it's necessary to use these diagonal lines as a reference for how much the time interval shifts from each column to the next. for if my display runs at 100hz, i know the interval changed by 10ms over the horizontal width of the diagonal line. (I should probably take into account the vblank interval though).

[spacediver]

Brain's hurting. Lemme try work it out from first principles, with CRT only.

CRT is operating at 100 hz, so each frame takes 10 ms to scan.

Camera is operating at 60 fps, with horizontal rolling shutter, so each video frame lasts 16.7 ms.

Video card is sending out a 1000 fps signal with VSYNC off, so each frame lasts 1 ms.

Let's sync everything up so at time T = 0, the first frame is sent from video card, the CRT scans its first line, and the rolling shutter starts on its first frame.

At T = 5 ms, the video card outputs a full white frame (all other frames are black) that lasts 1 ms. If you could take a full frame snapshot of the CRT with an exposure time of 10 ms, starting at 0 ms and ending at 10 ms, you'd see a white horizontal strip that starts halfway down the screen, and the thickness of this strip is a tenth of the height of the screen (since it lasts 1 ms, which is a tenth of the vertical scanning duration for each CRT frame).

Our rolling shutter, however, will integrate information differently. At T = 5ms, the shutter is (5/16.7) ms across its width. At T = 6ms, the shutter is (6/16.7) ms across its width.

Assume that the width of the CRT screen matches the width of the viewing angle of the video camera.

The resulting integrated image will have a partial horizontal white strip whose left edge starts at (5/16.7) of the frame width, and whose right edge begins to disappear at (6/16.67) of the frame width. The falloff of the right edge into blackness depends upon the phosphor persistence.

Ok now walk me through the rest - how do you use this idea to calculate relative input lag, and why do you need to stack the displays on top of each other?