It's not as easy to see on graphics as it is on a video clip with solid near-black sections. I also don't see anything wrong within Vegas if I import the WMV clip back - however if I play it with with *any other software* such as WIndows Media Player or VLC (which is what I used for screen captures), then the problem pops up.

This is on multiple computers (for many years now), and even when hardware accellerated playback is disabled in VLC (to rule out the video card drivers as a potential cause).

Projects are 8-bit. All files are raw M2T clips direct from the FX1, captured in Vegas. This also used to happen when I used Cineform as my codec.

It's almost like Vegas is setting something non-standard that it itself knows how to handle, but not anything else.

I've seen the same issue with WMEnc (Windows Media Encoder) and I just assumed it had something to do with color profiles. I didn't have time to look further into the issue, and since it looked OK on the target platform (XBox 360) I didn't bother with it.

OK,
when I get a chance I'll have a look see what's happening with WMP.
I'm 99% certain I know what's going on and the fix is as I explained to you in the other thread of yours. There's nothing wrong with what Vegas is doing, if you load the WMV file back and it looks the same as what you had in the first place then Vegas is working fine.
The problem is what WMP expects WMV to be like and that seems to be black is Y' = 0 not Y' =16.

Bob.

Well.. the main thing that bugs me with that solution is that if I adjust the levels, then I can't encode to any OTHER format in Vegas without un-adjusting things. Not to mention that all my previews are going to look far too dark, making color correcting impossible.

And if other WMV encoders are able to produce files that play back "as expected", then what is Vegas doing...

Edit: Something interesting I forgot to mention. Graphics encoded to WMV in Vegas still have jet solid blacks when played back in WMP. It's just video that suffers.

"Graphics encoded to WMV in Vegas still have jet solid blacks when played back in WMP"

Indeed they would because the black level in graphics is different to the black in video. Consider the following, hopefully it'll help you get your head around the issue and why there's no one shoe fits all solution. I'm using purely arbitary numbers here.

Say you have a video system that defines black as 16, any values less than 16 will still be black. Now you have another system, the world of digital photography and computer graphics. Here black is 0. If you put the graphics into video the black still looks black, that's all it can do. If you do the reverse, put the video into the world of computer graphics the black in the video might not look as black as the black in a photo or a graphic.
The problemo unfortunately is further compounded by how monitors are calibrated or more to the point not calibrated or even simply incapable of correctly displaying images.

Bob.

I understand the difference in black levels. However let's say the black in the video is already 16. I'm happy with it at 16. If I encode to a M2T or a MP4, my graphics are at 0 and my video is at 16. The world is fine.

But with WMV files from Vegas... why then do graphics stay at 0 and video gets bumped up to 32 (just pulling numbers here). Instead, if WMVs were expecting everything in "video space", I would expect the new floor to be 16 for ANYTHING, causing video to get bumped incorrectly higher. But what I'm seeing is almost more like a gamma adjustment, or some way it's processing the video that's not right.

As for monitors, I'm using the NEC LCD2490WUXI2 SpectraView version, fully calibrated, so I know what I *want* to see. And WMV's from Vegas isn't it.

However because of all of this I may have found my true love... constant quality MP4s from Handbrake. Wow, the quality I can get with such a tiny filesize. And correct black levels.

"But with WMV files from Vegas... why then do graphics stay at 0 and video gets bumped up to 32 (just pulling numbers here). Instead, if WMVs were expecting everything in "video space", I would expect the new floor to be 16 for ANYTHING, causing video to get bumped incorrectly higher. But what I'm seeing is almost more like a gamma adjustment, or some way it's processing the video that's not right."

If the WMP sets black at 0 to 0 nits (light from the monitor) then 16 must equal something lighter than black. They look different.

If another player sets black at 16 as 0 nits then 0 is still 0 nits, they look the same, negative light does not exist :)

I believe the WMP generally expects black at 0 so video black will look dark grey.

One other trap to be aware of is most video cards provide separate calibration for the video overlay. This confused me no end at first. I twiddled all the settings to no avail, desktop and Vegas monitor did not budge. I left it munged and weeks later played something in WMP and oh dear, a few minutes of panic until I realised I'd finally found something that used the video overlay.

Bob.

m2t/mp4 are both YUV aren't they?
and i thought WMV was RGB colorspace.

Perhaps I should clarify that I'm not expecting my video black to be true black, because I know it isn't supposed to be. "Black" in my encoded video is of course a dark grey (~7.5 IRE) versus the black bars on the monitor, or any graphics I put into the video with true black.

The problem is with WMVs, what I'm expecting to be dark grey is instead a much ligher grey. Check out my screenshots I posted earlier, the black in the 3 "good" samples is clearly not black (you can see "true" black above and below the frames if your monitor is calibrated), and I know that's how it's supposed to be.

Now (please correct me if I'm wrong) the going theory here is that either Vegas is encoding or Media Player is playing back WMVs with "true" black set as 7.5 IRE, which makes my already-7.5 IRE video black much lighter. Except, then, in the resultant file I wouldn't see ANY true black on playback. But I am - fades and graphics still have true black.

Now the last poster mentioned the YUV/RGB thing - I've been researching this and found that, apparantly, improper conversion between YUV and RGB can result in what was originally 16-235 becoming 32-215, resulting in elevated blacks, weak contrast and washed out color, which seems to be what I'm seeing here.

Edit: Thinking a bit further, perhaps the problem here is that MPEG-2 & MPEG-4 expects video to be 16-235 and the players "adjust" appropriately for playback on a PC, bringing 16 back to 0 and 32 back to 16. But perhaps WMV is expecting video to be 0-255, and Vegas is storing bitmaps correctly as 0-255, but incorrectly boosting video blacks to 32 which DO NOT get brought back to 16 when played back.

Color Spaces in Vegas 8 by Glenn Chan may help explain some of your questions.
He's got several other articles on his site that deal with this and similar issues.

Mike

"But perhaps WMV is expecting video to be 0-255, and Vegas is storing bitmaps correctly as 0-255, but incorrectly boosting video blacks to 32 which DO NOT get brought back to 16 when played back"

If that were the case then:

1) When you took the encoded video back into Vegas you would see the difference on the waveform monitor.
2) If you went through several generation of encoding WMV to WMV the image would soon be munged very badly. Vegas does none of this.

Yes there is a RGB to Y'CbCr conversion going on. Trust me Vegas gets this correct.

I created a test. Half screen 0,0,0 and the other half 16,16,16 and rendered to WMV and used WMP to display it. Even the absolute black was not as black as the surround and the video black was lighter still. How can this be?

The answer lies in nView. I can change all of this including display gamma etc in nView. About the only thing it affects is WMP, it even has a switch 16-235 or 0-255. A quick twiddle and I have things where they should be. Not Vegas's fault at all if the player and/or the video card decides to do its own thing.

Bob.