.wmv CHANGED COLORING OVER TIME????

[yabyum]

Okay so here's the deal. I apologize for the caps in title but this is VERY Odd to me and pisses me off.

I encoded a file in .wmv and sent it out. It was basically two phones shot on black velvet, and edited next to each other. It was imperative that the black velvet be completely black, so I changed the levels in post and achieved that look. I *SWEAR* that when I sent it out, the video file looked all black on the background.

Now about 5 days later I re-download the same file and this time it is NOT all black. It looks like the levels were kind of half changed since you can tell on one side that it was shot on black velvet.

IS THIS POSSIBLE??? Was I just hallucinating the first time I sent it out and it really wasn't all black? I highly highly doubt this but I was tired. It's something very noticeable and that I definitely would've noticed seeing as how I edited it to look a certain way.

Encoded in .wmv 720p 30p in vegas with resolution changed to half size of 720p.

 

[Demistate]

It sounds like you're having some gamma shift issues. here are a few things to keep in mind:

• When you encode a WMV, there is a slight gamma shift upwards (brighter) because the encoder can encode pixels that are close to near black easier.
• When Windows Media player plays these files back, they will be shifted back to the correct position.
• Third party players don't shift gamma (like Media player classic or VLC)
• Untill the next OS X Update, macs are at gamma 1.8, while PC's and Video standards are at gamma 2.2 You might be seeing one thing in final cut, and then exporting another thing into your WMV if you use a program like flip4mac.

All I can tell you to do is TEST your export on multiple setups to see if there are any weird gamma or chroma shifts happening. Depending on how hard you are compressing your file you will find that sometimes the color shifts because of the palatalization that is happening with the compression (to make the file smaller)

I've found in practice, that h.264 encoders tend to keep the dark detail better, but if your client needs WMV, you're stuck with the inconsistencies.

 

[JeganRX]

If an encoder truly is INTENTIONALLY shifting the brightness of pixels for easier encoding (this is usually the opposite actually... dark greys tend to get muddy, while pure black remains solid), then you should stop using said encoder, or look into its default settings. For example, some of Cleaner's low-bitrate web compression presets have various color tweaks to aid in presentation (not so much compression).

I predict three possible reasons for this:

- The playback of your final file is at an incorrect gamma (in Quicktime's case, this sadly happens with H264 files, though the file itself is perfectly fine), often set to the TV luma range of 16-235. This is usually due (on Windows) to a choice in video renderer; VMR renderers tend to use these levels on many setups, so I would look into that.

- If you're playing back using the "overlay mixer" (another renderer), make sure your video card's overlay settings are appropriate. Unfortunately, Nvidia's defaults are still not quite right on their drivers, and it's a pain to properly calibrate them; ATI has an advantage in that regard. The solution to the two proposed reasons thus far is to switch to a different renderer (EVR if you're on Vista/7, or Haali's Renderer if you're willing to install Media Player Classic, if you can get Overlay Mixer to the appropriate levels, use it).

- I'd say the client's monitor is off in terms of gamma, but if you see this problem on your end now, it's not likely the monitor (unless you changed something).

 

[Chris Light]

contents settle during shipping.

 

[yabyum]

oops I completely forgot about this thread... sorry guys, here's an update:

I discovered that my monitor I was using at home to edit wasn't color corrected properly (something I knew but just forgot to think about when I made the video). Dumb mistake on my part but that's the process of filmmaking! Just got a Huey Colorimeter today though

 

[yabyum]

It sounds like you're having some gamma shift issues. here are a few things to keep in mind:

• When you encode a WMV, there is a slight gamma shift upwards (brighter) because the encoder can encode pixels that are close to near black easier.
• When Windows Media player plays these files back, they will be shifted back to the correct position.
• Third party players don't shift gamma (like Media player classic or VLC)
• Untill the next OS X Update, macs are at gamma 1.8, while PC's and Video standards are at gamma 2.2 You might be seeing one thing in final cut, and then exporting another thing into your WMV if you use a program like flip4mac.

All I can tell you to do is TEST your export on multiple setups to see if there are any weird gamma or chroma shifts happening. Depending on how hard you are compressing your file you will find that sometimes the color shifts because of the palatalization that is happening with the compression (to make the file smaller)

I've found in practice, that h.264 encoders tend to keep the dark detail better, but if your client needs WMV, you're stuck with the inconsistencies.

Ah good to know. Wow it's complicated huh?

I've been using .wmv encoding for ease of use. In Vegas I'm not sure the best way to render out h264... I think it's actually to render out uncompressed then use another app to compress. I'll do my next project like that.

 

[Demistate]

Ah good to know. Wow it's complicated huh?

I've been using .wmv encoding for ease of use. In Vegas I'm not sure the best way to render out h264... I think it's actually to render out uncompressed then use another app to compress. I'll do my next project like that.

Try Using Debugmode Frameserver. It allows you to create reference files that can be re-encoded in any other application. pair this together with a program like Ripbot or Megui and you can get some pretty high quality h.264s for free.

 

[yabyum]

Try Using Debugmode Frameserver. It allows you to create reference files that can be re-encoded in any other application. pair this together with a program like Ripbot or Megui and you can get some pretty high quality h.264s for free.

Hey thanks for posting this! It took a bit but I got it working and it is pretty awesome!

For anyone else following this, here's what you need to do. Get the Frameserver software, install with plugin to your software (vegas for me), I did this with Vegas off. Turn it back on, now I can render to Frameserver .avi

This makes a blank file. Just leave the settings default it will work. What the Frameserver does it send the data that the compression software is using at the time it needs it, instead of having a massive file, u have one constantly updating small file. When you render it will look like it's not doing anything, that is good

Okay, so with Megui you need to also download AviSynth or it won't work. Now in Megui with all that installed (oh you need microsoft .net framework too which i already had)... go to Tools -> AVS Script Creator. Select Video Input and select the frameserver .avi. It'll bring up a preview and all that jazz. Save the script.

Main window choose x264 whatever you want. I used various 2 pass encodings which worked well... though you need to up the bitrate probably (I used 2400 for good results). Here's the important part that I couldn't figure out forever... go to Advanced Settings in x264, under Rate Control and select "Use MB-Tree". I have NO idea what this is but it would error everytime if I didn't have this checked.

Back to main window, File Format should be mp4. Hit Enqueue it'll ask if you want to add something to the script (about color space or something) just say yes. Now you're good to go to encode video. Just go to Queue tab and hit Start.

To have audio you need to render from Vegas the audio in .wav format (default settings worked fine for me). Select it in the main window of Megui and use FAAC *scratchpad*. Default settings work fine, though you might want to up the bitrate. Change extension to Raw AAC. Enqueue and start in Queue tab and boom!

You'll now have two files, one .mp4 and one .aac. In Megui go to Tools->Muxer->Mp4 Muxer. Choose the video file, mp4 and the audio file .aac and then enqueue it and start in Queue tab. BOOM! You now have a small h264 format self-contained video clip!!

Anyone know what this MB-Tree business is? From my google searches looked like other people weren't getting the same error as me (said unsupported feature or format or something and referenced --mbtree-off or somethign like that).

Oh and I also noticed that if I set my Vegas pixel format to 32 bit (floating point full range) from the normal 8 bit... Megui didn't seem to be working. At least the preview showed gobblyguk.

 

[JeganRX]

Hey thanks for posting this! It took a bit but I got it working and it is pretty awesome!

For anyone else following this, here's what you need to do. Get the Frameserver software, install with plugin to your software (vegas for me), I did this with Vegas off. Turn it back on, now I can render to Frameserver .avi

This makes a blank file. Just leave the settings default it will work. What the Frameserver does it send the data that the compression software is using at the time it needs it, instead of having a massive file, u have one constantly updating small file. When you render it will look like it's not doing anything, that is good

Okay, so with Megui you need to also download AviSynth or it won't work. Now in Megui with all that installed (oh you need microsoft .net framework too which i already had)... go to Tools -> AVS Script Creator. Select Video Input and select the frameserver .avi. It'll bring up a preview and all that jazz. Save the script.

Main window choose x264 whatever you want. I used various 2 pass encodings which worked well... though you need to up the bitrate probably (I used 2400 for good results). Here's the important part that I couldn't figure out forever... go to Advanced Settings in x264, under Rate Control and select "Use MB-Tree". I have NO idea what this is but it would error everytime if I didn't have this checked.

Back to main window, File Format should be mp4. Hit Enqueue it'll ask if you want to add something to the script (about color space or something) just say yes. Now you're good to go to encode video. Just go to Queue tab and hit Start.

To have audio you need to render from Vegas the audio in .wav format (default settings worked fine for me). Select it in the main window of Megui and use FAAC *scratchpad*. Default settings work fine, though you might want to up the bitrate. Change extension to Raw AAC. Enqueue and start in Queue tab and boom!

You'll now have two files, one .mp4 and one .aac. In Megui go to Tools->Muxer->Mp4 Muxer. Choose the video file, mp4 and the audio file .aac and then enqueue it and start in Queue tab. BOOM! You now have a small h264 format self-contained video clip!!

Anyone know what this MB-Tree business is? From my google searches looked like other people weren't getting the same error as me (said unsupported feature or format or something and referenced --mbtree-off or somethign like that).

Oh and I also noticed that if I set my Vegas pixel format to 32 bit (floating point full range) from the normal 8 bit... Megui didn't seem to be working. At least the preview showed gobblyguk.

Is there a particular reason you're bothering with debug frameserver? The final AVI from Vegas (if you're exporting a WMV as your master, please stop) can be directly loaded into AVISynth, so you can cut out a step there.

As for x264's MB-Tree, I'm aware that it does *not* work with the B-Pyramid option of x264 (see: http://forum.doom9.org/showthread.php?t=148686), as it's a very recent patch actually, within a few days of being officially added... Though I'm not sure why unticking the option gave you an error (At this time, it seems advised to use MB-Tree anyway for quality/efficiency gain). Stick with MeGUI's profile settings for easy compatibility (particularly if you're sending to an Apple user, who can't play high profile H264).

 

[yabyum]

Is there a particular reason you're bothering with debug frameserver? The final AVI from Vegas (if you're exporting a WMV as your master, please stop) can be directly loaded into AVISynth, so you can cut out a step there.

As for x264's MB-Tree, I'm aware that it does *not* work with the B-Pyramid option of x264 (see: http://forum.doom9.org/showthread.php?t=148686), as it's a very recent patch actually, within a few days of being officially added... Though I'm not sure why unticking the option gave you an error (At this time, it seems advised to use MB-Tree anyway for quality/efficiency gain). Stick with MeGUI's profile settings for easy compatibility (particularly if you're sending to an Apple user, who can't play high profile H264).

Actually using the debug frameserver saves me time and isn't an extra step really. I don't have to wait for Vegas to render out an uncompressed AVI file. Plus I'm concerned about HD space as well.

The only problem is that I cannot use 32-bit pixel depth (?) in Vegas and I have to stick with 8-bit. I've read that some people say using 32-bit increases the color quality a lot but I don't know. Maybe it is something with AVIsynth that is not allowing the 32-bit to work? (To clarify, the error is that I can render out but the video is just a rainbow mess of skewed lines and stuff)

 

[JeganRX]

Actually using the debug frameserver saves me time and isn't an extra step really. I don't have to wait for Vegas to render out an uncompressed AVI file. Plus I'm concerned about HD space as well.

The only problem is that I cannot use 32-bit pixel depth (?) in Vegas and I have to stick with 8-bit. I've read that some people say using 32-bit increases the color quality a lot but I don't know. Maybe it is something with AVIsynth that is not allowing the 32-bit to work? (To clarify, the error is that I can render out but the video is just a rainbow mess of skewed lines and stuff)

AVISynth doesn't support 32bbp images, only 8-bit. Technically, your final delivery is probably going to be 8-bit anyway, the difference is how effects are rendered (usually gradients, lens flares, etc), since banding can occur if they're not rendered at a higher bit depth.

Rendering higher and then bringing down to 8-bit is always better (oversampling is always better in general) anyway, but if you have a fairly straight-cut video (or your effects were rendered in 8-bit already), you should have no issue in continuing as 8-bit.

Just an advisory to some: 8bbp != 8-bit video (Though I'm colloquially using that term here). 8-bit would be absolutely horrendous, and on the line of GIF level colors.

 

[yabyum]

AVISynth doesn't support 32bbp images, only 8-bit. Technically, your final delivery is probably going to be 8-bit anyway, the difference is how effects are rendered (usually gradients, lens flares, etc), since banding can occur if they're not rendered at a higher bit depth.

Rendering higher and then bringing down to 8-bit is always better (oversampling is always better in general) anyway, but if you have a fairly straight-cut video (or your effects were rendered in 8-bit already), you should have no issue in continuing as 8-bit.

Just an advisory to some: 8bbp != 8-bit video (Though I'm colloquially using that term here). 8-bit would be absolutely horrendous, and on the line of GIF level colors.

Mmm. thanks! Now I gotta find another workflow, dern.