"In Vegas 10, 11 and 12 there is a Computer RGB to Studio RGB change in levels in the MP4 file."

In which certain case? I cannot repro here.

Here is a simple 0-255 gradient. Is this mapped different in any's Vegas Pro 12?

Marco said:

"In which certain case? I cannot repro here.

It will take me a while to check that file in V9 as my system with V9 is capturing.

HOWEVER, this has been checked by myself on multiple computers with Laurence's MP4 file that was rendered out of Mercalli.

I checked V9, V10 and V11.
Musicvid checked V8, Grazie checked V12.

Again I say.
In V8 and V9 it decodes as Computer RGB
In V10, V11 and V12 it decodes as Studio RGB


Somewhere there was also a thread about how V10 decodes MP4 differently to V8 and V9.

Bob.

[edit]
It *may* well be that the difference has something to do with the contents of the MP4 file, we have no way of knowing. What it would take to know for sure is a program that can read the Y'CbCr values directly from the MP4 file.

O.k. here is another go which demonstrates it is Mercali which treats different input file compression in different ways regarding the luma mapping.

-> Download

The unzipped folder "testfiles" contains two clips with different file formats – MPEG-2 as HDV and H.264 as MP4 – and both clips contain same video signal: a 0-255 gradient.

Put these files into the Vegas Pro timeline and you will see Vegas Pro do not remap any of the signals (only thing you'll notice is some markable loss in the H.264 file which doesn't matter here). Both waveform are (nearly) identical and repro the range of 0-255 which conforms to the original signal.

Now put both clips into Mercali 3 let it do its processing and output to MP4 again.

Your resulting Mercali output is same file format and same compression format for both clips. Both are MP4 H.264 now and if it would be Vegas Pro doing a remapping, once imported into Vegas Pro both video signals should show same waveform again but this time both waveforms should show a remapping.

Truth is only the clip which was feeded as MP4 into Mercali shows a different waveform. Actually I can put these two Mercali clips into any availble video system and the difference is clearly visible.

Marco said:
"Truth is only the clip which was feeded as MP4 into Mercali shows a different waveform. "

Agreed. In a Skype session with Grazie last night he confirmed that MXF files from his XF300 suffer no level change going through Mercalli.
Feeding the MOV from his Canon point and shoot camera there is.

The real problem here is we lack the tools to determine what is really going on, there are too many unknown variables.
All I believe can be said with any confidence is:

1) There is a difference in the way Vegas decodes some MP4 files after V9.
2) Most "still" cameras record video with Computer RGB levels. This has been done to death both here and in other NLE fora. From memory it took an update to FCP for Apple to ease FCP users from having to set Canon 5D and 7D cameras into low contrast.
3) Histograms are simply the wrong tool to be using with this problem.

Bob.

Yes, I don't disagree.

And yes, there is a difference between some Quicktime (MOV) H.264 files. In Vegas Pro (10, 11, 12) some are decoded via Sony AVC (like the ones recorded by Canon cameras) and some others are decoded via Quicktime.

Marco, I recreated your experiment with what I believe are the same results as you got. I'm still not convinced though.

Yes, Vegas is saving the HDV format to h264 and then reloading it with the ranges intact. This would initially seem to imply that you are correct and that it is not Vegas making the mistake.

Another possibility though is that Vegas is making the mistake both on the save and open. As unlikely as this seems, I thought I would test it. I was unable to open your "hdv" format clip in Adobe Photoshop (my test Adobe application for all this), so I was trying to think what other video editors I might have. Aha! I found my unused up to this point "Windows Movie Maker". This loaded both your "h264" and "hdv" test clips. To my surprise, this backed up the theory that Vegas was both saving and loading altered ranges in h264 format! Try it. Load your h264 and hdv clips into Windows Movie Maker. The levels are the same in Vegas, but different in Movie Maker!

This leads me to believe that somebody at SCS stumbled upon this level mixup before and rather than have Vegas read one set of levels and write another, they simply made them match and put in a matching error on h264 writes.

This would also explain the banding in your h264 test clip. If Vegas is compensating both on the write and back again on the read, you would expect to see this exact sort of banding.

This would also expain why I hate Vegas's h264 writes so much and have been using Handbrake instead. Vegas may read it's own h264 file levels correctly, but Youtube and Vimeo probably do not. I'll test this out later when I have time. Right now my wife is calling me for dinner.

"Load your h264 and hdv clips into Windows Movie Maker. The levels are the same in Vegas, but different in Movie Maker!"

You are right.

"This would also explain the banding in your h264 test clip."

Right again. I also stumbled across that banding just now. It either means you are right and Vegas Pro expands the levels in this certain case of compression and file format, or it would mean the app I used to create this H.264 MOV file (MPEG Streamclip) caused the banding.

I'll try to find another format which is useful for this test.

This is a quite different thing then. Vegas Pro created H.264 MP4 is fine and both Youtube and Vimeo reads and encodes them correctly. But the flash player used in your browser expands levels.

If you have a WebM capable browser and a HD Youtube video rendered to MP4 in Vegas Pro you will see there is no level change no more when viewing the video in fullscreen mode. Also if you download the hd version of these videos from Youtube shows the difference comes from the flash player.

deleted again, need some sleep first …

Just one note: The differences you saw when comparing the original un-processed HDV clip against the MOV clip in Windows Media Player might be caused because the Windows Media Player expands levels of MPEG-2 video (it does not for the MP h.264).

Meanwhile you can check a Quicktime PNG against that HDV clip. The Quicktime PNG matches perfectly its original gradient (no banding, no clipping, just like a 1:1 copy).

-> Download

But once processed by Mercali its levels are pushed down whereas the HDV's level keeps being fine.

No conclusions to the MOV h.264 possible from this but at least it demonstrates how different Mercali treats some formats. On the other hand I found another process which feeds your theory of Vegas Pro remapping a certain kind of MOV file. Later …

>deleted again, need some sleep first …

LOL! This is week three for me on this subject! You have no idea of how much I understand that last comment! ;-)

My latest finding is:

There is a certain type of Quicktime MOV h.264 that is decoded in Vegas Pro 12 using Quicktime. And this certain version makes Vegas Pro to expand the levels (which causes banding clearly visible via RGB histogram).

I proofed this by using such a Quicktime MOV h.264 and by remuxing it to MP4 without touching the h.264 video stream inside. The MOV version in Vegas Pro is decoded by Quicktime. The MP4 version is decoded by Sony AVC. The MOV is remapped. The MP4 is not.

This certain type of Quicktime MOV h.264 is ouput by Mercali V3 so for the use in Vegas Pro it is better to output as MP4.

---------------------------------------------------

Please notice different Quicktime MOV h.264 files might be differently decoded in Vegas Pro, e.g. such files recorded by Canon cameras (like the MKII) or by Panasonic Cameras (like GH3) which also uses Quicktime MOV h.264 are NOT decoded by Quicktime but by Sony AVC in Vegas Pro 12 (without any remapping).
This might be the difference to Vegas Pro versions before version 10. The former versions always used Quicktime to decode MOV h.264.

It seems to be something in the header of such Quicktime MOV h.264 files which makes Vegas Pro using different decoders. If you got a Quicktime MOV h.264 file which decodes by Quicktime you can simply remux to same Quicktime and then Vegas Pro will decode by Sony AVC (without remapping).

So what you can do is using MP4 files instead of Quicktime or you can remux existing Quicktime files.

There's a few "might"s in there :(

Earlier today I made an effort to get to the bottom of this by trying to find a way to read the actual Y'CbCr values from the input file.
I thought I had it nailed using Color Finess in AE CS5.5 but with that I can only change the Output LUT, the Input LUT isn't accessible, I guess AE does the decode and conversion and passes the RGB values into its pipeline before any FXs get to the data.

My only remaining hope would be DaVinci Resolve which implements the full ACES pipeline which lets us change both the IDT and ODT LUTs. If one can change the IDT for different sources to None then we can compare the actual values that different cameras recorded.

Doing this is going to take a fair bit of work. Even if we know the answers beyond any doubt, then what?

So far ProDad have tried to address the problem in a very off hand manner. SCS changed *something* between V9 and V10 in regard to how at least some MP4 files are decoded to RGB without even a footnote. Neither company comes close to having what I would rate as a professional ethos. This isn't a "bug" issue, this is a failure to engage and communicate with the user.

Bob.

OK, here's another test that I think anyone here could recreate:

Download the video examples here which contain the flower video clip in both it's original .mov format and the Mercalli SAL v3 stabilized form:

https://dl.dropboxusercontent.com/u/9490815/Mercalli_Issues_Video_Examples.zip

Drop each of these clips on a Vegas timeline and you will see the original problem: that is that the native MOV clip is in cRGB space and the Mercalli clip is in sRGB space (as confirmed with a Vegas histogram).

Now run both of these clips through Handbrake and put the resulting h264 files on the same Vegas timeline. I won't take the time to do screen captures and post the pictures because it's just more of the same but here is what you will find.

The handbrake renders of the original MOV clip and the Mercalli processed clips look the same and are both in sRGB color space! Handbrake thinks the original MOV clip is in sRGB space as well!

So Handbrake, Adobe products and Cineform all treat the original MOV clip as though it is sRGB and see no difference between the pre and post Mercalli clips!

Sony Vegas, Windows Movie Maker, and VLC see a difference in color between the two clips. Adobe, Cineform and Windows Media Player do not. One group has to be remapping colors.

I just did a Google search and sure enough, Windows Movie Maker is also using VFW. To me it seems so obvious! On certain codecs (including my Nikon MOV format and my GoPro mp4 codec) VFW maps colors one way. Directshow maps them another. Which is the correct mapping? I am quite sure at this point that the currently supported Directshow is correct and that the bug ridden and archaic VFW is making the mistake, but obviously we don't all agree. What will it take to convince you guys? I am already absolutely sure of this and have been for a while now.

How sure am I? As sure as I am of my political party's superiority ... no I'm a lot more sure than that. As sure as I am about my own religion's correct grasp of things spiritual...no I am a lot more sure than that .... but I am quite sure...

Just to summarize my theory:

Certain codecs map colors differently when played back by VFW or Directshow. Vegas plays back all video using VFW and thus sees the VFW mapping. When a clip which is displayed differently by VFW and Directshow is processed by Mercalli SAL v3, Mercalli reads this clip using Directshow, and rewrites it's stabilized version in an mp4 codec that looks the same when read by VFW or Directshow. This "locks in" the Directshow version of the color mapping. Thus Vegas looks at this stabilized clip with the Directshow mapping rather than it's previous VFW mapping and sees a difference in color.

Adobe products, since they are reading with Directshow see no difference between the original clips and the Mercalli processed clips. Neither does WIndows Media Player, Cineform or Handbrake.

If a product uses VFW, it will see a difference between the pre and post Mercalli processed clips. If it uses Directshow, it will not. Thus Windows Media Player and Adobe see no color difference between pre and post Mercalli stabilized clips while Vegas, VLC and Windows Movie Maker see the post Mercalli clips as being somewhat desaturated.

Because people tend to prefer more saturation, the VFW playback instinctively looks better to most of us even though it's wrong, and we tend to see the problem as being in the post Mercalli stabilized version even if in fact that version is actually rendering colors more accurately.

Laurence, the file "Quicktime_MOV_Clip.MOV", is this the native camera source file or did this go its way via ProTune?

This GoPro test did not use Protune. Protune is useful but it compresses the levels and it is hard to compare the results when you are analyzing the codec's behavior. That's why I left it off for this test.

> proofed this by using such a Quicktime MOV h.264 and by remuxing it to MP4 without touching the h.264 video stream inside. The MOV version in Vegas Pro is decoded by Quicktime. The MP4 version is decoded by Sony AVC. The MOV is remapped. The MP4 is not.

I'm seeing exactly the same thing. The Mercalli MOV output has noticeable banding in it.

Thanks for this additional info. I asked because there is one thing I do not understand:

If Vegas re-mapped the levels of this file how can it be there is absolutely no banding to be seen in the RGB histogram?

Ah, wait, I now remuxed the original file once to MP4 and also demuxed it into the native h.264 video stream. All three files looks same with levels ranging from 0-255.

how can it be there is absolutely no banding to be seen in the RGB histogram?

Quite.

G