Editing Throughput (Warning-contains tedious spreadsheet)

[BTM_Pix]

I'll give you fair warning that this thread will probably not be most, if anyone's, cup of tea !

And will probably be of zero interest if you are working on narrative projects where you have more time and control and have a broader artistic vision.

But it might be worth a look if you are a hack like me and considering doing some vlogging or other quick projects.

OK, so, I've got some projects coming up over the next few months (that quite large bicycle race they have every year around France being one of them) where I'm going to be doing a lot more video stuff and the nature of most of it means it needs quick turnaround.

I've been doing a lot of testing recently in preparation for this regarding cameras and ancillary packages and workflow etc and one of the things I'm butting up against is trying to find a balance between an image that I'm happy with and getting it out quick enough where it won't have be re-packaged as an historical documentary.

Obviously, I need to sort out where the bottlenecks lie and I've been doing some testing today to nail some actual comparison figures down that will hopefully force me to make a definitive decision as its so easy to get bogged down and have paralysis by analysis.

The requirement I have is to be able to bring footage in that may not have been shot in ideal circumstances - whether that be to do with location, preparation time and/or just plain incompetence - and make it look decent within time and my own correctional ability constraints and have it be consistent enough to be repeatable to be able to do day in day out whilst traveling and without overtaking my primary gig at these events which is shooting stills.

The other requirement is that I'll be shooting this stuff on small stuff like GX85/G7/Mavic/Osmo and X-T2 so there won't be a lot of RAW going on here or even LOG to be honest so this is where it starts to get me bogged down as on the one hand there isn't massive latitude on the way in and then often way too much potential on the way out to go down a rabbit hole time wise trying to polish them a bit. 

Added to that is that I'm not going to have a massive amount of computer horsepower on the road so whatever I do is going to have to be done with FCPX so, again, I'm trying to minimise the potential for endless fiddling about for that reason as well.

Which also brings me to the other issue which is that having everything in H264 coming off these cameras is adding to that pain as well.

My options then are :

1) Use a flat profile in the camera that requires a corrective LUT from the get go

2) Use a standard picture profile in the camera

3) Use either option 1 or 2 but record them externally in ProRes

Option 1 gives me the most scope for correction but also for time loss, option 2 gives me the best route for speed and consistency (by forcing me to 'learn' the profile and not be reliant on fixing it in the mix) and option 3 makes whatever one I choose a lot easier to shuffle around inside of FCPX.

The downside of using the external ProRes recording option is that its bulky, power consuming and eats up hard drive space.

The compromise option to keep the ease of use within FCPX is to transcode the camera files to ProRes before they get there and in the case of option 1 add the corrective LUT at the same time.

What I needed to do though was see exactly what the comparative times were like using the different options so I can find the sweet spot. 

Or the least worst option as the case may be.

So I shot a 10 second clip on the G7 both in a Flat profile and a standard one (Cinelike D to be exact) internally to the card and then with the same profiles out again to the Atomos Disco Inferno *

All files were then copied to a regular USB3 external work drive.

I took the Flat and Cinelike D H264 files through a few typical journeys through FCPX, which were

 

1) Straight through (with the corrective LUT applied in the case of the Flat profile)

2) With a basic exposure and colour balance applied

3) As 2 but with an additional Sharpen and addition of a 'style' LUT applied

4) As 2 but with an additional Sharpen and FilmConvert process applied

 

I then did exactly the same passes after converting the in camera H264 files into ProRes using EditReady (with the correctional LUT for the Flat file added in the transcode) and then the same again with the externally recorded ProRes versions.

For a bit of sport, I then went for the absolute fastest path possible which was to plug in the SSD from the Atomos and edit the ProRes files straight off that.

If you are still awake, you can see the results in the spreadsheet I've attached. 

The results are not in the least bit surprising as - spoiler alert - ProRes files with minimum fiddling absolutely cane H264 files that need massaging but its informative to me at least to see the extent of it quantified within how I would use it.

What's interesting is that the H264 files do OK at the beginning but this is largely because the copying and/or transcoding time of the ProRes files goes against them before they've even got into FCPX but once the heavier lifting comes in they are soon overtaken by the ProRes versions. And the cumulative effect of the multiple corrections needed to be applied to the Flat version also add up dramatically, especially when FilmConvert comes into the equation of course. And then finally when creating what would largely be my target output format of 1080p rather than the 4k timeline, it ends up being even worse.

Its worth bearing in mind that this is only a 10 second clip so its not difficult to imagine how alarming that 60 times real time render would feel like on something a bit more substantial. Yes, of course, it should be expected that it will take a while with FilmConvert on it but its sobering to see thats already 6 times real time without anything but the required correctional LUT on it. In comparison, the Cinelike D H264 version is half the time and only begins to be drawn back to it when FilmConvert is applied.

And the conclusion?

Well the gold standard in this test in terms of getting the fastest throughput is the externally recorded Cinelike D ProRes read straight from its own SSD so thats no surprise and would be the way to go for me in terms of shifting stuff if I master the profile and retain control of the shooting situation (or the serenity to accept that I can't) and don't mind lugging around something that is significantly bigger, more power hungry and unwieldy than the cameras its attached to.

The other non surprise is that the Flat profile whether in H264 or transcoded to ProRes is the worst performer. Bearing in mind that this test just measures file transfer/rendering time then the additional time in finessing the Flat profile (which would be substantial in my case) makes this an order of magnitude worse.

Which leaves us with trying to find the sweet spot which in this case would be split between Cinelike D in H264 if it was only going to be lightly touched or a transcoded version if it needed more work. There is a balance to be found between the two because whilst there is a time and disk space penalty to the transcoding, it does pay off even if you don't go to heavier correction because FCPX plays much nicer with ProRes files full stop.

My conclusion for these summer projects then is to stick with an in camera profile, work within its parameters instead of changing them or ignoring them and take the transcoding time hit at the beginning of editing. And buy more hard drives, obviously.

 

* Yes I know its Ninja Inferno but its just stuck in my head as Disco Inferno now and I'm ceasing resistance.