I just bought Morgan Jpeg2000 ($30) and it looks like a great intermediate codec. I transcode using CoreAVC and AVISyth and enable Lossless with 4:2:2. My test video ended up half the size of lagarith with no data lost. It did take a little longer to transcode but 700mb vs 1,500mb is a compromise I am willing to accept.

You can also adjust a global quality setting for realtime playback while editing and enable full when you are ready to render. Seems to be very fast and efficient.

Morgan Multimedia - Home of the MM MJPEG video codec.

Will the Morgan JPEG codec resolve the crushed black issue?

No.. Not exactly. To solve the crushed black problem you need a decoder that will read all of the available data in the original .MOV files. The only codec I am aware of that will is CoreAVC. To force Premiere, After Effects, Combustion, Vegas and others to use this codec the frame server AVISynth is required. Or they will just override CoreAVC and use QT or a built in decoder.

While This will fix the crushed blacks and highlights problems the trouble is that editing becomes a nightmare. With AVISynth playback is extremely slow, and as you load up your workspace it becomes much worse.

My solution is to transcode the .MOV using CoreAVC to Morgan Jpeg2000. This solves all of the problems including the full 0-255 range and fast realtime playback I believe in any software. This meets all of my post-production workflow needs.

There are other possible ways you could go about this. For example, I picked Morgan Jpeg2000 because its "Lossless" and very fast but you could use the lagarith codec which is free but has much bigger files and a bit slower playback. You could also use Cineform or some other fast free lossy compressed format.

As a final note, I recently read at some other sources that documentation and support for Morgan Jpeg2000 is horrible. It was a shot in the dark for me because the trial version does not even work (Expired October 2007). I am pleased with it but there are other options.

Sony Vegas ships with a jpeg2000 codec installed. However, it is not customizable. I've used it and it works well, but the bitrate can get awfully high. I used it on a 1080p file this week and I was seeing rates in the 90Mbps range. That's pushing it for 1080p if you want smooth playback.

I currently use the DNxHD codec for what I do, but it's lossy. Not terribly so, but it is not designed to be lossy. It's VERY similar to ProRes and Cineform. Previously, I've used Cineform as that also shipped free with Vegas but it has no 64bit version and no 10-bit support out of Vegas. Obviously ProRes is Apple only. Lagarith has 32 and 64 bit versions, but I had loss with it and for the file size, that was not acceptable.

There are a multitude of options out there for codecs, but all have tradeoffs and you have to choose depending on need. Because of my workflow, I needed 1hr of material to fit into 20GB of space for writing to BluRay. This gives me the room to write a high quality version as well as an mp4/vc-1 to the BluRay for future use.

Why did Canon ship the camera with such a problematic codec??? Is there a petition going for them to tweak the video codec so it's easier to post with?

The biggest mistake Canon made was choosing Quicktime. I think the quicktime decoders are what's currently broken at the moment. Apple needs to hurry up and fix the colorspace and gamma issues and then get this code out to all the licensees.

That said, even if those issues didn't exist, doing post-editing with h.264 on the timeline is probably going to be something that will take a while to become truly practical. GPU acceleration would probably go a long ways towards improving it, but that would require support from the NLE packages. Hopefully a standard API will emerge to facilitate this so NLEs can leverage the GPUs regardless of the hardware. I think this is the only way we might see some sort of universal solution. Otherwise it's more likely to be a bunch of proprietary solutions which will be costly and possibly troublesome.

Yes and no. Quicktime is widely supported, which is good. The only real problem is this 0-255 RGB compatibility issue, which can be worked around today, and which should be improved before long. As you mention, it's a decoder issue.

The h.264 editing issue is independent of Quicktime. High data rate h.264 is CPU intensive, and it's long GOP to boot. For now, we have to expect to encode proxies. It would be nice if there were a transcoder that could fill in the P- and B-frames with I-frames. That would be quick and would remove the long GOP issue.

Personally, I think they nailed the codec in that that the quality is excellent, and the solution fits in the camera and it still has good battery life. We might be struggling to optimize things, but you can do edits (black crush and slow rates aside) out of the box with every HD NLE.

I agree - the codec is fine - the video coming from these files is gorgeous, but as a container Quicktime has been miserable to work with for years (esp. on Windows machines). This RGB colorspace issue just adds another reason supporting my general dislike of Quicktime. Maybe there's a perfectly reasonable explanation for it, but from my perspective it's a really boneheaded glitch. It could be fixed if there were some way to get into quicktime's decoder config so we could manually select the appropriate output, but that's just not an option. Several weeks ago, I poked around the internet looking for possible registry key hacks that could force quicktime one way or another, but I had no luck. That this particular issue is even a problem for Mac users says a lot too (for the record, my day to day machine is a macbook pro, though I choose to edit on the PC platform with Vegas).

