Will X Export Faster than 6?

[Mathieu Ghekiere]

Difficult Question…

1. The reason why your exports are taking so long, I think are because of 2 things:
– the Timecode Filter. It takes ages to render. It’s just fact.
– You’re talking about rendering a low resolution video. FCP6 and 7 only use like 2 cores or something, so it’s better to export a full resolution movie with timecode, and then rendering a low resolution from that in Compressor. That way you are not giving old 32-bit FCP 7 a hard time rendering 2 things at once (compressing + timecode filter) and you can use a Cluster in Compressor to make a lower resolution video faster.

2. Will X render faster… X renders effects faster, often, yes. And with the last 10.0.6 update it also can export in the background, so you can work further. I would still recommend doing the same there, first exporting a full resolution Master File, and exporting a lower resolution later from Compressor.
BUT, kicker… In X you only have a Timecode READER filter, not a timecode GENERATOR filter. Maybe that isn’t a problem to you, I just let you know.
Other, more serious problem… The timecode filter only gives you the timecode of your sequence in FCP X, and not the timecode of your source clip… Can be a big hurdle. It used to work with a (free) 3rd Party Timecode Reader filter by LeoHans, but since the 10.0.3 update it stopped working.
I think Alex4D has a big work-around on his website now, but it’s that: a big work-around.

[Ned Miller]

Uh Oh!!! Are you saying the time code reader has nothing to do with the source timecode? I suppose I just need it for the clients to choose which takes to use so I will be OK.

Thank you

Ned Miller
Chicago Videographer
http://www.nedmiller.com
www,bizvideo.com

[Bill Davis]

[Mathieu Ghekiere] “In X you only have a Timecode READER filter, not a timecode GENERATOR filter. Maybe that isn’t a problem to you, I just let you know.”

WHile this is technically accurate, I’ll just note that you can do the exact same function in X – you just have to do it the way X works.

For a reason.

Once upon a time, the average shooter had ONE camera that used one system. Even if you had two or three cameras from two or three of the major manufacturers – there was still consistency since a handful of manufacturers could agree to standards.

Today that’s NOT the real world. My timeline might have footage from a dozen sources. Pro Cams, Handy-cams, GoPros, Cel phones, whatever. And many of them don’t know timecode from Esperanto.

Timecode once marked the boundary between amateur and pro – but decreasingly so.

Why? Because technology has largely moved beyond it. TC is a very rough construct created for a world of broadcast TV.

But today, the digital timekeeper in software is orders of magnitude more precise than “frames”. (which is why you can now work at sub-frame accuracy in realms like audio!) So TC frame tracking is nice, but less necessary then ever before.

So if you’re the designer of a product like X – how much effort do you direct toward a timecode standard that has already been surpassed at the deepest level of the software – and isn’t even a part of more and more content creation devices?

If your working habits want a TC “Generator” X gives you a way to do that via metadata. Just create a new project (a new metadata expression) and change the base timecode of that expression.

Once again, X is reflecting the real world – not holding too tightly to the way things were once done – just because that’s how they were once done and a lot of skilled people are more “comfortable” working that way.

Time code is a rough system from a rough era. We’re working in a microprocessor era now.

FWIW.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Ned Miller]

The only reason I need burned in TC is for the client to choose takes. Also, it’s in Portuguese so I need fairly exact numbers. That’s why I did the burn it.

What options are there? I miss VHS window dubs!

Ned Miller
Chicago Videographer
http://www.nedmiller.com
www,bizvideo.com

[Jeremy Garchow]

[Ned Miller] “What options are there? I miss VHS window dubs!”

FCPX used to allow a custom built motion template for a tc reader.

It is now broken, for whatever reason, and there’s no alternatives.

There’s a tc generator filter, but it has to be the weirdest filter ever created as the tc keeps changing depending on what kind of container your clip is in.

If you move any piece of the sequence, the tc also changes.

TC needs a ton of help in FCPX, I don’t care what Bill Davis says. 🙂

Jeremy

[Mathieu Ghekiere]

Sorry Bill, but I have to disagree there.
The function indeed needs work, and you can’t just give your example of why it is necessary.

I’ll give you another one…

We often record medical videos. If an operation happens, we record from multiple feeds.
The sources are often medical monitors, with things like an echo of a heart, heart meassure monitors (EKG), endoscopic views, and a boom view of the operation table.

We don’t record Audio in every single source. We timecode all these recordings. Recordings are often multiple hours long.

If I’m together with a client (a doctor), and we edit the video, and we are going trough a frame and he wants to see what happens on another medical monitor or something, for me it’s very quick to find. Look at the source timecode, type it in and get immediately to that timecode in another video which I don’t visually understand (I’m not a doctor, I just see 4 hours of black and white material that I don’t understand, but they do!). So yes, Timecode IS important!

