-
The Next FCPX Update
-
[Walter Soyka] “Doesn’t MC do this with DNxHD?
FCP7 is still somehow a serious competitor to FCPX with this workflow, and is one of the four big NLE apps (FCP7, FCPX, MC, Pr) people are using, so it doesn’t seem fair to exclude it from consideration.”
MC does it with DNxHD with a transcode or rewrap. It does not extract native frames (via AMA or whatever) and rewrite native frames. At some point, you are going to have to go down to DNxHD in either 1080 or 720. Pr at least gives you the potion to keep native frame size and frame rate of the individual clips (as does FCPX) on transcode.
[Walter Soyka] “I think it did work, but the supported formats were really restrictive, so maybe that’s the “real well” part. Who works exclusively with DVCPRO HD anymore?”
This is part of my point in why copying all of the clips is not that far fetched or a bad idea. Who works exclusively in any one format anymore?
[Walter Soyka] “If you’re already optimizing media to ProRes, what’s the big deal? “
But what if you are NOT optimizing to ProRes? I don’t optimized to ProRes hardly ever in FCPX. I find there is little need, and it is a waste of disk space. None of the cameras, Alexa excluded, that I routinely work with shot in ProRes or .mov, and FCPX is handling them just fine.
[Walter Soyka] “Also, the only technical requirement for consolidate/trim without transcode is intraframe compression (and you could probably do it with interframe compressed material if you padded the requested handles to fit the GOPs). You wouldn’t have to transcode everything to a common codec unless you were doing it as a courtesy to the next application in the tool chain.
“It’s not that easy, especially with formats like MXF which have their own metadata requirements, and not to mention, proprietary codecs, and different atom structures. So you could flip it all around to a new generic MXF file, but that’s a rewrap and doesn’t get you back to the original media very easily (you aren’t simply going to reconnect an op1a MXF to an op-atom MXF). So a transcode solves all of that, if you need to trim media, but it takes away any metadata workflows with RAW formats, and creates more media.
I’m just saying, there’s a good reason why this capability isn’t in FCPX for now as it’s not as easy as it could be, and without QTKit, it might not be possible at all with current AVFoundation limitations.
[Walter Soyka] “Now that we have multiformat timelines, we need consolidate with transcode. It’s kind of a new need, because the last generation of NLEs dealt with a single codec only by design. When you know for a fact that everything on your timeline is DNxHD or ProRes, you can take shortcuts.”
Sort of. With ProRes, it’s harder to do this if you aren’t on a Mac. With DNxHD, it’a hard to send to other people in a the sneeze of MXF files that Avid creates. Adobe’s MXF solution (or GoPro .mov) does solve a lot the format problem, but it’s not an end all solution. Collect files, which Adobe and X do quite well, is a much more thorough solution. It ensures nothing gets left behind, and you can always match back to the original edit. You can trim the media during the color grade and archive that.
Jeremy
-
[Jeremy Garchow] “It’s not that easy, especially with formats like MXF which have their own metadata requirements, and not to mention, proprietary codecs, and different atom structures. So you could flip it all around to a new generic MXF file, but that’s a rewrap and doesn’t get you back to the original media very easily (you aren’t simply going to reconnect an op1a MXF to an op-atom MXF). So a transcode solves all of that, if you need to trim media, but it takes away any metadata workflows with RAW formats, and creates more media.”
Copying frame data from one container to another, even if they’re of the same type, is essentially re-wrapping, so even in the optimal scenario it’s not possible to trim media without re-wrapping.
Proprietary codecs have their downsides, but in a well-designed container format, you should still be able to copy frame data from one container item to another without actually having to know how to decode it.
You’re describing what’s possible with today’s tools. I’m describing what’s possible from a data perspective. Pretty much the only time that recompression is strictly necessary is when you’re modifying pixels.
We just don’t have good tools for doing any of this. We’re asking for them. Adobe, Apple and Avid aren’t delivering. I have high hopes for MOX [link], but it’s an uphill battle.
[Jeremy Garchow] “I’m just saying, there’s a good reason why this capability isn’t in FCPX for now as it’s not as easy as it could be, and without QTKit, it might not be possible at all with current AVFoundation limitations.”
That good reason is that it wasn’t a priority. This is something a media framework (AVFoundation, MediaCore, etc.) could provide, if required.
[Jeremy Garchow] “Collect files, which Adobe and X do quite well, is a much more thorough solution. It ensures nothing gets left behind, and you can always match back to the original edit. You can trim the media during the color grade and archive that.”
Collect files is a sledgehammer. Trim is a scalpel. Different use cases.
Personally, I prefer the collect files philosophy, too, but it’s not always practical. After that, I prefer consolidate and transcode. If you’re going to make a whole set of new media, you may as well make it all as easy to handle as possible.
What are we debating exactly?
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
[Walter Soyka] “What are we debating exactly?”
That trimming media is somehow, easy.
Invariably, these debates always end up that X can’t do what “Y” can do, so I think it’s best to look over at Y, and wonder why.
Or, why can’t X do this when Legend did? Often the reason is because “it’s not that simple” rather than “WTF, Apple?”.
There are good, technical, reasons for not having the trim and consolidate function at this time. One of them being that FCPX is, pretty much, a native format editing application, unlike FCP7, and it runs on an entirely different architecture with a different workflow. QTKit was pretty good at reaching and grabbing the necessary frames, and pulling them out to a new container without a transcode cycle. AVFoundation doesn’t seem very capable of this at this time, and who knows if it will ever get there.
-
[Jeremy Garchow] “That trimming media is somehow, easy.”
None of this is easy. Whether it’s worth the effort to develop is a separate question.
[Jeremy Garchow] “There are good, technical, reasons for not having the trim and consolidate function at this time. One of them being that FCPX is, pretty much, a native format editing application, unlike FCP7, and it runs on an entirely different architecture with a different workflow. QTKit was pretty good at reaching and grabbing the necessary frames, and pulling them out to a new container without a transcode cycle. AVFoundation doesn’t seem very capable of this at this time, and who knows if it will ever get there.”
I know that we have gone off on a tangent about smart trimming, but really, who is asking for that? I think just about everyone here asking for trimming would be quite happy with ProRes-transcoded trims of native media (or smart trims of ProRes material, which can surely be done today, even with AVFoundation [link].
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
I think smart rendering and trimming are related but very different.
One basically marries together a linear block of media in a set frame rate and frame size that is not related to the original media at all. Yes, X seems to have this capability.
A consolidate/trim is a an exact subset of media that is directly related via metadata, to a larger media pool. While the actual technical process is related, the end result is very different.
-
Here’s a nice perspective on a year with the new MP and FCPX, from Peter Wiggins
Bill, please note what he mentions at the end!
-
Jumping into this thread a little late, but…
I get the frustration. Avid has had consolidate media with handles forever. One of the knocks on FCP Legacy was that they were late to the consolidate party and their implementation was, shall we say…less than reliable. For sure, the ability to transfer only the used media was important, especially when pulling only a short bit from an hour’s worth of loaded footage.
And this is where I think I see the disconnect in this discussion.
Much of the media ingesting I did in past years was of the “put in the tape and capture the whole thing” variety. When I had 10 tapes full of synched dailies, they were rarely logged, and I rarely had the time to sit and log the tape in a bin and then batch capture each take. So I often ended up using lots of short bits from one tape. To have to copy over that whole one hour file just for the 3 minutes I may have used would have been ridiculous.
But virtually all media I deal with these days is shot to cards or drives. It comes in short bursts, with a new clip created with each take (or other camera start/stop). Yes, some directors like to let the camera “roll” for ten minutes at a time. But mostly the files are no more than a few minutes long.
So the idea of copying a 2 minute take, of which I’ve used 40 seconds, doesn’t seem like such a big deal. It’s not as if I’m forced to copy the unused takes.
Now, I know that transferring 10 minutes of R3D 4k footage is a pain compared to 1 minute of that footage. But, really, if I’m transferring that kind of footage, then I’m copying to a drive and shipping or messengering the drive to the next guy. It’s not as if I’m uploading 50 gigs of footage (unless I’m a big boy with my own T1 line or some other studio-grade file transfer system in place).
Now, in promo land, I often work with pulling clips from one or more 48 minute episodes of a show. That’s 20 or 30 gigs per episode. In that case, I’d sure like to be able to trim that deliverable footage to the few gigs I actually used. So hello Clip Exporter or Primaries Exporter. Should this functionality be included in X? Ideally. But there’s a way around it for now.
I’m inclined to go with Jeremy here in guessing that if it were simple, X would already have this built in. Otherwise, one is forced to go to the “Apple has forsaken the pro user” argument, which is just stupid.
-
[Jeff Markgraf] “I’m inclined to go with Jeremy here in guessing that if it were simple, X would already have this built in. Otherwise, one is forced to go to the “Apple has forsaken the pro user” argument, which is just stupid.”
Apple doesn’t just pick low-hanging fruit. If it were important to them, it would have shipped. If they only developed what was simple, FCPX would not be the impressive product that it is.
Development prioritization weights user benefit against developer cost. Assuming some fixed development budget, choosing to develop feature A means postponing feature B. I argue this is a relatively simple feature, but not worth taking time away from other development. This doesn’t mean I must think Apple has forsaken the pro user.
Apologies in advance if I’m being overly argumentative, but I’m curious what you guys think the too-hard-to-be-worth-it part is. Exporting a consolidated, trimmed sequence is doing stuff NLEs already do, systematically for every clip in the project.
FCPX can already read media and transcode it to ProRes. It can already smart-render, I think. It can already relink clips from one source file to another. It can already output only a section of finished media from a longer source.
What’s the missing link?
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
They’ve seemingly been edging towards this for the last few updates. 10.1 obviously changed the whole architecture underlying media management- so it was likely smart to postpone any development on this front post 10.1. 10.1.2 expanded the depth and easy of exporting XMLs for Event and/or Project, as well as simplifying media storage location and media consolidation.
Really the only thing missing here is media trimming, with optional ProRes Transcoding on command.
-
[Marcus Moore] “They’ve seemingly been edging towards this for the last few updates. 10.1 obviously changed the whole architecture underlying media management- so it was likely smart to postpone any development on this front “
Makes a lot of sense. The complexity of what they did in 10.1 shouldn’t be underestimated.
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn]
Reply to this Discussion! Login or Sign Up