Take a look at this screen capture from a video file.
The video itself is just a black (R:0, G:0, B:0) matte. Or at least, it is supposed to be. Notice that the 16:9 video portion is actually dark grey -- much lighter than the surrounding true black border. I only noticed this recently, even though it has probably always been this way on my computer. Almost all of the video watched on this computer is from youtube, which goes through a different video display route than DVD video or video played from individual files.
Initially, I thought the problem was caused by Premiere itself. I created a very simple video with just a few seconds of solid black matte. When viewing the preview window in Premiere, it looked fully black. After encoding into MPG, it looked dark gray. Clearly, it must be a problem with Premiere or its encoder. I was encouraged by this bug report:
http://forums.adobe.com/thread/387845
http://forum.videohelp.com/threads/309449-Adobe-Premiere-MainConcept-s-H-264-vs-x264-open-source-encoder/page4
After upgrading to 4.0.1 and spending many hours fighting with codecs, filters, shaders, etc, I discovered that my video card driver actually has the final decision about black levels. Even if all of the video decoding software outputs a "0", the video card driver may still adjust this to be dark gray in order to be compatible with analog television output. I had to upgrade my Nvidia driver, which now includes the option to actually use 0-255 range in the video output.
The alternative to 0-255 range is 16-235. I guess analog TVs and maybe even digital TVs are setup to display a value of 16 as complete black and 235 as complete white. Why? I have no idea. It might have made sense when dealing with an analog signal, but it makes no sense with digital signaling. The difference in tonal range is technically known as pc.709 and rec.709. If you start reading about color spaces and transfer functions, your head might explode. Just try searching for YUV rec.709 YUY2 YV12 4:2:0
This is helpful:
http://avisynth.org/mediawiki/ConvertToRGB
I recall that extra color space was used for live keying. It's been a long time though since I've even thought about it. It was late 90's when I last had to modify video footage to compensate for it and even then it was only to comply with broadcast standards so it might have been used for something else initially. I do know that levels outside that range would sometimes cause buzzing to hapen in the audio on analog signals so maybe that was initally used as a buffer to help deal with those earlier/noisier analog signals....
ReplyDeleteThe +16 is known as Pedestal, and it's added during active video to ensure that glitches "blacker than black" aren't mistaken for the beginning of the horizontal sync. Color space conversion is a royal PITA (having done alot of it), but there's a really good treatment of it in "Video Demystified", by Jack.
ReplyDeleteCheers - Todd.
Thanks for this! Fixed on my computer now, it has been wrong for years. Found your site on the hackaday-blog.
ReplyDeleteDennis
Sweden
The 16-235 range is a carry over from the first digital video systems from the 1970s, which worked by sampling and storing the analog signal itself, they had no concept of color channels or even pixels. The entire waveform was stored including sync pulses, which shoot over and under the bounds of the picture voltage range. Storing luma values in this way allows an 8-bit DAC to also generate the sync pulses without having to scale the picture data into codes 16-235.
ReplyDeleteTHANK YOU SO MUCH for this article I've been searching for hours why the blacks in my exported videos aren't really black. Thanks!!!
ReplyDeleteThank you. This helped stop my building frustration and rage against Premiere.
ReplyDeleteI also found an alternate solution, for VLC only
Go into the video settings and disable the hardware yuv->rgb conversion.
At least I now know that the exporting from Premiere was not at fault.