I realize that H.264 is very resource intensive, but I think what we're seeing from a performance perspective is due more to suboptimal software at this point. I know it can be decoded and played with a locked down 30fps rate at 1080p with moderate CPU loads on my quad core system. But the h.264 compatible plugins (apple's and mainconcept's) on vegas are both pretty weak.

I think Canon should have gone with an ISO compliant MPEG-4 container in the first place, though MP4's limitations on compressed audio formats may have ultimately killed those chances.

I apologize beforehand, for repeating some basic concepts. Although there are excellent posts in this thread, it appears that a number of 5D MKII users are not all that familiar with a few video terminology and concepts and that's understandable, because many of these folks have migrated from the true DSLR world. Here are some very simplified thoughts :

1. The 5D MKII uses the h.264 codec, also referred to to as MPEG-4 Part 10 or MPEG-4 AVC. To read a h.264 file you need a decoder. To write an h.264 file, you need an encoder. These two types of software are referred to as "codecs". On PCs, you need a h.264 decoder to read the 5D MKII files properly. Most people have the freeware Apple Quicktime Player and decoder installed. If you have Apple Quicktime installed on a PC, QT will not read the 5D MKII files properly, as it defaults to studio RGB (sRGB), which does not use the complete 8-bit color range (0-255). The QT decoder only uses 16-235, so you are losing information at both the black and white ends of the color space. (0 being true black and 255 being true white in 8-bit color). You can see the extent of this problem, if you have an NLE that displays color histograms. CoreAVC makes an excellent (and almost free) decoder that will read the file properly and not crush the blacks. CoreAVC has an option to output computer RGB (0-255).

2. When an h.264 video stream is written to a file, it must also have some type of wrapper, that contains information in its header about the video's frame rate, width, height, etc.. The 5D MKII uses the Apple Quicktime wrapper, which has a file extension of MOV. This file format will work on both Apple and PC systems. There are other types of wrappers used for encoding video. The more common ones that you see are Video for Windows (AVI, the generic wrapper on Windows-based systems), MP4, WMV (Windows Media) and M2T (An HDV MPEG-2 stream). Sometimes the file extension tells you something about the codec used (like M2T) and sometimes it only tells you about the wrapper used (like AVI, which could have any one of a number of codecs wrapped inside). Thus, the 5D MKII produces an h.264 video stream within an Apple Quicktime wrapper. The codec that produced the original h.264 video stream in each MOV file, is built in to the hardware of the 5D MKII.

3. Sony Vegas uses its own built-in h.264 decoder and will not access CoreAVC to decode your 5D MKII MOV files. Adobe Premiere, After Effects also use their own plug-in, but any other video software that uses Windows DirectShow to access codecs will use CoreAVC, assuming that Core AVC has a higher file merit that the QT decoder. What is "file merit"? It is a priority number that signals to the Windows DirectShow video subsystem, which codec or filter to use when more than one option exists (like having QT and CoreAVC both installed). If you Google "DirectShow file merit" you will get a number of links that will explain this concept in greater detail.

In theory any software that uses Windows DirectShow should work. But both Adobe Premiere and After Effects will not use CoreAVC.

They automatically give QuickTime priority when decoding .MOV files. Without QuickTime installed they will refuse to open that container. If we could get that to work then transcoding would not be necessary at all (when using adobe products). CoreAVC is fast enough for realtime playback, trouble is that the NLE won't use it.

That's interesting. But what happens if you open a re-wrapped file in AE or Premiere? Does it use CoreAVC in that case? And if so, is it fast and smooth on the timeline? I switched from Premiere Pro to Vegas many moons ago...

I corrected the error in my post. I just assumed that it worked since I use CS3 & Cineform. What's really interesting is that people that have tried using AviSynth to force Premiere to use the DirectShow codec with the highest file merit still can't get it to work.

I'd be curious to know whether just changing the extension to .MP4 would work in this case if QT was not installed?

It *might* work but if the software is really strict with respect to the MP4 standards, it should fail to open it as it contains an audio stream ('sowt') that's illegal according to the MP4 standard. That's why you have to re-encode the audio as AAC during the re-wrap process I devised.

After some searching I found that to enable MP4 support Premiere needs to be updated to 3.02. I will try tomorrow and see if it works. Right now my version does not support the MP4 container at all.