Forum Replies Created

Page 67 of 96
  • Joe Marler

    May 2, 2017 at 12:58 pm in reply to: Markers or Metadata – The Debate!

    [Franz Bieberkopf] “I’m not sure why you label sequence-based organization as a “primitive method” – both are as old as film (at least).”

    As you described, sequence-based organization is as old as film itself. They didn’t have computerized asset management in 1930. Today we do. In that sense solely using sequence-based organization is primitive. This doesn’t mean it should be shunned or isn’t useful. However there’s a difference between using sequence-based organization vs using only that. Using Premiere + CatDV or Avid Interplay or FCPX, you can mix and match whatever degree of database vs sequence-based organization you want. It’s not like you are restricted to one method — unless your product doesn’t provide that capability.

    [Franz Bieberkopf] “…If you’re not convinced that this method is valuable, productive, creative, and necessary given 3 examples of working editors using it, how many examples would it take? What would convince you? By what standard are you going to dismiss them?

    I’m not saying using sequence-based organization isn’t valuable or useful. You can do that in FCPX anytime you want. But you are not restricted *solely* to that. I don’t dismiss sequence-based organization, only that rigidly holding solely to that method is restrictive given the technology now available. If that by itself was always sufficient, nobody would use MAMs.

    [Franz Bieberkopf] “…The implication in your posting seems to be that Frederick Wiseman is “inefficient” is his filmmaking. My question would be this: how do you judge the efficiency of filmmaking? You will be quite able to find someone who can “finish” faster on any given project (including Wiseman’s films). Would that be “more efficient” in your mind?”

    Wiseman himself now shoots digitally and edits on Avid. He admits it enables him to find content faster. He is philosophical about whether it speeds up the overall process, but in no interview has he analytically evaluated this. It’s just a gut feel — metaphysical. If he can find content faster using Avid, then *something* is being sped up, and he’s productively spending that time elsewhere.

    [Franz Bieberkopf] Wiseman: “’I got the idea as I get all my ideas: I take a lot of showers.”

    Walter Murch once said something similar, and here is Edgar Burcksen’s (LucasFilm, EditDroid) view of that (18:47):

    https://youtu.be/z99wO2utddo?t=1127

    [Franz Bieberkopf] Wiseman: “….Jackson Heights was 170 hours [of raw material].  The film was just a bit more than three hours, I think.  Shooting ratio roughly of 60/1.  During the shooting, I just collect sequences….”

    Of *course* he just collects sequences. That’s all his software can do. He’s not going to saw wood with a hammer. Through decades of experience, he is familiar with that ingrained working style. This is why the EditDroid had a shuttle dial just like a KEM, and graphically presented tracks like a flatbed editor, because editors would otherwise have difficulty learning it: https://youtu.be/dZNffHkQOdA?t=222

    We’re now 33 years past EditDroid, and computers can do a lot more to assist than just mimicking tracks of film and mag tape.

    Some contents or functionalities here are not available due to your cookie preferences!

    This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

  • Joe Marler

    May 2, 2017 at 11:49 am in reply to: Markers or Metadata – The Debate!

    [Andrew Kimery] “I think deep and thorough asset management is more useful in some instances than others. For example, on reality TV shows I don’t think it’s that paramount because the lifespan of these projects is so fast. “

    Avid thinks it’s very important for reality TV, and pitch their Interplay MAM for this: ‘The high shooting ratios and multiple camera angles of Reality TV and unscripted programming pose enormous challenges in managing and logging more media than ever before,” said Chris Gahagan, senior vice president of Products and Services at Avid.”‘ https://www.avid.com/fr/press-room/2013/04/avid-interplay-production-simplifies-file-based-production-environments

    So the debate is not between FCPX and Premiere but between using an asset manager vs not using one. Does Vashi’s demonstration mean that feature films can be always be efficiently made without an asset manager? Does it mean that much larger projects with higher shooting ratios can always be efficiently made just using timelines and bins? Then who is buying and using Interplay, CatDV, etc. and for what?

    I’m not saying media asset management must be used, but it’s just a logical progression. Over the decades as the data management burden has grown, we first used paper, then index cards, then spreadsheets, and finally databases. This is in many fields, not just film & video production. In the 1960s, Boeing designed the 747 on paper and kept track of the six million parts using file folders. Today they design new airliners with CAD which is linked to a component database.

    If it’s not beneficial to tag, keyword and organize content, then why does Adobe Lightroom support this? Why not just keep all the photos in named folders (ie bins), and make collections (ie stringouts) for various groups of interest? We widely accept the benefit of database tagging and keywording for stills, so why not video?

  • Joe Marler

    May 2, 2017 at 10:31 am in reply to: Markers or Metadata – The Debate!

    [Shawn Miller] “Wow, what level of compression and how many layers of Redcode Raw?”

    That was three layers of 7:1 6k from a Red Weapon. However upon further testing it seems Premiere CC 2017.1 is actually faster than FCPX on the same 2015 iMac 27 for that codec. My recollection was a year or so ago FCPX was faster. Vashi was using Premiere from a year or more ago, so maybe today he wouldn’t need that many cores. Premiere seems to have gotten considerably faster over the last 1-2 years, especially for H264.

    This shows how Apple cannot lollygag on performance issues, because the competition is always improving. While FCPX is generally very fast, it has less performance leeway than Premiere or any other editor. E.g, a slower version of Premiere is just a bit slower — you can still get work done. By contrast a slow skimmer or Event Browser is almost unusable — it essentially removes those features from the table.

  • Joe Marler

    May 1, 2017 at 9:50 pm in reply to: Markers or Metadata – The Debate!

    [Shawn Miller] “What’s wrong with that? Dual 10 core workstations aren’t exactly rare as modern workstations go.”

    It was a dual-socket 40-core Dell 7910, about $17,000 not including the storage and monitors. Nothing wrong with that — in fact it’s good they could afford those since he said Premiere on a Mac Pro wasn’t fast enough. Of course the Mac Pro is plenty fast enough to edit Red Raw 6k using FCPX, since I can do that on my iMac.

    But since everyone doesn’t use FCPX, Apple must deliver the necessary hardware performance, else they are relegated to providing editing platforms that are only viable for FCPX. Vashi’s case is just one example of what increasingly happens. Had the Mac Pro been fast enough (or available in a more robust configuration) he’d have probably used that. As it was Apple lost the sale and Vashi bought several Dell workstations. That’s what happens when Apple doesn’t update hardware for three and 1/2 years in a performance-critical market segment.

  • For 1080p H264 content, you normally don’t need to use optimized or proxy media. Most decently-equipped contemporary Macs are fast enough to edit that natively. You don’t even need to import it to the library — you can normally import it with “leave files in place”. Exceptions are AVCHD and XAVC content which are in the original folder structure.

    If you have already created proxy or optimized media, this can be deleted by selecting the even or library, then File>Delete Generated Library Files, and selecting all the checkboxes. This will only delete scratch and temp material, never the original content.

    Since you have already imported media to the library, that can either be left there or moved outside the library using the Consolidate function. You can Google various instructional videos about this. Or you can leave that content inside the library and import subsequent additional content using “leave files in place”.

    Normally even a MacBook Air is fast enough to edit 1080p H264 content natively. If you are editing multicam, you might need proxy files in that case.

  • Joe Marler

    May 1, 2017 at 2:06 pm in reply to: Markers or Metadata – The Debate!

    [Oliver Peters] “He seemed to imply that Vashi’s technique would be less useful with non-scripted content.”

    I think it is less useful in those cases. The fact that documentaries have been made using traditional editing & organizational methods since 1922 doesn’t change this. Frederick Wiseman edited his 1968 High School documentary by himself — but it was shot on a single 16mm Bolex camera, and only used a 25:1 shooting ratio: https://www.zipporah.com/films/21

    For Titicut Follies he shot 37 hr and his shooting ratio was 26:1, however it took him 14 months to edit: https://www.zipporah.com/films/22

    When Ken Burns edited The Civil War, he said “it took more than two years of absolutely solid work, with ten or twelve of us working six days a week, ten hours a day”. It was edited on a flatbed Steenbeck. Yet it was “only” 50,000 ft of 16mm film, which at 24 fps and 36 feet per min equates to 23 hours of material:
    https://www.btlnews.com/crafts/post-production/technicolor-postworks-helps-restore-the-civil-war/
    https://archive.org/stream/Documentary_Filmmakers_Speak/Documentary_Filmmakers_Speak_djvu.txt

    If Wiseman had access to GoPros and flash-storage cameras he’d have probably used them. In 1988, if Burns had access to a MAM he might have used it, which would have shortened the two-year edit time.

    We have those today, and shooting ratios can be over 300:1 for docs, but in many cases we’re still using organizational methods from prior eras.

    Vashi’s demonstration was really good, highly informative and a pleasure to watch. The fact he cut 6k Red Raw natively was impressive, although it took a dual-socket 40 core machine.

    I just don’t think this organizational method is efficiently scalable to larger productions and higher shooting ratios, esp. docs. The fact these were previously done using primitive methods doesn’t validate this workflow in the modern era. It would actually be good to have more info on what asset management methods are being used today. This aspect is usually given little coverage in these “behind the scenes” accounts.

  • [Glenn Payne] “if I could actually edit the H264 footage as is (saving storage space on a drive). If I need to let it convert then that’s fine. I was just wondering if the technology had improved enough to allow me to do it without converting. “

    If it’s 1080p and you have a decent machine you can usually import the content with “leave files in place” and you don’t need to transcode to either proxy or optimized media. Performance is usually very good. If you don’t select “leave files in place”, the content will be copied to the library. That is not transcoding but it takes up more space — when your video files were already sitting on your hard drive. OTOH some prefer all content copied within a “managed library”. This is a media management issue not a performance issue.

    If it’s H264 4k, you can try it without proxy or optimized. Single-cam material on a good machine can be doable, but multicam usually requires proxy.

    If the H264 content is actually AVCHD, I’d recommend you rewrap that with EditReady before importing. FCPX can handle it without that, but EditReady removes the deep folder tree, combines all the original metadata, and enables the option to “leave files in place” for import.

  • [Matt Wilson] “I had heard in the past that DSLR AVCHD footage doesn’t gain much by 422 HQ (vs 422), but I’m wondering if that’s because it’s typically at a very low bitrate of ~28Mb/s. Since I have my AVCHD at a higher 130 Mb/s, I want to make sure I choose the correct one to transcode to with my goal being the best image quality.”

    See my other post. You likely don’t need to transcode at all. Just use EditReady to rewrap (not transcode) the AVCHD content before import. That preserves the full bit rate of the original content. Internally, FCPX always works on a ProRes buffer, so essentially it’s always editing ProRes. Transcoding to ProRes before or after import is mainly a performance issue, not an image quality issue. On a good machine and with 1080p content you normally don’t need to transcode to ProRes. With H264 4k, proxy or optimized media is more commonly needed.

    If you are doing heavy multicam or if your machine is *very* old or slow, then transcoding to optimized media or proxy might help editing performance — even for 1080p. You don’t need EditReady for that, since FCPX can do that either during import or afterward.

    First try to rewrap (not transcode) with EditReady, then import with “leave files in place”, and don’t create proxy or optimized media. Evaluate the performance. If it’s not sufficient, have FCPX either create proxy or optimized media during import or afterward. Proxy is 1/4 res, so not that big. Optimized is several times larger. To use proxy the viewer must be set to proxy, then set back to optimized/original before final export, else the exported files will be at proxy resolution.

    Never, ever remove AVCHD files from the bundle and import with “leave files in place”. This can cause significant performance problems. If the files are already removed from the bundle, they should be rewrapped with EditReady before import. If you have ever imported any bare AVCHD files “in place” without rewrapping, they should probably be removed from the library and reprocessed.

  • [Matt Wilson] “I have some AVCHD clips so I need to transcode to ProRes 422 to get best performance in FCPX. I got Edit Ready 2.0 software…I transcoded the files to ProRes 422, but the ProRes 422 files are actually a bit smaller than the original AVCHD files…I thought transcoding to ProRes 422 was supposed to increase the file size by about 3-4 times the original?…”

    You possibly re-wrapped the files, not transcoded them. EditReady can do either, but rewrapping is normally preferred for AVCHD. It is much faster than transcoding and does not alter the true bit rate, although it’s conceivable the reported bit rate could vary based on how you’re inspecting that. Verify what you did and that you selected the rewrap (not transcode) option. That is in EditReady, top right of window, under “Preset”. It should say Rewrap.

    On a decently-equipped editing machine you normally don’t need to transcode 1080p AVCHD or H264 content to optimized or proxy media to obtain good editing performance. After rewrapping the AVCHD files you can import those with “leave files in place”, which is very fast.

    If the AVCHD files are “bare”, e.g, they’ve been removed from the AVCHD file bundle, you do *not* want to import those with “leave files in place”, since that can cause performance problems — unless they are first rewrapped with EditReady.

    You have two main methods to handle the AVCHD content:

    (1) If it’s within the AVCHD file bundle, import from FCPX. “Leave files in place” is not allowed in this case, and the media will be automatically re-wrapped and copied to the library.
    (2) Rewrap with EditReady before Import. This works whether the AVCHD files are in the bundle or already removed. That makes the import much faster and enables the option of “leave files in place”, without any performance problems.

    For either of the above, FCPX can optionally create proxy and/or optimized media during import or afterward. In general this isn’t necessary for 1080p content on a good machine.

  • Joe Marler

    April 28, 2017 at 10:19 pm in reply to: Final Cut Pro H.264 performance

    [Tom Quayle] “…I tried to edit a Multicam project using my three Panasonic G7 cameras, shooting 24fps 100mb/s mp4 files in 4k. In both Windows 10 and Mac OS, Premiere is allowing me to edit these files natively on this system with no transcoding. I can’t scrub super smoothly through the timeline, but editing is smooth and perfectly pleasant with transitions, effects and rendering times exhibiting no issues at all. I’m not dropping any frames running all three angles at the same time plus the main viewer.

    In FCPX, on the exact same system, I can’t even play back two 4k files at the same time in Multicam mode without incredible levels of stutter and dropped frames, let alone three, unless I let FCPX transcode everything first. In both cases the files are running off the NVMe SSD.”

    This is interesting. I’ve done extensive testing with both Premiere CC 2017 and FCPX 10.3.x on my 2015 iMac 27, and have generally the opposite experience — FCPX is much quicker and more responsive on this platform.

    As Duncan said, it is most likely a GPU/driver issue. Max Yuryev built an i7-6700K Hackintosh which had excellent performance, but (like Duncan) he used the AMD R9 280X — see below. That said, if your config using Premiere can edit three-camera H264 4k without transcoding, that is very good. I can’t do that smoothly on my top-spec iMac 27 using FCPX. You can probably get an R9 280X on ebay for $100, so you could try that if you’re curious. But your performance in Premiere is so good, I’d be happy with that.

    https://youtu.be/I6ZJWPi_CBc?t=621

    Some contents or functionalities here are not available due to your cookie preferences!

    This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

Page 67 of 96

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