LCD Lag: An Issue? Or the New Normal?

[ZaCloud]

I started an offline-message-exchange with AC about this, then realized that maybe it'd be relevant for all of us to discuss.

Basically, while looking at computer upgrades and enthusiastically considering an LCD monitor, my gusto quickly dropped when I realized that lag is still an issue with this technology. Even the latest and greatest that boast reduced lag... still have lag.

This got me thinking about the ramifications this might have on AMV timing. I mean sure, a split-second may not seem like much... but when you're editing to split-second beats, it can mean plenty.

I just don't know how much of an issue it actually is, so I'd like to find out more. I have an old CRT that's been good to me and outlasted countless computers, but of course would like a healthier, lighter, and more colorful alternative since the tubes are fading. And more and more people are getting LCDs. But, plenty still have CRTs... and might not have the same AMV experience.

Sephy, did you edit your "Path of Advent" and "Advent: Revolutions" vids on LCD or CRT? Because remember, I pointed out that some of the timings looked consistently "off" but you insisted they were fine on yours. I knew for sure that it wasn't sloppy editing or anything; as I said, it was consistent. But, it was noticeable.

Likewise, AC's masterpiece "Random Acts of Azuviolence." The timings are precise and in rhythm... and on my screen, a tad bit too early. Not greatly, not too noticeable if I'm not looking for it, but it's there.

Now, it could be chalked up to editors' style: Some make use of the visual waveform in Adobe Premiere and time their screen-flashes/scene-changes and such to match the spikes on the waveform. While this is technically correct, the human brain perceives visual signals before audio signals. This is why some editors will instead opt for what "looks right", which is a method I lean toward myself. I compensate for "human lag" by letting my visual fall ever-so-slightly after the audio cue in most cases. I fine-tune this until it looks right... but that's been on my CRT monitor.

I haven't done enough intensive timing videos since moving to the more frame-accurate Premiere for me to ask this, but do my timings look ok on LCDs, or do they look way too slow and mushy? (Yeah... like I said, might not be enough to answer that currently... But I wonder it though)

If your monitor is LCD and lagging, and you use visual-spike editing, it might look perfectly fine on your monitor... but too early for folks on a CRT. Or even if you go by what "looks right", you'd still be going by the sound of the audio, which wouldn't fall in the same spot on your monitor as a person with CRT. Get what I'm saying?

Anyway, all this begs the question... Should we all edit for it to look right on LCD monitors since more and more people are upgrading to them anyway? Or should we keep CRTs in mind since many still use them? This question's half of why I'm not hands-down on getting an LCD in the near future.

And on the other side of the coin... TVs. More people are getting LCD TVs or other formats of digital TV-watching which might or might not also have lag. But plenty still have some that don't. Will our considerations still work for one but not the other? Our videos might be shown on such formats... And what about projectors at conventions?

It's not a completely dire issue; all your vids still play amazingly, it's not like a "game-breaking" glitch... but for some high-speed vids one might consider doing, or for certain nuances, it could indeed sully the experience for the viewer. Which is why I find it a relevant issue to experiment with, and see just how much of an issue it really might be.

[Sephiroth X]

I've seen no problems with any of your AMVs on LCD displays, so my response to your main question is a thankful 'no'.

I'd lean towards making things LCD display oriented since most AMV makers & viewers are going to them, if not on them already, and considering most major vendors do not make or even sell CRT displays anymore it seems kind of pointless to cater specifically to, what is now, very obsolete technology.

However, just to throw another variable into everything. What you suggest is very likely, and probably, just a case of LCD lag. However the only way to make sure would be to take the exact same computer tower and hook it up to a CRT and LCD display and see if the same timing hiccups occur. Because we still haven't looked into the notion that one persons computer might just be a half second behind because of a CPU or other form of bottleneck. The reason I mention this is because the common LCD monitor on the market today carries a 4-5ms response time, which means that everything appearing on your screen is going to be 0.004 or 0.005 seconds behind. While the picture is not instant with what's actually happening, it's reaching the level where the human eye may not be able to detect it or have trouble detecting it.

But my final analysis; yeah I'd put focus on LCD instead of CRT considering even LCDs are technically obsolete now thanks to LED displays.

[AltruisticCrono]

I'll agree with X on this one.

There's going to be more variability with the computer setup, listening environment, and editor preference rather than just purely the LCD's 2ms-5ms (majority on Newegg.com) lag. Going with LCD will increase your purchase options, space, and portability (important for gaming abroad!).

When strictly editing, clips are placed on the timeline at a slow pace and with human oriented decisions. In light of the discussion, I'll keep the viewing consideration in mind when dealing with frame specific timings.

I've edited for both spike and "feel" of timings, but mostly gone with audio spikes - which can be time effected by many things (pre/post processing and editing suite quirks) as well. In the case of my RAAV AMV, the quick flashes are severely diminished in quality without video acceleration. Some AMVs are even mistimed on Youtube from the framerate / compression conversion differences.

[whicker]

