¶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:
- Launch Windows Media Player.
- Play a video.
- Go into Tools > Options > Performance, and change the video acceleration level from Full to None.
- Play the video again.
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.