Use Quicktime Pro? I'm sure there's some sort of batch work around for it somewhere.

@shian

5DtoRGB is really only for turning mts files into something we can edit.

Mmmmm, not entirely. Not for me. Not when you're talking CS6. That may be the case for some systems running older software. Working with MTS/MP4 files directly in an editing package is as much or more about software as it is hardware. The same system that chugs trying to do it in CS4 likely works just fine running CS6...but there's the rub: CS6 does a bad job of transcoding the MTS.

Beyond the "digital rain" artifacts produced by the Main Concept libraries, it simply doesn't do as good a job with filtering MTS files for grading.

Granted, this may be also more the fault of the Main Concept libraries and not necessarily Adobe's but I've noticed it in my own footage. I haven't investigated whether they've solved this issue with CC or not.

I keep footage as MTS while editing, because I get great realtime performance. Then when the edit is locked I transcode the appropriate clips and conform for grading.

I should probably clear up any ambiguity about what 5DtoRGB is doing, so here goes.

ProRes files always use broadcast levels. This is something I have no control over, and are written (and read) that way by the ProRes codec. This is also the correct way to do it, because it keeps compatibility with everything else in the post pipeline.

MTS, MOV or any other file compressed with H.264 are primarily 8 bit. That means they have 0-255 possible values for luminance. This is the case even if the camera shoots "broadcast" levels. If it does, there is still data in the file from 0-15 and 236-255, but it is usually nothing that contains any picture information. That is the way it is supposed to be, anyway. The reality is oftentimes very different.

I'll use the example of a camera that shoots to MTS files. MTS files are typically understood to contain video levels in the 16-235 (broadcast) range. However, some cameras still write data over 235. That's right. Sometimes the camera will write highlight data -- that's real information -- above 235. This data will be clipped in any normal NLE or software that doesn't give the option to transcode full range because it assumes, more or less correctly, that no data exists over 235. This is a fault of the camera, not the NLE. I've seen it happen plenty of times, even with cameras that shoot to MP4 files. That's why I added the option to 5DtoRGB to force the use of the entire 0-255 range. So, even though it's supposed to be that cameras shoot 16-235, they don't always stick to the plan, and clipped highlights are the result. You would never even know this was happening without trying to transcode the clips as full range, because any other piece of software that doesn't allow this (and most don't) would never give you the option.

If you don't notice a "flatter" image after transcoding using the full range setting, this is probably because the source is already full range. In this case, using the broadcast range setting will give a much more contrasty image because 5DtoRGB is only considering the data within 16-235 (it is clipping shadow and highlight detail). This is also why footage that is genuinely broadcast range looks correct when using the broadcast range setting, but looks low-contrast when transcoded as full range (even though there may be some extra highlight detail, so keep that in mind).

I hope that helps!

@Rarevision

However, some cameras still write data over 235

I suspect the data over 235 levels comes from sharpening which is applied to the file after it has been remapped to 16-235 (the sensor shoots 0-255 but video gets remapped to 16-235 somewhere down the image processing pipeline). I suspect all picture styles are applied in 8bit mode after the file has been remapped to 16-235 ...

Anyway... thanks for posting!

Have you guys done testing to DPX? I just did a series of tests with my Rokinon 85mm Cine at various ISOs and E/V levels as well as some comparisons of profiles and exported everything through 5DtoRGB out to DPX which was then played back through a high end Christie cinema projector. The export settings were Rec709 Broadcast. Initial observations - nothing I didn't already know. This is with Moon T7. Image detail was very good. Shadow areas were noisy (if cleaned up with Neat Video using a chart on set to create a noise profile, I'm sure this would end up looking very clean), dynamic range is limited as we all know but outside of some extreme DR range I was able to control exposure with ND, and overall the images held up really well projected on 14 ft screen. I was not able to test motion properly as I only have a basic tripod with me at the moment and the head is not fluid enough to do a proper test. I've been watching Alexa footage projected on this same projection system for the past weeks. This is a movie being shot by a Hollywood DP, so naturally the footage looks really great and as expected beats out the GH2 in almost every way. However, I will say that the GH2 holds it's own. The areas where it can't compete are dynamic range, motion, color rendition, and resolution. But the fact that the GH2 looks as good as it does for $800, especially seeing these uncompressed DPX files projected is very cool. I await the BMPCC to compare against the GH2 which is a much fairer comparison. I suspect that camera will replace my GH2 as my compact rig. But I'm not willing to make that claim just yet. Still need to do the tests.