I ask, if I may, be allowed to interject.

What I personally would call "lag" would be a delay in responsiveness between two points of measurement.

Let's take a classic example of Television lag. An event, like a baseball swing hitting a ball occurs, and is being recorded on camera and by microphone and sent wirelessly.

Now for some odd reason a fan sitting nearby in the bleachers has a portable television. Whatever, he likes the announcer or whatever. Obviously, the fan is going to see the real-life event first, and then see it on the television 500ms to 2 sec, or so, later.

Depending on how far back the fan is sitting, he might see the bat hit the ball, and then hear the sound some significant fraction of a second later. So far, we're dealing with reality here.

Now, if this fan is really observant, he'll notice that on his television display, the sound and the video are synchronized. But hey, it just so happened I'm sitting right by the camera that recorded this, how can this be?

Well, to answer that immediate question, the microphone recording the sound is near the batter, and since once the signal is represented electrically, it should be traveling at near the speed of light, it shouldn't be an issue. And if there is an inherent delay one way or the other, then either an audio delay line could be added or microphone guy needs to stand closer.

Okay fine, what am I getting at? People are probably expecting the distance of them from the TV (and paradoxically not the distance involved between the camera and the subject) to be the deciding factor in audio/video mismatch.


OK fine, where am I going with this? You'll see, but I'm not there yet.


Now throw in the processing that people have come to expect with their brand-spanking-new LCD televisions. This is an unsupported statement, but let's just say, the way the NTSC signal works, is based off of how a CRT tube can be operated easiest with the simplest circuit components.

However, LCD based panels cannot be electronically driven the same way, each dot is unique and color intensities quantifiable. Not just 525 lines of analog smear between the left and right of the screen.

Throw in the fact that people don't want dot crawl, which would be hugely noticeable on these huge, crisp displays, but that people and cable companies wanted to keep their muddy RF connections. So enter DSP, which says you can increase samples to get more resolution. Well, since you can't "speed up" the broadcast signal (or otherwise look ahead into the future), you're going to record in memory a handful of frames, maybe 3 or 5, and then come up with an output that is signal processed to look pleasing. However, now it's going to be "behind" maybe 1 to 3 frames as it's a combination of past, present and "future". Or rather way-past, past, and now but let's not be too confusing. At 29.97 frames a second, 3 frames is 100 milliseconds. There is going to have to be an audio delay of 100ms.

Now, some spendy dude doesn't like his TV's speakers (who does?), and wants to circumvent the whole TV, and use an audio receiver, bypassing the TV's audio output. Audio comes before video, and you can get used to that. Or really annoyed.

...continued

[whicker]

Now we have the wonderful world of Personal Computers.
The eternal demand for the cheapest components at the cheapest price at the cheapest software driver development cost.

The audio delay of your sound card is not standardized. Why do you say there is a delay? Because with all that wonderful "crapware" installed, and celery processors, and integrated video tied into system RAM, there's going to be variable "latency" or unpredictability on when the CPU is going to be able to service the audio driver with a new chunk of data. Yes this is really stupid and counter-intuitive, no the audio chip cannot cycle steal and play directly from RAM memory.

In microspeak, this variability is termed DPC Latency. "I need that audio sample right now, but how long is it going to take for me to actually get it?" The audio buffer is going to need to be big enough to cover the majority of DPC latency spikes. But a 50ms buffer (the actual number of storage cells would be determined by say a 44.1KHz sample rate), is going to delay the audio by 50ms.

Let's say the wonderfully kick-a-round emachines notices their audio garbles regularly, calls up their chip supplier, they "just increase the buffer size". Well, YOU THE END USER CAN'T CHANGE THIS. Your software program can have a buffer, but the underlying driver's buffer size is inaccessible and variable.

As for VGA video, again the signal was based on how a Cathode Ray Tube works, and an LCD monitor is probably going to need to sample at least one whole frame before it displays it. I suppose there also is a three-scanline strategy one could use. Nobody quotes these numbers.

Everybody cares about phosphor or cell "persistence", which is how long it takes for a pixel of one color to change to something else. Ghosting would be a phenomenon between how the virtual objects appear to our visual system differently from real objects. This is the 2-4 ms number that gets quoted. An LCD that waits to sample one whole frame at 60 fps before displaying, is going to have a lag of 1/60th second = 16.67 ms.


So where is all this going? With all this unpredictable lag, you're just going to have to match it up knowing your audience. If you don't know your audience, you'll probably just want to match a video event exactly with audio.

I guess our much touted VLC media player has track synchronization, where you can adjust this to personal preference, but would get tiring for short clips that are all over the place. If there is an actual PC audio-video-human input latency standard, I'd love to see it.

Frame dropping is somewhat of a science. If a hiccup causes it to take the time of 3 frames to decompress one frame, do you display that decoded frame late? Whatever is showing, is now 2 frames behind audio. What if this keeps happening? Now your audio has to start delaying.


Blah, what's my point? It's complicated. There's all sorts of latency everywhere.