Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects


Blog Archive

The video level mess in Windows

I've gotten so many reports over the years about mismatched YCbCr video levels in VirtualDub and had to explain the situation so many times that I'm tired of it... even though it is important. The level situation in a simple video workflow often involves hardware and software from at least half a dozen vendors and therefore no one can unilaterally solve the problem, thus resulting in frustration for everyone. This is the issue that sums up the situation best, though:

On some but not all systems, you will get different black and white levels between these two modes, meaning that software and hardware color conversion are inconsistent. Even worse, this only happens with videos where YCbCr decoding is active -- use a RGB uncompressed stream or a decoder that outputs RGB, and you won't have this problem. Regardless of who's correct, this leads to the unhappy situation where it is impossible to encode a video that displays properly on everyone's system, and pretty much anything you try will be wrong in some way. It also means that if you haven't noticed this particular issue, and were using your player to calibrate your pipeline, you may have done so incorrectly. Joy.

Compounding this issue is the "two wrongs make a right" problem -- you may have two stages in your workflow that are both using the wrong levels, but the two cancel out. An example is that if you have 16-235 input coming in, but your encoder is interpreting that as 0-255 and the decoder is also producing 0-255 while the display code is expecting 16-235. This works out great until you already have a video playing when you try to examine another one, at which time the second player drops out of acceleration mode because the hardware overlay is already in use, and the decoder attempts to convert YCbCr to RGB in software and whacks the black and white levels.

Ultimately, I think that only Microsoft is in a situation to fix this, since only it controls the APIs and has enough clout to spec out and propose/push a solution to the codec and driver vendors. There are multiple problems involved: formats whose levels aren't defined, formats that don't have a way to specify levels, and formats that are specified but for which modules are accidentally or even willfully violating the spec. I don't have high hopes for a solution soon, though, after what I saw happen to the Direct3D overlay API, which was an API that had level options defined from day one and also ended up being fatally broken from day one.


This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.