Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Creative Community Conversations The Next FCPX Update

  • Jeremy Garchow

    February 6, 2015 at 4:10 pm

    Ironically (or not!), through this whole discussion, I have been working with this type of method (needing to send an edit with media to graphics) and FCPX has been working flawlessly. Each 30 second spot results in 30-60GBs of material (there’s a decent amount of time-lapse and slow motion in these spots, so the files are large). After Effects has given me some issues with collect files, and if it dumps out in the middle for some reason (I get an inordinate amount of “file not found” errors), the resulting project is some sort of hybrid between collected files and not collected files. It’s frustrating.

    For yucks, I have sent these Ae comps to Pr to test out the Project Manager. It seems to go OK, for some reason it doesn’t transcode certain individual files, but will transcode other individual files of the same make up, and Pr appends .mov to the end of files, sometimes giving them two extensions such as filename.mxf.mov. Surely, I’m holding something wrong.

    Those trimmed files (with 2 second handles) result in 10GBs of ProRes files, so no matter what, I am not uploading this stuff, but rather transferring to a drive. I’d rather use the method that works the most reliably most of the time, and so far that’s been FCPX. 😛 :-0 🙂

    Jeremy

  • Jeff Markgraf

    February 6, 2015 at 6:05 pm

    Well, yes.

    Didn’t mean to suggest that Apple can’t or won’t do “difficult.” I think, as I discussed above, that the consolidation-style media management isn’t seen by Apple as particularly important, what with the preponderance of small-ish files coming from modern cameras. If they saw this as an important feature, they’d get on it. I would assume it doesn’t meet their cost-benefit threshold for now.

    So it would seem ripe for a third party to do this. Like Primaries Exporter. Or a video-enabled version of X2Pro. I’m not a techie, so I don’t know if there’s an issue truncating R3D files or the various long-GOP files without first transcoding to ProRes or some such all I-frame format. After all, Avid’s consolidation works on its own MXF files and doesn’t deal with other formats. Maybe there’s a reason (besides Avid’s usual…Avid-ness!).

  • Bill Davis

    February 7, 2015 at 9:53 pm

    [Steve Connor] “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!

    https://www.fcp.co/final-cut-pro/articles/1595-the-mac-pro-and-final-cut-pro...”

    I did.

    Peter’s a good guy. I used an example of his workflow on my Virtual Users Group appearance with his permission.

    In this whole debate, I’ve come to believe that Jeff Margraff decoded my position pretty well. I’m entirely file/card based. So I don’t do hour long captures. If I did, the pain of lacking more traditional media management options would effect me more. So it’s not really on my personal radar as a big deal.
    But I understand that this doesn’t mean it’s not for others.

    I remember a personal conversation with the late and very much missed Ralph Fairweather at NAB many years ago where he was talking about just digitizing full DVCAM tapes to use Final Cut Pro V2 to manage the clips afterwards, rather than doing sectional log and capture.

    (For those of you who weren’t around in that era, Ralph was the quasi official conduit between the original Apple development team and those of us trying to learn the software in the early days – appearing on the very early FCP editing websites like 2-pop to help us solve out problems back when the program was very young.)

    I never warmed to that “grab it all and sort it out later” workflow. Likely because in the early days, storage was expensive and I couldn’t afford to fill up hard drives willy nilly.

    So it’s another example of “how I need to do it, isn’t the same as how the other editor needs to do it.”

    But that acknowledged, it’s often useful to look at the TRENDS. Is the trend long, unbroken captures – or, as Jeff suggests, more card and file captures in smaller discrete chunks? I think it’s clearly the latter. But the needs of those who work with the former have to be respected.

    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.

  • Walter Soyka

    February 8, 2015 at 10:51 am

    Jeremy, if you’re seeing issues with Ae’s collect files or Pr’s project manager, please consider filing bug reports so they can get fixed.

    Walter Soyka
    Designer & Mad Scientist at Keen Live [link]
    Motion Graphics, Widescreen Events, Presentation Design, and Consulting
    @keenlive   |   RenderBreak [blog]   |   Profile [LinkedIn]

  • Andrew Kimery

    February 9, 2015 at 12:07 am

    [Bill Davis] “But if you’re one of us silly fools who actually like editing in X, and you just want to get this done to your clips before exporting them – Richard shows a clever and pretty fast way to do that as a batch process with minimal keystrokes using dashboard trimming, and, cleverly the reverse retiming function.”

    Unless I’m misunderstanding the video, that’s not what we are talking about. That example changes all the edits in the timeline by adding more media to the beginning and end of each clip. What we are talking about is being able to trim down to just the media used in the timeline with a user determined amount of handles on both sides of each edit point (the edit points themselves are not changed). The handles allow for flexibility down the line so that if (more likely when) a few edits are tweaked here or there the online/grading person can mirror those changes on their end w/o requiring the editor to send over new media.

    I know it’s not as amazingly innovate as Publish to Vimeo, but it certainly has its place and can save a lot more time than than just a few minutes (both for the person sending the media and the person receiving the media). Can workflows work even if they are more labor intensive than they need to be? Sure. I mean, Avid is used on a t-o-n of multicam shows but it’s multicam prep (same as FCP Legends) b-l-o-w-s compared to X and PPro. Can the guys working on Focus successfully post a Hollywood feature w/o a consolidate and trim media function? Sure, but that doesn’t mean their workflow couldn’t be improved by, say, having a robust consolidate and trim media function (interesting how the Hollywood workflow gains more relevance when X is involved as opposed to when FCP Legend, PPro or Avid are involved but that’s a whole other thread…).

    [Jeff Markgraf] “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. “

    For scripted I can see that, but for doc/unscripted there are still 30-60min long takes. Even on a feature though I can see the media adding up when you are talking about a couple thousand edits and each edit carries with it extraneous media. Again, not show stoping but not ideal either. The process on your end takes longer, copying it to/from the transfer drive takes longer, it eats up more space at the online facility, etc.,.

    [Jeff Markgraf] “I’m not a techie, so I don’t know if there’s an issue truncating R3D files or the various long-GOP files without first transcoding to ProRes or some such all I-frame format. After all, Avid’s consolidation works on its own MXF files and doesn’t deal with other formats. Maybe there’s a reason (besides Avid’s usual…Avid-ness!).”

    I’m not a techie either, though FCP Legend could perform a consolidate and trim with handles to GOP media, but all GOP media was re-wrapped into the MOV container on import in order for FCP to be able to recognize it. Doing it with camera native file formats might be more complicated, but to a laymen like myself I feel like if the NLE can decode the media down to the frame then it should be able to to export it frame accurately as well and if it can export it frame accurately what’s the big deal about giving the user the ability to add handles?

    Even if the feature only worked on some codecs I would still like the option to use those codecs and get consolidate and trim. “It’s not a requested enough feature to be worth our while” is certainly a viable (if disappointing) excuse because at the end of the day no company can offer a product that’s all things to all people. As users all we can do is ask and hope for positive response.

  • Jeff Markgraf

    February 9, 2015 at 6:19 am

    Andrew –

    I agree that it would be nice to have the trim media function available. Even though I don’t need it much any more, I know it’s important for others. Even if it’s only available for certain formats, such as ProRes, one can make a decision about what format to shoot, or whether to optimize, in light of the need to consolidate.

    Regarding your suggestion that since an NLE can decode such a file with frame accuracy, it should be able to truncate and output the same way: I don’t think it’s nearly that simple. From my admittedly basic understanding, reading a long gop file requires reading an I frame, then creating groups of b and p frames both in front of and after the I frame. Editing on anything other than an I frame requires decoding the whole group in order to make a new I frame at the frame used for the edit. I’m sure Oliver or Jeremy or another big brain will jump in here to correct me if I’ve gotten this wrong.

    I think there’s also an assumption here that Avid DnX files are long gop files. I don’t think they are. I don’t think MXF is synonymous with long gop. If they are in fact all I frame, then consolidating is as easy as it would be with ProRes.

  • Michael Gissing

    February 9, 2015 at 7:51 am

    Jeff, mxf is just a wrapper like .mov. DNxHD codec family is very much like ProRes. Compressed but not GOP.

    DNxHD can also be .mov wrapped. To the issue of truncating, as Andrew has pointed out, the doco world still has long shots and huge ratios. They are rarely r3d or anything other than ProRes, DNxHD or GOP/AVC type codecs where truncating has been normal in Legend and is missed by some but not all in X.

    I guess expressing a desire for this functionality is mopping up the last of the functionality of Legend that is still useful in current workflows for many. Again a third party developer may pick up the slack. I think it is fair to point out where slack remains however.

  • Andrew Kimery

    February 9, 2015 at 7:58 am

    [Jeff Markgraf] “Editing on anything other than an I frame requires decoding the whole group in order to make a new I frame at the frame used for the edit. I’m sure Oliver or Jeremy or another big brain will jump in here to correct me if I’ve gotten this wrong.

    FCP Legend could consolidate and trim w/handles interframe codecs (HDV, XDCAM family, etc.,) though those codecs were wrapped into MOV upon ingest into FCP. If you made a QT reference movie then any interframe codecs in the timeline got exported out as new media which makes sense because, as you said, the GOP cadence can’t be interrupted.

    I don’t know how much more complicated it is to, say, work with native XDCAM HD files vs ones re-wrapped into MOV but an NLE can natively import, edit and export an interframe codec like XDCAM HD then I don’t see why it can’t perform a consolidate and trim with handles as that’s basically just a batch export of every clip in the timeline. Granted, at least the way FCP Legend worked, for intraframe codecs it was basically creating a copy of just the used portion of the source QT file (so no recompression occurred) where as with the interframe codecs new media had to be created so another round of compression happened. Whether or not the media would take a quantifiable quality hit probabley depends on the source.

    To Jeremy’s point, this maybe a limitation of AV Foundation compared to QTKit in which case the solution to the problem could be much more complicated (if possible at all).

    [Jeff Markgraf] “I think there’s also an assumption here that Avid DnX files are long gop files. I don’t think they are. I don’t think MXF is synonymous with long gop. If they are in fact all I frame, then consolidating is as easy as it would be with ProRes.”

    AFAIK Avid’s codecs are intraframe though Avid does support some interframe codecs natively (like XDCAM). I haven’t worked with native interframe codecs in Avid so I don’t know if they present any unique problems when consolidating or not.

  • Walter Soyka

    February 9, 2015 at 1:40 pm

    [Jeff Markgraf] “From my admittedly basic understanding, reading a long gop file requires reading an I frame, then creating groups of b and p frames both in front of and after the I frame. Editing on anything other than an I frame requires decoding the whole group in order to make a new I frame at the frame used for the edit.”

    This is true if you’re talking about inputting and outputting native long GOP media.

    Long GOP cannot be arbitrarily split; the cuts have to fall on closed GOP boundaries. It’s also possible to close an open GOP by re-encoding just a few dependent frames instead of the entire asset.

    Walter Soyka
    Designer & Mad Scientist at Keen Live [link]
    Motion Graphics, Widescreen Events, Presentation Design, and Consulting
    @keenlive   |   RenderBreak [blog]   |   Profile [LinkedIn]

  • Walter Soyka

    February 9, 2015 at 1:52 pm

    [Andrew Kimery] “To Jeremy’s point, this maybe a limitation of AV Foundation compared to QTKit in which case the solution to the problem could be much more complicated (if possible at all).”

    Careful! There’s a hidden Apple-doesn’t-care-about-pros argument in there. AVFoundation started life as the iOS mobile media framework, and since has been extended to the desktop. QTKit started life as a multimedia authoring framework. If FCPX can’t trim media, it’s the iPhone’s fault! (I kid, somewhat. My relationship with AVFoundation/QTKit is complicated.)

    It seems almost silly to say, but let’s also not forget that Apple develops AVFoundation, too, and if they wanted to include these features, they could. They also developed QTKit and so they know a thing or two about how to do this stuff that’s “missing.”

    Speaking of replacing old code with new, here’s a classic from developer Joel Spolsky on re-writing code from scratch. It’s called “Things You Should Never Do, Part I [link].”

    tl;dr of all my posts in this thread — If trimming were critical to Apple’s vision for FCPX, we’d probably have it already. It’s nowhere near as hard to implement as, say, a roles-based mixer. It’s just a question of balancing priorities. Trimmed consolidation would be cool to have, but unless trimmed media is a strict workflow requirement for you, this is a tempest in a teapot. FCPX is not that “far behind;” Pr just got this a couple months ago!

    Walter Soyka
    Designer & Mad Scientist at Keen Live [link]
    Motion Graphics, Widescreen Events, Presentation Design, and Consulting
    @keenlive   |   RenderBreak [blog]   |   Profile [LinkedIn]

Page 9 of 10

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy