How do you get the blackest black when rendering in H264?

[ohnoeee]

I'm rendering a video in Vegas video out in a H264, and the result I get is a saturated lighter black than a pure black. What could be causing this?

[Munster1]

I just rendered 10 seconds of black using Mainconcept in Vegas, which seems ok on my system. How does it appear to you? What are you using to judge the "blackness"?

[guns1inger]

I suspect it is related to NTSC's IRE setting, which prevents NTSC getting pure black

[edDV]

I just rendered 10 seconds of black using Mainconcept in Vegas, which seems ok on my system. How does it appear to you? What are you using to judge the "blackness"?

Your black is at digital zero, not 16.

[edDV]

I'm rendering a video in Vegas video out in a H264, and the result I get is a saturated lighter black than a pure black. What could be causing this?

What is your source?

What are your encoder settings?

There should be no levels shifting during h.264 encoding. It would help if you post a before and after h.264 encoding sample.

Luminance is normally defined as 16-235 with excursions allowed up to 255.
This applies to DV, DVD, MPeg2, AVC, ATSC, DVB, Blu-Ray, etc.

Some 8 bit devices expect 0-255 black to white.

[jagabo]

Actually, your black as at Y=1. Y can go as low as zero but y=16 is defined as black in the spec. You shouldn't be going lower than Y=16 except for occasional overshoots. If you aren't seeing Y=16 as total black* on your display when playing in a media player (and all values from 0 to 16 should look exactly the same) then your graphics card or monitor is misconfigured.

* most LCD monitors cannot display total black. But what you should see at Y=16 is a black as black as your monitor can display. And you should not see any difference between Y=16 and Y=0. Both should be the same shade of black.

[ohnoeee]

I get same effect with H264 that I do with xvid mpeg4. Mainconcept can get the right black levels, though I think it distorted some other colors in a different part of my video, in terms of saturation and making fading to black look like to blocky of a transition..


Ok, this is going to sound like the dumbest question... but what's the best divx pro software to download, if I want to be able to encode in divx? Every Divx package I get wont let me render in divx through ffdshow (or at all because it's some other kind of divx codec) like I was able to on a different laptop.

[jagabo]

sample h.264.avi is encoded with correct levels -- black is at Y=16, white at Y=235. The mainconcept sample has the wrong levels with black at Y=0 and white at Y=255.

[Munster1]

The file attached is a Y=16 black rectangle on a Y=0 black background rendered the same way as my earlier file in this thread. The encode seems to change Y=0 to Y=1.

With MPC-HC playback set to 0-255 output range I can't see a difference (both blacks go to Y=0). With it set to 16-235 output range I can see the not quite as black rectangle (as I also could in the Vegas preview). In Photoshop I can also see the difference between the blacks. Does this all sound right?

The monitor is a Samsung SyncMaster 2032MW connected by VGA to a Nvidia G210.

[ohnoeee]

Yeah, that's the kind of black level I'm getting. Is there some way to change it?

Also, would divx do anything different for it? Not that it matters right now, because I can't use divx in ffdshow like I used to. BTW, What version of divx would I need to install to make it work in ffdshow again?

[jagabo]

Yeah, that's the kind of black level I'm getting. Is there some way to change it?

For media players adjust the video proc amp settings in the graphics card's setup applet. I don't use Vegas but I believe it doesn't expand the contrast (converting Y=16-235 to RGB=0-255) by default for display. I think there's an option to adjust that somewhere.

Waveform levels graph of sample h264.avi (correct):


Waveform levels graph of sample - mainconcept.m2t (incorrect):


The waveform should not extend into the brown/yellow areas of the graph.

The actual video image in those two pictures have been adjusted for display. Ie, they have gone through the normal contrast stretch that any media player (including Blu-ray and DVD players and TVs) should perform when playing the videos. Notice how the details on the characters shirt have disappeared in the mainconcept encode.

The mainconcept video is encoded incorrectly. It looks better on your computer because your computer is maladjusted.

Also, would divx do anything different for it?

No. All MPEG family video uses Y=16 for black, Y=235 for white.

[ohnoeee]

Yeah, I guess mainconcept is a little too dark. I just wanted to get the same contrast level that I was getting through the preview window... I guess I'll just stick with xvid mpeg4. Thanks

[jagabo]

Yeah, I guess mainconcept is a little too dark. I just wanted to get the same contrast level that I was getting through the preview window... I guess I'll just stick with xvid mpeg4. Thanks

Just fix your computer/software so that it's displaying the video correctly.

[poisondeathray]

I just wanted to get the same contrast level that I was getting through the preview window...

The preview window in vegas uses studio RGB (Y'CbCr gets converted to black at RGB for display at 16,16,16 instead of RGB 0,0,0) if you are using 8-bit mode

If you want to see temporarily how it would look like, use a StudioRGB to ComputerRGB filter (but disable it upon export) . This will remap black to RGB 0,0,0 , and white to RGB 255,255,255 - as it is for sRGB that most other programs use

Vegas handles different import and export formats differently. For example exporting h264 the levels will be handled differently than wmv exports. Importing uncompresssed IYUV will be handled differently than say, importing a h.264 video wrapped in a mp4 container. Native camera formats are passed through as Y'CbCr (so something like DV-AVI, or AVCHD) , but if you use filters, color correction, they will undergo studio RGB conversion (black mapped at 16,16,16)

You can read more about this:
http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm
http://www.glennchan.info/articles/vegas/colorspaces/colorspaces.html

[Munster1]

Importing the sample h264.avi from ohnoeee into Vegas results in the levels being expanded to 0-255 on the timeline. Is there a way to avoid this?

Also, the glennchan.info articles state the preview window in Vegas uses computer RGB not studio RGB.

[poisondeathray]

How do you have it setup for the scopes? (studio rgb or not - push the little button beside the drop down menu where it says "histogram") ? This doesn't affect the actual data, only the range of the way the scopes appear.

You can use ComputerRGB to StudioRGB preset. This will make black at 16,16,16, white at 235,235,235

This is not the same thing as Y' 16 or Y' 235. Legal range video is Y' 16-235 , not RGB.

Also, the glennchan.info articles state the preview window in Vegas uses computer RGB not studio RGB.

This depends on the input format, and the version of vegas used. Vegas also converts BACK to Y'CbCr differently when you use different export formats (e.g. wmv is handled differently than h264) . Most native input formats will be converted using StudioRGB (by native, I mean straight from the camera, like DV-AVI etc....)

RGB is RGB. The problem occurs when you convert Y'CbCr to RGB , ie how do you "map" Y' to RGB

Studio RGB means Y' [0,255] => RGB [0,255] . So for a "normal range" input legal video, Y' is 16 black, Y=235 white. This means RGB will have 16,16,16 - 235,235,235 if you're using studio RGB

sRGB means Y' [16,235] => RGB [0,255] . So for a "normal" legal video where Y' [16,235] , RGB will be 0,0,0 - 255,255,255. Notice that the "superwhites" and "superdarks" are clipped in this conversion

You can change the behaviour for some input formats by using 32-bit (using full range option , vs video range option).

[Munster1]

The Studio RGB checkbox is ticked.

[poisondeathray]

On computers and monitors "black" is RGB 0,0,0 , white is RGB 255,255,255 . This will also depend on how your graphics card is set, and monitor calibration etc...

In video "black" is Y' 16 , white is Y' 235 . This is "legal range" video. But how you "see" a video is dependent on how that software converts to RGB for display

If , for some reason, you want black at RGB 16,16,16 and white at RGB 235,235,235 , then use the computerRGB to studioRGB preset. Try this out and watch the scopes

BTW, sRGB and "computer RGB" mean the same thing. It looks like vegas is using compurter RGB or sRGB to decode that AVI (which is how 99% of other programs would do it) . "Native" formats are handled differently. They usually use studio RGB in vegas

Getting OUT of vegas is another issue. If you export an RGB format. Then no problem. RGB is RGB. The confusion occurs when you export out a Y'CbCr format, because vegas does the RGB=>Y'CbCr conversion differently for different formats

If this is too confusing, you will have to run some examples and see for yourself

[poisondeathray]

man , what a piss poor explanation. I just re- read what I wote.

Sorry I was typing something for another site at the same time. If it's still confusing just ask

The h.264 AVI is not a native format. So Vegas will use ComputerRGB for the Y'CbCr => RGB conversion . If you look at jagabo's waveform screenshot. It shows legal range ~Y' 16-235 . ComputerRGB means Y' [16,235] => RGB 0,0,0-255,255,255 . That's why you see the luminance portion of the histogram as such.

RGB is RGB. All "computer RGB" and "studio RGB" indicate is how RGB was achieved. ie. how was the Y'CbCr => RGB conversion done

Vegas can work in Y'CbCr if you use a native format (like DV-AVI, or HDV). This means no RGB conversion is done internally (the preview still is converted to RGB for display, but internally you are still working in Y'CbCr) . As soon as you use filters or color correction, then there is an RGB conversion

Is that more confusing

[Munster1]

I think it's clearer now. Thanks for the explanations.

Therefore, in the case of the sample avi above, if I wanted to export that clip as AVC I should perform the computerRGB to studioRGB levels adjustment first before rendering out to Mainconcept or Sony AVC.

[poisondeathray]

Not necessarily; Vegas handles that final step differently (converting RGB back to Y'CbCr) . For some formats, it "expects" computer RGB converted levels, for others it "expects" studio RGB converted levels

I don't use Mainconcept or Sony AVC. If I use vegas, I always export RGB and use other programs to control the RGB=>Y'CbCr conversion

But I know from experience vegas will treat , for example sony avc vs. wmv export differently (ie. the RGB=>Y'CbCr conversion will be different)

Usually if the video export looks screwed up in terms of levels, you either use the computerRGB=>studioRGB or the reverse preset. That will fix 99% of the cases

But how you view that exported video is also important. How are you determining levels or the appearance of that exported video, because remember you're not looking at Y'CbCr directly, you're looking at the RGB converted representation of it. Also things like video renderer, grahphics card, player settings etc.... affect how it "looks"

*All the confusion occurs because of RGB<=>Y'CbCr conversions - video is usually Y'CbCr. So there is usually one conversion upon import and one upon export. (and one more again when it's viewed in your media player)

[Munster1]

The glennchan article suggests that Mainconcept expects studio RGB levels, but it doesn't mention Sony AVC.

I guess I'll have to experiment to see if it's the same.

Thanks for all the help.

[poisondeathray]

Actually that chart "Tables of Codecs" refers to DEcoding (importing) the footage.

If you look at the 1st 3 rows, AVCHD, HDV - those are native camera formats. So they use studio RGB in 8-bit mode (superbrights and superdarks are retained)

What I'm talking about is exports. Exports are also handled differently .

[Munster1]

Are you sure? The table and the article in "Color spaces and levels in Sony Vegas 9 and 10" gives the impression it's talking about imports and exports.

[poisondeathray]

You're probably right. You'll have to test it out. I did a bucketload of tests, and some things were different between 8 and 9 - I havent tested 10. I rarely use vegas these days, but if I do, I avoid all these issues by controlling the RGB conversion (in and out) with other programs

Even "uncompressed YUV AVI" is handled slightly differently in vegas. For example , fourcc "IYUV" is handled differently than "YV12" . It uses studio RGB in the former, computer RGB in the latter

[jagabo]

What a PITA Vegas is!

[poisondeathray]

What a PITA Vegas is!

HAHA. It has a lot of "quirks" , but for the actual editing and interface, it's really an exellent NLE

Other NLE's have different "quirks" just as bad or worse

Getting your head around color spaces, Y'CbCr, RGB all that stuff is a headache. Actually jagabo you helped through all that back in the day

[jagabo]

I know Vegas is a good NLE but why are there so many problems with YUV/RGB conversion? Why aren't the consistent? The rule is pretty simple RGB=0-255, YUV=16-235. There are only a few exceptions. Why would it treat IYUV and YV12 AVI differently? That makes no sense.

[poisondeathray]

Yes it has a lot of weird quirks . The basis for all the YUV/RGB issues is the choice to use studio RGB in vegas. I don't know of any other program that uses it. But then why doesn't it use studio RGB for everything?.... I don't know.

IYUV has the chroma plane order swapped vs. YV12 . It "unlocks" some "special sauce" for some reason, but not only in Vegas. Some other programs treat it differently as well. For example, you can encode in quicktime h.264/mov using IYUV input without the gamma shift bug. But YV12 undergoes that extra RGB conversion before h.264 encoding, so you get the dreaded gamma shift bug.

All the QT gamma shift issues for Macs is from YUV/RGB conversions as well, but instead it's a 1.8 gamma issue for the conversion, not a studio RGB issue

Life would be so much simpler if everything was RGB. But we need more bandwidth