Emprex 3202-HD TV deinterlacing and input lag review using piLagTesterPRO - a tail of an extra frame buffer and poor sync
This 720p TV has 2 component inputs, 2 HDMI, and VGA. It's a bit of a hot mess but an interesting test case for the piLagTesterPRO because of how it handles vsync and 60hz sources.
Image quality
The display is 720p but in an incredibly rare design choice it's actually pixel perfect at 480p/i, with zero (yes, zero) aliasing. There is only minor cropping, about 15 pixels off each edge. Unfortunately, at 720p, the "native" resolution, it is aliased pretty badly, in addition to cropping a lot of pixels off each side. Crazy. It would be an interesting retro gamer option if the deinterlacing/input lag was good: a great 480 image and an ok 720p image for more modern system.
Input lag measured with a piLagTesterPRO
This display does not have a game mode. I used a piLagTesterPRO to measure input lag. This device sends a frame of video over HDMI and measures how long it takes to display it.
summary/comparison:
full data:
This TV has the distinction of having the worst input lag for 480i I've ever seen. For progressive content it's actually decent, on a lucky day.
Image quality
The display is 720p but in an incredibly rare design choice it's actually pixel perfect at 480p/i, with zero (yes, zero) aliasing. There is only minor cropping, about 15 pixels off each edge. Unfortunately, at 720p, the "native" resolution, it is aliased pretty badly, in addition to cropping a lot of pixels off each side. Crazy. It would be an interesting retro gamer option if the deinterlacing/input lag was good: a great 480 image and an ok 720p image for more modern system.
Input lag measured with a piLagTesterPRO
This display does not have a game mode. I used a piLagTesterPRO to measure input lag. This device sends a frame of video over HDMI and measures how long it takes to display it.
When I first tested this display I thought I had found a bug in my code or an obscure hardware bug in the raspberry pi. The lag wasn't fixed; instead it slowly increased and eventually wrapped around to a smaller number. This behavior is shown in the figure below.
As you can see it's very consistent. The minimum lag recorded is 35ms and it slowly grows to 51ms and then jumps to the minimum value again. The same sawtooth pattern is seen in the response time as well. I also own an OSSC modded to do lag testing and I didn't see this behavior with that device - it reported a consistent value. There turns out to be a difference between how these two devices are configured, however. The OSSC outputs the NTSC refresh rate (59.94hz), whereas the Pi defaults to 60hz. But once I configured it to use the NTSC refresh rate (add "-t" to the tvservice command), it behaved like the OSSC, showing a constant lag value (and the Pi/OSSC were in reasonable agreement on that value).
But I noticed it wasn't the same value between days. If I unplugged and plugged in the OSSC or Pi without power cycling the TV they would show the same value, but every time the TV was power cycled I got a new value for lag (always between 35ms and 51ms). I never found official documentation for what's going on here, but I think I have a pretty good idea.
The TV (and I have since found at least one other TV by LG that does the same thing) can't display any other refresh rate than 59.94hz. Generally that's fine, as that's the common frame rate in the US, but you will run into 60hz sometimes. The TV could just barf and show no picture, but instead they added extra hardware to display the 60hz signal at 59.94hz. What they do is have an internal frame buffer, which grabs the signal sent over HDMI (or whatever) and saves it. Then every time the TV wants to start drawing a new frame it uses that frame buffer, instead of whatever is coming in over HDMI. Since 60hz is faster than 59.94hz, eventually the TV will get a full frame behind the input; the TV solves this simply by dropping that frame. It does it somewhat intelligently, I never saw any display tearing.
This is a respectable solution to allow different input frame rate to be displayed on a fixed scan rate display. Aweful for gamers, but still preferable to dieing for 60hz content. What's crazy is how it behaves given a 59.94hz signal. You'd think the framebuffer would no longer be needed, or at least the TV would synchronize with the input. But it doesn't. Instead the TV starts drawing some fixed period of time after it's turned on, with no attempt to synchronize with the input's vsync. So one day your input lag will be 40ms, and the next it will be 51ms, and on your birthday it will be 35ms. At least it stays constant (or at least very close to it, there's possibly some drift but I didn't feel like recording for half an hour to catch it).
This might have been a feature, actually. I own another device made for people who cared about video quality and had money to spare: the DVDO VP50. It cost $2500 new, and by the time I purchased it used 10 years after being discontinued it still cost me $150. One of its features (thankfully togglable) is to generate its own fixed sync signal (and, presumably, display from an internal framebuffer, just like this TV). In the DVDO manual they explain this allows for a "smoother/quicker" transition between inputs. Well, not everybody is a gamer, and not every gamer cares about input lag.
So, back to our regularly scheduled review. After all that it's pretty clear this device isn't for anybody reading this post, but since I collected the data...
I report two kinds of values. The minimum lag is the earliest point any change is detected at the top of the screen. This overly optimistic value doesn't tell you how long it takes to see anything useful, but matches what other reviewers use. I also report a more realistic measure of lag: when the display has reached 80% of full brightness at the bottom of the screen. This combines both input lag and response time, and is closer to what you would actually experience in a game. FYI these are the averages, so on power on your actual lag will be +/-8ms of the table below.
summary/comparison:
full data: