CineForm supports 5D Mk II editing

[Thane Brooker]

Mike,

I find CoreAVC to be by far the best solution for previewing .MOV clips, I haven't found anything else that can run in realtime on my laptop for in-the-field previewing.

First, make sure CoreAVC really is being used. Click "Configure CoreAVC" and tick "Use Tray Icon". Also tick "Preferred Decoder". Then try and view a .MOV file in Windows Media Player - you should see the blue and white CoreAVC icon appear in the tray icon area (next to the clock) while playing the file. If you do not see this icon, Windows Media Player is using something other than CoreAVC.

To find out what codec is being used, use GraphEdit (Google for this utility). Drag the .MOV file into GraphEdit, and what you should get is:

MVI_xxxx.MOV --> CoreAVC Video Decoder --> Video Renderer
|--> A Sound Device (sound will vary according to your system)

You may or may not see reference to Haali Media Splitter. The important thing is CoreAVC is listed as the Video Decoder, and not Canon, FFDShow, or some other decoder.

If CoreAVC is not listed, and something else is, you need to de-prioritise whatever is being used instead. For this I use a utility called Radlight Filter Manager (Google for this utility). Make sure you run it as administrator. Find the filter that is being used (it will be under DirectShow Filters) and change the Merit drop-down box to MERIT_NORMAL, MERIT_UNLIKELY or MERIT_DO_NOT_USE. Then click "Set Merit Value". Then reboot your PC (the effect only takes place following a logout/login).

I find that installing Quicktime or Quicktime Alternative AFTER CoreAVC changes CoreAVC from being the preferred decoder, so if you install a Quicktime update, reinstall CoreAVC (and the Haali Media Splitter component) again afterwards.

Once you are certain that CoreAVC is really being used, go back into the CoreAVC Decoder Properties and ensure Input Levels are set to PC: 0-255, and Output Levels are set to TV: 16-235 if using with Windows Media Player (Windows Media Player 11, like Premiere Pro CS4, expects any input to be 16-235 and will clip anything outside this range). I also set 16-235 when using CoreAVC in the creation of a Cineform file for use with Premiere Pro CS4 using HDLink, as per my previous post. This means the Cineform file isn't used to it's full advantage, but the point is Premiere Pro CS4 can't seem able to deal with a "full advantage" Cineform file and will clip if you try. David Taylor, any advice?

I use CoreAVC for previewing files in Windows Media Player because it is so efficient at decoding, but I don't use it for converting files to Cineform (or any other codec) because it doesn't give the option of selecting between ITU-R BT.601 or ITU-R BT.709 color specifications. I understand (to be confirmed) the 5D files are encoded in ITU-R BT.709, and CoreAVC appears to decode using ITU-R BT.601 only. So for non-realtime conversion, I use FFDShow instead, which also allows conversion to 16-235 plus ITU-R BT.709 option.

It is easy to leave both decoders installed, and switch between the one you want to use (CoreAVC for realtime viewing or FFDShow for non-realtime transcoding) by setting FFDShow as a higher merit and toggling "disabled/libavcodec" against the H.264/AVC Format in the FFDShow Codecs property page. FFDShow also has a show-in-tray option as visual confirmation of which is being used. If your PC is fast enough to use FFDShow in real-time, you may just want to use this and not use CoreAVC at all.

Hope this helps.

Thinking about this has prompted some questions in addition to my previous post:

1) Does the new Neo Scene 5D decoder use 601 or 709 color specs? And which is correct anyway? Reading Cineform's other posts, I think they are implying 709 is correct for 5D files based on the files being HD 1920x1080 (but not because Canon specifically say so). This is a sensible deduction, but is this just a best-guess or is there a flag or anything set in the file to indicate the correct decode mode?
2) If 709 is correct for 5D files, why does CoreAVC and Apple Quicktime and Premiere-Pro-timeline-drop and Adobe-Media-Encoder all appear to use 601 (I say appear, because I have no technical specs on this and am doing a visual comparison against FFDShow in each mode, taking into account the gamma change Apple and Adobe make).
3) Does anybody know of a Windows Media Player that accepts 0-255 input, and actually displays on the screen 0-255? I have yet to actually see a 5D file in its full 0-255 glory. Quicktime Player doesn't (even the latest one), it squishes to 16-235 like CoreAVC/Windows Media Player, and outputs that (along with a brightening of the gamma by about 10%).
4) Why does the RGB parade in Premiere Pro show gaps in the color range following an Adobe Media Coder conversion to 16-235, or a direct drop of a native 5D .mov file onto the timeline? Surely squashing from 0-255 to 16-235 will result in bits being lost, so there should be no gaps. The only thing I can think of is they are caused by the gamma change, which is happening after the 16-235 squeeze. Not that it matters if you use CoreAVC/FFDShow to do the squeeze, but it makes me wonder.

---
Thane Brooker
8Networks - IT Specialists

[Ray Bell]

What I have seen with Premier Pro...

If I bring native 5DMKII footage into Premier Pro... and look at the scope you can see that
the program is showing the footage in 16-235

But if I take the same footage and bring it into Quick Time Pro and output the same footage
with the same attributes that the original file was and then bring that footage back into
Premier Pro then the scope does show the footage as 0-255....

You can put both files ( native and QT) on the same time line and check the scope for each
by turning on/off the files on the time line to check it all out.... the shift is very easy to see on the scopes

There is more info on this here....

CineForm Insider

[Thane Brooker]

Ray,

Just to clarify, this is what I am seeing when I drag each file type onto the timeline and look at the RGB parade:

Native .mov: Squished into 16-235 (0-100 on the scope), gamma brightened, various lines of missing color.

0-255 file (cineform, lagarith): 0-15 and 236-255 clipped. So I have a lot of pixels at 0 and 100 on the scope due to the clipping. Cannot adjust brightness or contrast using ProcAmp/Fast Color Corrector to bring the clipped areas into range, it is as if they aren't there.

Is the above what you are seeing?

If so, are you saying that if I repackage a native .mov file in Quicktime Pro and import that, CS4 will NOT compress it into 16-235 (0-100 on the scope) and will clip it like a 0-255 cineform/lagarith file (lots of pixels at 0 and 100), BUT the clipped areas can be brought into range using ProcAmp/Fast Color Corrector like a hdv m2t file? So when I increase brightness, for example, the data from RGB0-15 magically appears on the bottom of the scope?

I am right in assuming that 0 on the RGB Parade maps to RGB16 in the source file, and 100 on the RGB Parade maps to RGB235 in the source file, yes?

[Keith Paisley]

Originally Posted by Thane Brooker

I use CoreAVC for previewing files in Windows Media Player because it is so efficient at decoding, but I don't use it for converting files to Cineform (or any other codec) because it doesn't give the option of selecting between ITU-R BT.601 or ITU-R BT.709 color specifications. I understand (to be confirmed) the 5D files are encoded in ITU-R BT.709, and CoreAVC appears to decode using ITU-R BT.601 only. So for non-realtime conversion, I use FFDShow instead, which also allows conversion to 16-235 plus ITU-R BT.709 option.

Originally Posted by Thane Brooker

Thinking about this has prompted some questions in addition to my previous post:

1) Does the new Neo Scene 5D decoder use 601 or 709 color specs? And which is correct anyway? Reading Cineform's other posts, I think they are implying 709 is correct for 5D files based on the files being HD 1920x1080 (but not because Canon specifically say so). This is a sensible deduction, but is this just a best-guess or is there a flag or anything set in the file to indicate the correct decode mode?

This may answer your question (or maybe not) but this is what I found a few months ago when looking at the Quicktime atoms in the header of a 5d Mk II file. I think it's a little strange that the "matrix" is listed as being 601 while the primaries and transferfunction are 709, but then again, I'm not real clear on what they all mean so it could be inconsequential.

[Jay Bloomfield]

I'm pretty sure that the 'gama' atom is ignored, if there is a 'colr' atom in the MOV file. I remember this from when I was using a hex editor to change the header entries on a 5D2 file, so that NLEs would read the file as being 30P NTSC (29.97 fps) and not 30.00 fps. Using a hex editor is the only way of editing the metadata on a PC, that I know of. On a Mac, there are a number of ways to do so.

[Chris Barcellos]

Davids at Cineform: Is there an issue here, and is there something in the works ? Guess I will find out in a day or two when my camera arrives- but I thought it was resolved.

[Jay Bloomfield]

601 is the old SD standard, 709 is for HD. It really depends on what the decoder does with information in the header file.

[Thane Brooker]

Originally Posted by Keith Paisley

This may answer your question (or maybe not)

It didn't answer my question exactly, but it is extremely helpful, so thanks for posting that.

[Jay Bloomfield]

Originally Posted by Thane Brooker

... I use CoreAVC for previewing files in Windows Media Player because it is so efficient at decoding, but I don't use it for converting files to Cineform (or any other codec) because it doesn't give the option of selecting between ITU-R BT.601 or ITU-R BT.709 color specifications. I understand (to be confirmed) the 5D files are encoded in ITU-R BT.709, and CoreAVC appears to decode using ITU-R BT.601 only. So for non-realtime conversion, I use FFDShow instead, which also allows conversion to 16-235 plus ITU-R BT.709 option. ...

Thane Brooker

Thane,

While were waiting for someone from Cineform to answer some or all of those questions, I wanted to ask you something. Where did you read that CoreAVC only decodes using ITU-R BT.601? Usually 601 is used for SD and 709 for HD. The tonal difference between the two standards aren't that massive, though it's worth worrying about it, if you are using scopes to color grade.

The QT 7.6 upgrade fixed the clipping/crushing issue, but there still seems to be some confusion (at least on my part) as to whether the various h.264 decoders are correctly interpreting the color information that is contained in the 5D2 MOV file metadata.

Jay

[Jon Fairhurst]

Originally Posted by Jay Bloomfield

The QT 7.6 upgrade fixed the clipping/crushing issue, but there still seems to be some confusion (at least on my part) as to whether the various h.264 decoders are correctly interpreting the color information that is contained in the 5D2 MOV file metadata.

QT 7.6 also broke the color curve by adding a 1.2, or so, gamma boost. It's fine for quick reviews, but adds gaps and bumps in the histogram.

We rewrap the MOV files as MP4s and open in Vegas. The Luma and RGB histograms are all 100% smooth. That tells me that the decoding is optimum, including the color space.

I haven't tried the NeoScene yet. Hopefully, somebody can confirm that the histograms for RGB and Y are all still smooth from 0 to 255 with the latest Cineform decoder. If so, I'm sold.

[Thane Brooker]

Originally Posted by Jay Bloomfield

While were waiting for someone from Cineform to answer some or all of those questions, I wanted to ask you something. Where did you read that CoreAVC only decodes using ITU-R BT.601? Usually 601 is used for SD and 709 for HD. The tonal difference between the two standards aren't that massive, though it's worth worrying about it, if you are using scopes to color grade.

The QT 7.6 upgrade fixed the clipping/crushing issue, but there still seems to be some confusion (at least on my part) as to whether the various h.264 decoders are correctly interpreting the color information that is contained in the 5D2 MOV file metadata.

The differences between 601 and 709 are easy to spot with the eye. I pasted a screen capture of each video image into Photoshop to make it easier to compare.

I couldn't find anywhere that said what CoreAVC does or doesn't do, which is partly why I posted here to see if anybody could confirm or find error in my findings.

I'll list below exactly what I did so you can recreate.

CoreAVC Decode, CoreAVC RGB conversion, Windows Media Player
Untick all the outputs in CoreAVC except RGB32 (or RGB24). This ensures CoreAVC is doing the RGB conversion and not the video renderer. The result exactly matches FFDShow's RGB conversion using ITU-R BT.601 option.

CoreAVC Decode, Windows Renderer RGB conversion, Windows Media Player
Untick all the outputs in CoreAVC except YUY2, and select TV output 16-235. This ensures the video renderer does the RGB conversion. The result exactly matches FFDShow's RGB conversion using ITU-R BT.709.

Notes
1. The reason I untick all the outputs in CoreAVC rather than rely on the priority order is that it didn't seem to work for me - even though RGB was at the top of the list, CoreAVC was still sending non-RGB to the Video Decoder.
2. When I selected YV12 instead of YUY2, the number of vertical pixels reduced. So instead of 1920x1080, I got a picture approx 1920x1070 or thereabouts (haven't counted).
3. If I select PC output 0-255 for YV12 or YUY2, I get clipped blacks and whites.
4. Selecting TV output or PC output with only RGB selected has no effect.
5. I'm not exactly sure what Video Renderer is being used, but it will be whatever is default on Vista with Media Player 11. I think it is the Enhanced Video Renderer (EVR).

I then wanted to cross-check my results, in case FFDShow wasn't a reliable benchmark, so I used the Haali Video Renderer and Zoom Player.

CoreAVC Decode, Haali Video Renderer RGB conversion, Zoom Player
Set CoreAVC to output YUY2 only, output 0-255. Set the Haali Video Renderer to output 0-255, and either BT.601 or BT.709.

The result was much more saturated than Quicktime or Windows Media Player, but saturation aside, the difference between 601 and 709 reasonably matched FFDShow.

Notes

If I select YV2 in CoreAVC, Haali clipped blacks and whites regardless of 16-235 or 0-255 options

Finally, I wanted to see how Quicktime compared.

Quicktime Player Version 7.6 (472) Quicktime Version 7.6 (1292)
Most noticeable is the picture is brighter. In Photoshop, I used the levels tool to brighten the other images to match. I found setting the midtone input level to 1.14 resulted in an almost identical picture. Following the brightness adjustment, Quicktime exactly matched CoreAVC and FFDShow's ITU-R BT.601.

[Neal Wagner]

So, after many discussions & alternatives, is a successful workflow for the 5D Mark II and Sony Vegas 8.0c (32-bit) as simple as follows:
Success means preserving 1080 resolution and faithful (no crushed blacks, etc.) coloration.

1. use NeoScene to transcode 5D mov to Cineform avi.
2. edit Cineform avi in Vegas

My NeoScene trial ran out before I reinstalled 32-bit Vegas, so to buy or not...

Thank you.

[Charles W. Hull]

Originally Posted by Neal Wagner

So, after many discussions & alternatives, is a successful workflow for the 5D Mark II and Sony Vegas 8.0c (32-bit) as simple as follows:
Success means preserving 1080 resolution and faithful (no crushed blacks, etc.) coloration.

1. use NeoScene to transcode 5D mov to Cineform avi.
2. edit Cineform avi in Vegas

My NeoScene trial ran out before I reinstalled 32-bit Vegas, so to buy or not...

Thank you.

Neil, I think each release of the Neo Scene beta has its own trial period so if you downloaded the first 1.1 version there is now a second one you can try. This version solves the explorer crash problem and supports 5DII files (initial support). It should run okay with Vegas but I'm running with Premiere so I can't say for sure.

Yes, there is an issue with blacks. Here is my current understanding - Cineform correctly converts the 5DII files, but when they do this they can overrun the 8 bit color range of the editor, so in Premiere you have to use a 32 bit color filter in case the blacks or highlights are crushed (which can be a pain). The logic from Cineform is that the 5DII video is fine but if they compress it to fit the 8 bit editor they will lose data.

I don't know if Vegas will handle this, or how the color filters work in Vegas. But my expectation is you should be able to work with it.

[Jon Fairhurst]

Originally Posted by Charles W. Hull

I don't know if Vegas will handle this, or how the color filters work in Vegas. But my expectation is you should be able to work with it.

Vegas respects the data beyond 16-235. You can use the Computer -> Studio RGB filter, if you want to run studio levels with 8-bit processing. If I'm not mistaken, you can run Vegas in 32-bit mode and it expects video to range from 0-255. Note that Vegas is much faster when processing in 8-bits.

[Thane Brooker]

To add to my previous post, a Cineform file created with the latest Neo Scene matches BT.709.

I couldn't open it in Windows Media Player, I got crushed blacks. But I could open it in Zoom Player using the Haali video renderer.