That’s only one example. If we need to sync all these sources in a timeline, so 6 sources in a 4 hour timeline, we can do it very quickly now with the timecode viewer overlay in FCP 7. I don’t even have to have audio in every source, I can just visually see it and objectively see it.
Afterwards you put a timecode reader on ONE of the sources in a split screen, if you want to export a copy for the client to see. Yes, I want that timecode reader to be on the SOURCE timecode, so if the client makes comments with timecode notes, I can quickly go and see in the SOURCE material where it is, and I’m not locked in a sequence/timeline (especially not one that is magnetic).

We had a source timecode reader before 10.0.3, and because Apple changes something in the way Motion behaved with Timecode Generators, it doesn’t work anymore, and it’s a pitty. That, and having a timecode HUD again is one of my most requested features of FCP X.

And btw, a multicam sequence isn’t always helpful for us, because we often need to edit with picture-in-pictures. So, although I’m checking in how far I can use FCP X for this with new methods of working (Synchronizing clips based on the same timecode, haven’t tried it before, except for synching audio and video) , it’s still some work-around for what could be better.

[Erik Lindahl]

If you just want to render clip with TC burnt in Compressor can do that for you as well.

25s 1080p25 ProRes 422HQ clip to an “Apple Device 5 Mbps” on my MacPro 2008 8-core we’re talking:

– 78 seconds with TC filter on
– 68 seconds with TC filter off

Not the fastest encoder on the planet I’ll give you that but roughly 3X realtime. 29 minutes would take around 90 minutes if the above math is correct. But then you have a small reference file ready to go.

Running TC filter ON but with-out multi-pass H264 and you’ve got about 42 seconds rendering time for 25 seconds HD-video. Here 29 mins would take around 50 mins and would hold more than enough quality for selecting shots.

[Bill Davis]

[Mathieu Ghekiere] “And btw, a multicam sequence isn’t always helpful for us, because we often need to edit with picture-in-pictures. So, although I’m checking in how far I can use FCP X for this with new methods of working (Synchronizing clips based on the same timecode, haven’t tried it before, except for synching audio and video) , it’s still some work-around for what could be better.”

Sorry Mathieu, but after reading your post, I simply can’t find anything in your discription of your workflow that X can’t do right now the way it’s set up.

If you have timecoded sources selected in the Event Browser that all have the same start point, you can just type the timecode you want to reach in the HUD and X moves the playhead there.

Multicam is happy to match timecode, OR audio, or anything else you like it, including a hand-set marker.

You can use or not use the multicam view regardless of what you do on your timeline. So PIP is truly trivial.

Maybe I’m just dense, but from your description it seems that your dissatisfaction comes largely from an inadequate understanding of the X database and timeline operations.

X doesn’t do everything. But it does most things perfectly well. And I’ve found that typical timecode operations are one of them. The BIG difference is that rather than the interface coming pre-set to handle timecode as the default – it’s an optional expression that you have to set up.

I don’t find anything objectional with that since fewer and fewer of my sources make timecode a pervasive necessity – but that doesn’t mean it’s not there or that X can’t accomodate it if you like.

And Jeremy, is what you dislike about X’s approach to timecode largely a a reflection of YOUR workflow, or do you think it’s a universal element that ALL those who use X will find to be a lack?

I understand those who live and die by it. I did as well for more than 20 years. But I’m trying to break out of a LOT of the thinking that I relied on for the past 20years.

Particularly if there’s new thinking that makes it easier.

I don’t know anything about Mathieu’s workflow. But I can’t help but wonder if he simply learned the prep stage of range key wording his clips by operation and angle starting his range on the same frame on every clip angle – then everything from Operation A in a group of clips that’s at (+10503) would EXACTLY match every other clip in that bucket at the SAME keystroke location.

And since his Project can be set to reflect EXACTLY the same starting point as the EB clips – he can find and match anything numerically just using the HUD.

In that scenario – “originating timecode” is totally irrelevant isn’t it?

Metadata to the rescue once again.

Or is my thinking wrong here?

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Mathieu Ghekiere]

Hi Bill,

I do know how FCP X works, and I know about keywording etc. It’s one of the reasons I’m using it for a project right now which has many many clips.

And I admitted in my first post that I still have to do some testing in how to possibly edit operations in FCP X using another workflow, it’s on my to-do list. So you are right that I have some testing to do to see how we can edit such operations in X, but X doesn’t (seem) to make it as easy as in 7.
Again, I reserve final judgement, but whatever conclusion I come up with, you are not going to persuade me in the fact that Timecode isn’t important anymore, and that the timecode HUD in FCP X doesn’t lack.

But that doesn’t mean I thought about it a lot.

