MXF to FCPX not working? A possible fix

Ingesting C300 rushes using the Canon FCPX plug-in
Canon provide a free plug-in to enable the C300’s MXF files to import directly into FCPX without the need to transcode to ProRes. Many users report that they have no problems with the installation and it ‘just works’. However, other users with similar setups report that they cannot import C300 rushes in FCPX, though it works through Log and Capture in FCP7, additionally Adobe Premiere successfully imports C300 MXF. Only FCPX seems affected, and for a limted subset of FCPX users.

C300 rushes don’t work

Here’s the typical scenario: having run the xpfm211 installer. FCPX sees the folder structure, even the MXF files themselves, but does not recognise either. This is as far as some users get. For some reason, the installer has completed successfully, we are seeing files, but nothing imports. De-installing and re-installing brings the user back to this situation. Very frustrating.

After installing
After-installingTrying to track the activity of the installer, we see two new plug-ins highlighted in the MIO/RAD/Plugins folder – CanonE1.RADPlug and CanonXF.RADPlug. The latter would appear to be the ‘magic smoke’ for the MXF format. However, this isn’t working. There’s a second empty RADPlugins folder below – should the plugins be in there?
Moving the plugins
Moving-the-pluginsWhilst it may seem a bit ‘cargo cult’ to shift the contents from a RAD/Plugins heirachy to a RADPlugins, it was worth a shot. No, it didn’t work.
Comparing folders with a working configuration
Comparing-folders-with-a-working-configurationHere’s where it got interesting. I was able to confer with another editor who had a system that did import MXF successfully. The key difference was that he had a CanonXF64.RADPlug folder – not an XF, an XF64. I could not find a similar folder, nor could I make the installer create one. In the end, he just sent me a copy of that folder, and I dragged and dropped it into the same folder I had.
C300 rushes now appear normally
C300-rushes-now-appear-normallyAnd it worked! It’s pretty obvious because you can see the clips, but also note that the MXF folder heirachy has gone, replaced simply with the usual list of clips on a card or archive.
The Secret Sauce of C300 Import
The-Secret-Sauce-of-C300-ImportSo this folder appears to be the missing link. Depending on your system, the installer either creates this folder, or it doesn’t. Both of us had the XDCAMFormat.RADPlugin, removing both did not make my installer create this file, the only way was to use somebody elses copy. It would be useful to provide this folder as a download to those who need it, but license agreements seem to forbid this sort of activity – probably for good reason.
It comes down to an issue with the installer, which isn’t written by Canon staff, and so it’s difficult to work out who to alert to the situation. However, as seen here, access to the CanonXF64.RADplug folder cures the problem for now.

Ninja Blade – 2:2 Pulldown with Canon C100 Fixed

ninjabladeUPDATE: 2:2 PULLDOWN FIXED IN AtomOS 5.1.1…
Early adopters frequently find little snags that are quickly patched, and this week is no different. I have taken delivery of the new Ninja Blade recorder last week.

It’s an awesome piece of kit for the C100 user – but when I record 25PsF, I noticed that the images are shifted two pixels to the left with a black line running down the right hand edge.

Atomos support are on the case have fixed it, they suggest we update to version 5.1.1 here. we keep the C100 set to 25PsF and set the Ninja Blade to 50i. In FCPX and Premiere (I don’t use Avid) simply do the 2:2 pulldown trick by treating it like AVCHD footage, manually switching the files from interlaced to progressive as described in PSF – the fix.

As a C100 user, I am very impressed by the Ninja Blade in a number of areas:

  • screen quality and fidelity with the option to calibrate
  • ability to use a LUT when shooting C-Log
  • audio meters that put the C100’s to shame
  • waveform monitor and vectorscope
  • shot logging features – both live and after the shoot

Combine all this with very low power consumption, a lightweight chassis and a wide range of media choices, it closes the gap between the C100 and C300.

I’ll do an in-depth review when I’ve cleared my current workload, and I’ll go into a bit of depth over the shot logging facilities which will really make a difference to shooting interviews and long form events such as presentations and conferences.

But not now. I really should be editing! Until then, remember the 50i to 25p trick.


Well, it’s easy to deal with this little inconvenience in PAL-land. If you shoot in 24p or 23.976 PSF mode, you’ll find the same black line, so you’re recommended to shoot in 59.973 and you’re on your own.

So, whilst I don’t shoot for 24p or 23.976 most of the time,  when I shoot 29. 973 it’s fairly easy. So I had to find a solution that would make shooting 24p (or 23.976) work. It appears that the only way is to transcode the rushes. So…

With a drum roll and a nod to Abel Cine and all those who got there before me, here’s an Apple Compressor droplet that sorts your Ninja rushes out before you import them:

Apple Compressor Droplet.

C100 noise – the fix

The Canon C100 is an 8 bit camera, so its images have ‘texture’ – a sort of electronic grain reminiscent of film. Most of the time this is invisible, or a pleasant part of the picture. In some situations, it can be an absolute menace. Scenes that contain large areas of gently grading tone pose a huge problem to an 8 bit system: areas of blue sky, still water, or in my case, a boring white wall of the interview room.


Whilst we set up, I shot some tests to help Alex with tuning his workflow for speed. It rapidly became obvious that we’d found the perfect shot to demonstrate the dangers of noise – and in particular, the C100’s some-time issue with a sort of pattern of vertical stripes:

Click the images below to view the image at 1:1 – this is important – and for some browsers (like Chrome) you may need to click the image again to zoom in.

So, due to the balance of the lighting (couldn’t black the room out, couldn’t change rooms), we were working at 1250 ISO – roughly equivalent to adding 6dB of gain. So, I’m expecting a little noise, but not much.

Not that much. And remember, this is a still – in reality, it’s boiling away and drawing attention to its self.

It’s recommended to run an Auto Black Balance on a camera at the start of every shoot or if the camera changes temperature (e.g. indoors to outdoors). Officially, one should Auto Black Balance after every ISO change). An Auto Black Balance routine identifies the ‘static’ noise to the camera’s image processor, which will then do a better job of hiding it.

So, we black balanced the camera, and Alex took over the role of lit object.

There was some improvement, but the vertical stripes could still be seen. It’s not helped by being a predominantly blue background – we’re seeing noise mostly from the blue channel, and blue is notorious for being ‘the noisy weak one’ when it comes to video sensors. Remember that when you choose your chromakey background (see footnote).

The first thought is to use a denoiser – a plugin that analyses the noise pattern and removes it. The C100 uses some denoising in-camera for its AVCHD recordings, but in this case even the in-camera denoiser was swamped. Neat Video is a great noise reduction plug-in, available for many platforms and most editing software. I tried its quick and simple ‘Easy Setup’, which dramatically improved things.

But it’s not quite perfect – there’s still some mottling. In some respects, it’s done too good a job at removing the speckles of noise, leaving some errors in colour behind. You can fettle with the controls in advanced mode to fine tune it, but perversely, adding a little artificial monochrome noise helped a lot:

We noticed that having a little more contrast in the tonal transition seemed to strongly alter the noise pattern – less subtlety to deal with. I hung up my jacket as a make-shift cucoloris to see how the noise was affected by sharper transitions of tone.

So, we needed more contrast in the background – which we eventually achieved by lowering the ambient light in the room (two translucent curtains didn’t help much). But in the meantime, we tried denoising this, and playing around with vignettes. That demonstrated the benefit of more contrast – although the colour balance was hideous.

However, there’s banding in this – and when encoded for web playback, those bands will be ‘enhanced’ thanks to the way lossy encoding works.

We finally got the balance right by using Magic Bullet Looks to create a vignette that raised the contrast of the background gradient, did a little colour correction to help the skin tones, and even some skin smoothing.

The Issue

We’re cleaning up a noisy camera image and generating a cleaner output. Almost all of my work goes up on the web, and as a rule, nice clean video makes for better video than drab noisy video. However, super-clean denoised video can do odd things once encoded to H.264 and uploaded to a service such as Vimeo.

Furthermore, not all encoders were created equal. I tried three different types of encoder: the quick and dirty Turbo264, the MainConcept H.264 encoder that works fast with OpenCL hardware, and the open source but well respected X264 encoder. The latter two were processed in Epsiode Pro 6.4.1. The movies follow the above story, you can ignore the audio – we were just ‘mucking around’ checking stuff.

The best results came from Episode using X264

Here’s the same master movie encoded via MainConcept – although optimised for OpenGL, it actually took 15% longer than X264 on my MacBook Pro, and to my eyes seems a little blotchier.

Finally Turbo264 – which is a single pass encoder aimed at speed. It’s not bad, but not very good either.

Finally, a look at YouTube:

This shows that each service tunes its encoding to its target audience. YouTube seems to cater for noisy video, but doesn’t like strong action or dramatic tonal changes – as befits its more domestic uploads. Vimeo is trying very hard to achieve a good quality balance, but can be confused by subtle gradation. Download the uploaded masters and compare if you wish.

In Conclusion:

Ideally, one would do a little noise reduction, then add a touch of film grain to ‘wake up’ the encoder and give it something to chew on – flat areas of tone seem to make the encoding ‘lazy’. I ended up using Magic Bullet Looks yet again, pepping up the skin tones with Colorista, a little bit of Cosmo to cater for any dramatic makeup we may come across (no time to alter the lighting between interviewees), a vignette to hide the worst of the background noise, and a subtle amount of film grain. For our uses, it looked great both on the ProRes projected version and the subsequent online videos.

Here’s the MBL setup:

What’s going on?

There are, broadly speaking, three classes of camera recording: 8 bits per channel, 10 bits per channel and 12 bits per channel (yes there are exotic 16 bit systems and beyond). There are three channels – one each for Red, Blue and Green. In each channel, the tonal range from black to white is split into steps. A 2 bit system allows 4 ’steps’ as you can make 4 numbers mixing up 2 ‘bits’ (00, 01, 10 and 11 in binary). So a 2 bit image would have black, dark grey, light grey and white. To make an image in colour, you’d have red green and blue versions stacked up on top of each other.

8 bit video has, in theory, 256 steps each for red, green and blue. For various reasons, the first 16 steps are used for other things, and peak white happens at step 235, leaving 20 steps for engineering uses. So there’s only about 220 steps between black and white. If that’s, say, 8 stops of brightness range, then a 0.5 stop difference in brightness has only 14 steps between them. That would create bands.

So, there’s a trick. Just like in printing, we can diffuse the edges of each band very carefully by ‘dithering’ the pixels like an airbrush. The Canon Cinema range perform their magic in just an 8 bit space by doing a lot of ‘diffusion dithering’ and that can look gosh-darn like film grain.

Cameras such as the F5 use 10 bits per channel – so there are 1024 steps rather than about 220, and therefore handle subtlety well. Alexa, BMCC and Epic operate at 12 bits per channel – 4096 steps between black and white for each channel. This provides plenty of space – or ‘data wriggle room’ to move your tonality around in post, and deliver a super-clean master file.

But as we’ve seen from the uploaded video – if web is your delivery, you’re faced with 4:2:0 colour and encoders that are out of your control.

The C100 with its 8 bit AVCHD codec does clever things including some noise reduction, and this may have skewed the results here, so I will need to repeat the test with a 4:2:2 ProRes type recorder, where no noise reduction is used, and other tests I’ve done have demonstrated that NeatVideo prefers noisy 10 bit ProRes over half-denoised AVCHD. But I think this will just lead to a cleaner image, and that doesn’t necessarily help.

As perverse as it may seem, my little seek-and-destroy noise hunt has lead to finding the best way to ADD noise.

Footnote: Like most large sensor cameras, the Canon C100 has a Bayer pattern sensor – pixels are arranged in groups of four in a 2×2 grid. Each group contains a red pixel sensor, a blue pixel sensor and two green ones. Green has twice the effective data, making it the better choice for chromakey. But perhaps that’s a different post.

C100 Chroma Subsampling – the fix

c100The C100’s AVCHD is a little odd – you may see ‘ghost interlace’ around strong colours in PsF video. AVCHD is 4:2:0 – the resolution of the colour is a quarter of the resolution of the base image. Normally, our eyes aren’t so bothered about this, and most of the time nobody’s going to notice. However, stronger colours found in scenes common to event videographers, and when ‘amplifying’ colours during grading, all draw attention to this artifact.

Note that this problem is completely separate from the ‘Malign PsF’ problem discussed in another post, but as the C100 is the only camera that generates this particular problem in its internal recordings, I suspect that this is where the issue lies. I’ve never seen this in Panasonic or Sony implementations of AVCHD.

This is a 200% frame of some strongly coloured (but natural) objects, note the peculiar pattern along the diagonals – not quite stair-stepped as you might imagine.

Please click the images to view them at the correct size:

There are stripes at the edge of the red peppers, and their length denotes interframe movement. These artefacts illustrate that there’s some interlace going on even though the image is progressive.

Like ‘true’ interlacing artefacts, these stripey areas add extra ‘junk information’ which must be encoded and compressed when delivering video in web ready formats. These are wasting bitrate and robbing the image of crispness and detail. Reds are most affected, but these issues crop up in areas of strong chrominance including fabrics, graphics and stage/theatrical lighting.

Some have pointed the finger of blame at edit software, specifically Final Cut Pro X. I wondered if it was the way FCPX imported the .MTS files, so I rewrapped them in ClipWrap from Divergent Media. In version 2.6.7, I’ve yet to experience the problems I experienced in earlier versions, but the actual results seem identical to FCPX:

For the sake of completeness, I took the footage through ClipWrap’s transcode process – still no change:

So the only benefit would be to older computers that don’t like handling AVCHD in its natural state.

To isolate the problem to the recording format rather than the camera, I also shot this scene on an external recorder using the Canon’s 4:2:2 HDMI output and in recorded in ProRes 422HQ. The colour information is far better, but note the extra noise in the image (the C100 includes noise reduction for its AVCHD recordings to help the efficiency of its encoding).

This is the kind of image one might expect from the Canon C300 which records 4:2:2 in-camera at 50 Mbits per second. Adding an external recorder such as the Atomos Ninja matches the C300’s quality. But let’s say you don’t have the option to use an external recorder – can the internal recordings be fixed?

RareVision make 5DtoRGB – an application that post-processes footage recorded internally in the 4:2:0 based H.264 and AVCHD codecs, and goes one further step by ‘smoothing’ (not just blurring) the chroma to soften the blockiness. In doing so, it fixes the C100’s AVCHD chroma interlace problem:

The results are a very acceptable midway point between the blocky (stripey) AVCHD and the better colour resolution of the ProResHQ. Here are the settings I use – I’ll do a separate guide to 5DtoRGB in a separate post.

The only key change is a switch from BT.601 to BT.709 (the former is for US Standard Definition, the latter is for all HD material, a new standard is available for 4K).

So why should you NOT process all your C100 rushes through 5DtoRGB?

It takes time. Processing a 37 second clip took 159 seconds (2 mins 39 seconds) on my i7 2.3 GHz MacBook Pro. Compare that with 83 seconds for ClipWrap to transcode, and only 6 seconds to rewrap (similar to Final Cut Pro’s import).

You will have to judge whether the benefits of shooting internally with the significant transcode time outweigh the cost of an external recorder and the inconvenience of using it. You may wish to follow my pattern for the majority of my non-chromakey, fast turnaround work, where I’ll shoot internally, and only when I encounter difficult situations, opt to transcode those files via 5DtoRGB.

I’ve also been investigating the use of a ‘denoiser’. It’s early days in my tests, but I’ve noticed that it masks the ‘interlaced chroma’ stripe pattern is effectively hidden:

This is not a panacea. Denoising is even more processor intensive – taking a long time to render. My early testing shows that you can under- and over-do it with unpleasant results, and that the finished result – assuming that you’re not correcting a fault, but preparing for a grade – doesn’t compress quite as well. It’s too slick, and therefore perversely needs some film grain on top. But that’s another post.

Canon C100 PsF – the fix


The Canon C100 produces a very nice, very detailed image just like its bigger brother, the C300. However, the C100 uses AVCHD as its internal codec and Canon have chosen (yet again) a slightly odd version of this standard that creates problems in Non Linear Edit software such as Premiere Pro and Final Cut Pro X (excellent article by Allan Tépper, ProVideo Coalition).

Unless you perform a couple of extra steps, you may notice that the images have aliasing artifacts – stair steps on edges and around areas of detail.

PP6 – Edges before:

Here’s an example of the problem from within Adobe Premiere Pro, set to view the C100’s AVCHD footage at 200%. Note the aliasing around the leaves in the centre of the picture (click it to see a 1:1 view). Premiere has interpreted the progressive video as interlaced, and is ‘deinterlacing it’ by removing alternate lines of pixels and then ‘papering over the cracks’. It’s not very pretty.

PP6 – Interpret footage:

To cure this, we must tell Premiere that each 25psf clip from the C100 really is progressive scan, and it should lay off trying to fix something that isn’t broken. Control click your freshly imported C100 clips and select ‘Modify’ from the pop-up menu, then select ‘Interpret Footage…’

Alternatively, with your clips selected, choose ‘Interpret Footage…’ from the ‘Clip –> Modify’ menu.

Modify Clip

In the ‘Modify Clip’ dialog, the ‘Interpret Footage’ pane is automatically brought to the front. Click on the ‘Conform to:’ button and select ‘No Fields (Progressive Scan)’ from the pop-up:

PP Edges after

Now your clips will display correctly at their full resolution.

Final Cut Pro X – before:

The initial situation looks much worse in FCPX, which seems to have a bit of an issue with C100 footage, even after the recent update to version 10.1.

Select imported clips

The key to the FCPX fix is to let FCPX completely finish importing AVCHD before you try to correct the interlace problem. If you continue with these steps whilst the footage is still importing, changes will not ‘stick’ – clicking off the clips to select something else will show that nothing has really changed. Check that all background tasks have completed before progressing.

First, select all your freshly imported C100 clips. Eagle-eyed readers may wonder why the preview icon is so bright and vivid whilst the example clips are tonaly calmer. The five clips use different Custom Picture profiles.

Switch to Settings in Info tab

Bring up the Inspector if hidden (Command-4), and select the Info tab. In the bottom left of the Inspector, there’s a pop-up to show different Metadata views. Select Settings.

Change Field Dominiance Override to Progressive

In the Settings view of the Info pane, you’ll find the snappily titled ‘Field Dominance Override’, where you can force FCPX to interpret footage as Progressive – which is what we want. Setting it as Upper First will cater for almost all interlaced footage except DV, which is Lower First. Setting it back to ‘None’ lets FCPX decide. We want ‘Progressive’.

Final Cut Pro X – after:

Now the video displays correctly.

The before & after:


FCPX upgraded to 10.1

Logo-FCPXOkay, I admit it. On the stroke of midnight, I was pressing the refresh button in the App Store. New FCPX! New Toys!

So – FCPX 10.1 is out. Do I need to upgrade? Yes – there’s enough changes in the system that address current issues. But it requires a major jump in operating system – when your computer is your major money-earning tool and it’s stable and reliable, you don’t touch it unless you have to. I have to switch from Lion 10.7.5 to Mavericks 10.9, and that’s a big leap.


  • Build a new bootable drive with FCPX 10.1 to experiment on – you may not want to update yet
  • Clone your drive to a bootable image (to return to in weeks and months to come) with SuperDuper or Carbon Copy Cloner and make a fresh Time Machine backup – make sure they all work before you proceed!
  • Copy older projects to work with, don’t use originals – Philip Hodgetts has made EventManager X free! Use it to manage your project updates.
  • Prepare for some ‘spilled milk’ with Mavericks (for me, Exchange email is broken)

At first, I thought it odd that Apple released FCPX 10.1 so close to a major worldwide holiday, but on reflection – it’s perfect. Rule 1 of upgrades: never upgrade during a job. Things can go wrong, things like backups and archives invariably take more time than you thought, and what if it’s all horrible and you need to back track? Smaller jumps, a minor ‘point-oh-one’ upgrades can be welcome relief, but this is a ‘point-one’ and it needs an OS upgrade to boot (pun not intended).

The safest option for me is (having backed up your main machine of course) to unwrap a brand new hard drive, format it and install the latest OS on it, then boot from THAT. Install the new software on the fresh OS, and play with COPIES of older projects that you copied across. New versions of software often change the file format and rarely is it back-compatible. You want to play in a protected ‘sand-box’ (I preferred ‘sandpit’ but hey…) so you don’t accidentally convert your current projects to the new system and find yourself committed to the switch.

Really, that is the safest way – but its frustrating as the performance of a system booted on an external drive isn’t quite what you’re used to, and it’s a bit clunky. Plus, it will take time to do the official switch – you’ll have to rebuild your apps, delete old versions that don’t work, sort out new workflows, new versions, reinstall, find license agreements, it all takes time (and it’s not billable for freelancers). But until you’re sure that the new OS won’t kill your current must-use apps, you can simply shut down, unplug, and return to your current safe system.

Then of course there’s the impatient teenager in all of us who, after backing up, installs the new OS on top of the old OS, downloads the new app, finds what’s broken in the rest of the system and fixes it, finds out that a few tools don’t work, plug-ins need shuffling, projects don’t render as they used to, fonts have gone missing… All this takes longer, funnily enough. And then there’s the creeping rot of a brand new operating system ‘installed in place’ over the old one. I did this ages ago, and the problems didn’t show until 12 months on and we’d gone through some minor version changes and bug fixes. Serious, serious problems that impacted work (and backups, and archives). If you’re jumping from 10.X to 10.Y (especially to 10.Z) it’s worth the time it takes to do a proper clean install.

And of course once it’s done, you still may need to be able to go back to the ‘old’ system – so you’ll need to clone – not back up or archive but CLONE – your old system before you start, if only for the comfort factor of running back to it when the new system refuses to do something.

So, I’m spending the first day having to NOT download the update, but format drives, archive disks, install software whilst reading and watching the sudden deluge of 10.1 info. (Note to self – Matt: don’t touch that button! Don’t do it!)

Alex4D has a bunch of links to get you started, training from Ripple and Larry Jordan (hopefully IzzyVideo will have some new stuff soon too), discussion forums already alight with debate… and a week or two of holiday season to enjoy it all in.

(And Apple’s official take)

POV’s 2013 Documentary Filmmaking Equipment Survey

Whilst the number of respondents is a bit too low to be a true picture, POV’s survey does paint an interesting picture of the Documentarist’s world. It’s still a ‘buy’ rather than ‘rent’ market, for the best part in love with Canon’s DSLRs and lenses.

However, there’s a couple of splits  I wanted to see, but isn’t here. Firstly the split by sensor size: what has happened to 2/3″, and what proportion are now S35? Secondly, and somewhat related, body design. There still seems to be plenty of room for ‘the little black sausage of joy’ – the fixed lens, all-in-one camera with a wide-ranging parfocal zoom.

Yes, the Mac dominates in Docco editing. I boggle slight at the FCP7 market – twice that of all the Premiere Pro flavours. FCP7 used to bog down with over 35-40 mins in a timeline, and for larger projects I’d have expected a larger takeup of Premiere Pro.

Still, at least Gaffer Tape makes it into the top 5 ‘things we love’ list.

POV’s 2013 Documentary Filmmaking Equipment Survey