PDA

View Full Version : Black Frame Interleave for LCD Displays


Isochroma
5th April 2006, 06:27
I've been spending some time researching LCD and plasma displays for my near-future home theatre setup (with PC input feed, of course!).

There are many advantages and disadvantages to both LCD and plasma displays for this application. At this point in time I'm leaning toward LCD for its superior lifetime, higher reliability, and higher resolution.

Despite its black level problems (solved soon by dual-panel sandwitching or other neat new ideas!), the advantages of LCD are many, so I've decided to give it a try first.

Besides black level, one other item stands out as a certain disadvantage of this display technology: motion smear. Due to an LCD's sample-and-hold characteristic, video frames persist until overwritten by the next. By contrast, a CRT's phosphor fades to black between frames, 'cleaning' the retina of image persistence.

Some manufacturers are beginning to address this problem. LG.Philips showed an LCD with 120 Hz. backlight (http://ultimateavmag.com/features/106ces2/index2.html) at CES 2006, for example.

The problem with a strobed backlight is that its oscillation rate is arbitrary and is unlikely to match the video's native framerate - ie. 23.976/24/25 Hz. vs. 60/120 Hz. There is not yet any panel on the market that can detect native framerate from image analysis.

So pondering upon this problem, and also realizing that LCD monitors/TVs will become the majority of the market very soon, I realized that a simple software solution, implemented in ffdshow for example - could be used.

The proposal is to add a frame-doubler to ffdshow. It just duplicates frames by an integral number, and inserts black frames in the user-specified number of extra frames. Say I had a 24-fps file and played it on a 72 Hz. LCD. In this case, the framerate would be increased 3x to 72 FPS by duplication, except that the last frame of every 3 would be black. The LCD would strobe at 24 Hz., but since only 1/3 of the frames would be black it wouldn't be too visible (hopefully). If flicker was too apparent, a luma-reduced frame could be used instead of black.

Such a filter shouldn't use much CPU, and since ffdshow can accept raw formats it can be used as a postprocessor for any other decoder.

This would allow LCD owners to completely eliminate motion smear without having to wait for manufacturers to slowly implement their inflexible and cumbersome 'solutions'.

Perhaps even a simple avisynth script plugged into ffdshow could do the trick? I'll think about it and add some more tomorrow...

mod
5th April 2006, 14:19
I have a 32" LCD Monitor I use as a computer monitor, The Viewsonic V3200W
Nice start :) (isn't N3200W?)

@Isochroma: did you try some particular display and note that the problem couldn't be ignored, or you have read docs somewhere? In case you have tried, how many inches?

Isochroma
5th April 2006, 18:38
Maybe buying either a Toshiba 37HL95 or Panasonic 37PHD8UK in 9 months time. The plasma has the 'advantage' of having a 60 Hz. strobe, which cleans the retina between frames.

Truthfully, I've never seen this problem on LCD displays yet, but maybe it's important - maybe not?

Perhaps this forum ought to have a section for display hardware, since the display is a very important part of both editing and watching video.

Shinigami-Sama
5th April 2006, 18:42
Maybe buying either a Toshiba 37HL95 or Panasonic 37PHD8UK in 9 months time. The plasma has the 'advantage' of having a 60 Hz. strobe, which cleans the retina between frames.

Truthfully, I've never seen this problem on LCD displays yet, but maybe it's important - maybe not?

Perhaps this forum ought to have a section for display hardware, since the display is a very important part of both editing and watching video.
I think it was sugested once or twice, but I'm all for it
but I've never had a problem on laptop's display, only on ultra high chroma shifts, AKA playing a FPS, even then its not that noticable, seeing as how I'm the only one out of 10 people that noticed it, so I wouldn't think its a big deal execpt on some of the older displays

jggimi
5th April 2006, 18:55
I think it's very important to see your prospective monitor in action prior to making a decision. If for no other reason than you can make a side-by-side comparison of two displays with the same video source at the same time.

A couple years ago, I acquired a projection LCD tv, and did so only after seeing that images on this model did not appear to suffer from any motion smear that others had. Smear was most obvious on others with text.

I do not know why this was the case, but it was a key factor in settling on that particular model (Panasonic PT-50LC14).

Mug Funky
6th April 2006, 04:16
i think you could test this out pretty easily with an avs function, just as a proof of concept.

it'd be interesting to see how the monitor behaves - white-to-black decay tends to be a fair bit longer than the "grey-to-grey" response time that is usually cited with the display. it's possible the flicker will be quite visible, or it'd change the dynamics of the display (like reducing gamma). sounds interesting though.

[edit]

just tried a simple interleave(last,last,blankclip(last)) and it showed a little promise, but the machine just couldn't keep up with 75fps (monitor refresh is 75hz, but who knows what's happening between virtualdub and the graphics card).

Isochroma
6th April 2006, 05:36
Too bad... thanks for trying at least! I don't have a LCD (yet!) so can't test except for CPU usage. Guess we'll have to count on manufacturers to figure something out, or maybe convince Nvidia/ATI to do it at the driver level...

Soulhunter
7th April 2006, 13:16
Maybe it would be faster via shader function in MPC!?


Bye