For instance:
now we often record on a Nanoflash, which splits its recording over clips that are no longer then 13 minutes (depending on the codec). The cameraman who runs around in the OR runs around with a timecode locked camera, and does not record it all in one take (depending on the operation).
Sometimes a Nanoflash seems to miss a couple of frames, if I put them on the timeline, sync with the other sources in FCP 7. It happens, but we can very quickly re-adjust based on the timecode overlay in the canvas. Where I see ALL the timecodes of everything on my timeline at once. And if they are the same, they are all green, if not, one is purple, seeing it very quickly visually if something is off.
If I don’t, it could be that a clip that contains no audio, is of a patient monitor of a close-up of a device a doctor in holding, doesn’t match with the first layer of the complete recording with audio. But I wouldn’t never know, because doctors were masks, so you can’t see their mouth, and there are also monitors which we don’t understand the information from anyway.
In FCP X, the timecode HUD is only of your sequence, unless you also use clip skimming, but it really is much more difficult to compare timecodes going trough each layer, especially with skimming which can be very sensitive, in comparison with just seeing an overlay with ALL the timecode layers on that moment in time.
The magnetic timeline doesn’t help too. If I finally put them above each other, and I cut something away, and it moves, it can mess up sync, and I would not know because not everything contains audio and there are no visual cues for me, except for skimming trough every clip on the timeline again.
Yes, there are ways to get around the magnetic timeline (shift+delete, the position tool), but it’s more easy in this case to do make errors. If you made an error in FCP7, I would immediately see it in the timecode overlay.

Multicam wise, there you can pick your angle. But doctors often want to see multiple angles at once. So then you would have to put multiple multicam clips above each other. Now, I know you can also synchronize multiple video angles in X, placing them above each other, but I haven’t tried it out yet, and it’s definately on my to do list. I really will have to see how it works, so I’m gonna reserve some judgement there.
I’m afraid that you very quickly loose sight of the ORIGINAL timecode of your source clips, and in our case, that’s very dangerous because we as non-doctors are often not equiped to notice that immediately.

Your advice about the keywording, I will definately take in if I do that testing in FCP X, but don’t forget that as the Nanoflash spits its recording out in many files, and the cameraman record in many smaller clips, it would require a lot of work-arounds in keytaggin, multiple keyword collections, etc.
And only because FCP X doesn’t contain a better timecode HUD which FCP 7 had with its timecode overlays. If one operation takes me one click in FCP X, and 5 in FCP7, using new methods, I’m not afraid to defend FCP X. But if the opposite is truth, we should be critical of FCP X, and hope that it gets better in future releases and not say that ‘oh well, timecode is irrelevant anyway’.

BTW: we are looking into new recording options too, that will record on longer SSD’s in one take, and get audio and timecode from every source together. A lot of what probably makes editing an operation in FCPX more difficult, will vanish then, but again, the lack of not having a source timecode reader filter (or generator), and not having timecode overlays that immediately show you which timecode everything on the timeline has now, makes for possible work-arounds and lots more of keywording, tagging, ranges selecting up frond. Which is that it will take a lot more time for certain operations then now in FCP 7 where we can just drop these clips in folders, and place them quickly on a timeline, put a timecode READER or generator filter on it, and be done with it. I can do this for a 4-hour case in 10 minutes, beginning to end if there are no complications. Even with your methods of tagging, keyword-collections, etc; it will take me a lot more time.
The reason why we are looking into it, is because FCP X is in many ways a better tool in using the hardware, and some very nice features that I already miss not having in FCP 7.

[Bill Davis]

Mathieu,

I appreciate the time and effort you took in your post. And I also appreciate that you’re giving the software a chance.

That’s all that’s required.

I will note that as someone who’s already climbed a large part of the X learning curve, I’m more convinced than ever that one of the most daunting issues with it is that since it requires learning a lot of new concepts, it’s very difficult for those who haven’t gone up that learning curve and who don’t work with it regularly to “visualize” how the same tasks they’re used to doing in traditional editors might be approached in X.

Essentially, I’m saying that there are a LOT more tools inside X than many outside of it’s user base generally understand – and that the better one understands it, the easier it becomes to see it’s value.

This is why I think there’s been such a slow (if steady) path for adoption. When you get inside, it’s great. But it’s hard to understand why from the outside. And I fully appreciate that it’s initial adoption is often a act of faith.

Hopefully, as more high end editors in pro shops explore it and discover it’s strengths – it’s “acceptability” will continue to increase – because more and more of us are convinced that its an amazingly good tool.

After all, one truth that’s very hard to deny is that it’s currently the most “rapidly developing” software platform out there (based on released significant revs). And unlike most programs that get “major upgrades” measured in years – X has seen steady and amazingly rapid incremental expansion of it’s core capabilities.

I believe that’s as a direct result of it’s new architecture.

But regardless of why – it’s another reason to keep it on any editors radar.

Anyway, thanks again for your post. One of my local contacts does much of the medical video work for the local Mayo Clinic hospital and is keeping a close eye on X as well. I suspect that in this area where ID issues around asset tracking might literally turn out to be life and death issues – it might be an area where X will, in the long term, really shine.

We’ll see.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.