Forum Replies Created

Page 82 of 96
  • Joe Marler

    April 2, 2016 at 6:21 pm in reply to: More FCPX

    That looks amazing. What 5D3 codec did you use — IPB, All-I, Magic Lantern raw or external ProRes recorder? Did you use any shooting aids like Zacuto EVF or shoulder rig? Was it only the 70-200 at f/2.8 or did you also use a tele-converter? What color correction/grading software did you use?

  • Joe Marler

    March 28, 2016 at 3:09 pm in reply to: Can we perhaps hold the triumphalism …?

    [Steve Connor] “Would that involve a contract with a carrier to get your timecode $20 a month for 1000 timecode minutes or $50 for unlimited :)”

    Cell phone networks use various sources (not just GPS) of extremely accurate time. It’s called mobile backhaul synchronization. I don’t know how much of that is available via cellular metadata, however there are various internet-based sources of highly accurate time. Any location with WiFi could query those and preset the camera TC or periodically update a drift correction algorithm. Even my Seiko quartz wristwatch receives radio-based time correction signals. Those would not be reliable for a camera but it shows in principle how straightforward the concept is.

    There are mobile apps which query atomic time standards. We commonly use Bluetooth and WiFi links from mobile devices to cameras. Many cameras have built-in GPS and some (like Sony) even run apps. Camera vendors commonly have apps for mobile devices which add functionality to the camera.

    So there are multiple pathways using well-established affordable technology for a camera to either periodically or continuously update its TC. This need not cause a jerk or disruption in the TC; smooth continuous correction based on periodic updates is possible, for the same reason that camera clocks drift slowly. So it would not necessarily require a lot of data, even if delivered via a cellular network.

    It has just not been a design or feature priority for camera manufacturers. On the low end there is audio sync and using PluralEyes this is very capable. Just above that is Tentacle Sync, which is not very expensive. Above that are more expensive wireless TC systems. So there are already solutions which work across mixed camera brands.

    For GPS or WiFi TC pre-set/correction to work in a mixed environment, it might require some type of standardization, however rudimentary. E.g, one camera brand might support GPS-driven presets to a user-entered TC at a specific wall clock time, but another brand might only support continuous correction. It is likely manufacturers would favor their own products in terms of standardization but not collaboratively devise a universal standard for such a niche feature area.

    It is frustrating that cheap still cameras commonly have GPS geotagging which in principle can access nanosecond-precision time data, yet video camera manufacturers don’t use that to enhance TC.

  • Joe Marler

    March 25, 2016 at 2:40 pm in reply to: Can we perhaps hold the triumphalism …?

    [Jeremy Garchow] “when all else fails, you can send an audio tc signal to a camera and turn that in to jam sync tc on audio…I didn’t ask for this to happen, it just started to happen due to limitations and fragmentation in camera technologies.”

    This raises a good point. Some commonly-used field audio recorders don’t have SMPTE timecode, such as the Zoom H4 and even the Tascam DR-680MKII. They may display a pseudo timecode but this isn’t SMPTE metadata. In those cases (as you said) you must dedicate one channel to LTC audio timecode from some generator and then in post convert that to SMPTE TC. Resolve can do that, Premiere and FCPX cannot, however you’d normally use an external utility.

    With all the limitations and fragmentation, and with the availability of PluralEyes, it is often easier for lower-end productions to simply use waveform sync. PluralEyes can sync almost anything, even hundreds of clips in one batch. The 4.0 version automatically handles sync drift, so recorders drifting apart on long takes is no problem.

    I think there is an untapped potential to use GPS to augment existing TC, even if only simultaneous jam-syncing multiple cameras to a user-entered preset. That doesn’t require any change to TC format, and uses hardware already existing on many cameras.

    Re the auxiliary TC features which FCP7 had and FCPX does not, it is unfortunate those making feature films with FCPX have not discussed this in more detail. In Mike Matzdorff’s book he simply said make sure all cameras are jam synced: https://amzn.com/B00UO2NA8I.

    While he and director Glenn Ficarra were not shy about mentioning FCPX limitations such as multicam, I don’t recollect them ever discussing lack of aux. TC being an issue. If it wasn’t an issue on feature films, what was their solution?

  • Joe Marler

    March 24, 2016 at 3:14 pm in reply to: Wish List For Next Update

    Remove the many limitations on multicam:

    – Cannot apply stabilization (whether built in or 3rd party)
    – Cannot apply optical flow smoothing
    – Cannot use *any* Mocha tracking feature such as SliceX object removal, shape mask, etc.
    – Cannot use Auditions

    This is a harsh, discordant experience for a product which emphasizes simplicity and ease of use.

    By contrast with Premiere CC you just apply stabilization, tracking or optical flow directly to the MC clip. This is a major advantage for Premiere.

  • Joe Marler

    March 23, 2016 at 4:45 pm in reply to: Can we perhaps hold the triumphalism …?

    [Tim Wilson] “If in fact GPS is practical, and it’s simply not always….
    I don’t understand why we’re even talking about this. LOL It’s extra expense and complication, and will require a LOT more development to be practical on location…

    Many cameras have GPS built in already for geotagging. Consider my Sony A7RII — it has GPS, it has various TC functions including rec run, free run, initialize TC to user-entered preset, etc. However it does not have jam sync input. If it and all similar cameras simply accepted GPS to jam sync TC to a user-entered preset value at a given time of day, that would automatically sync them all. It’s a simple firmware update for already existing hardware. It’s not adding some GPS data in place of SMPTE timecode.

    Many cameras will record OK for several hours in free run without needing to re-sync. Here is a video of Dave Dugdale “jam syncing” (actually zeroing) TC on multiple A7 cameras, which then allows sync by TC during edit:

    https://www.youtube.com/watch?v=t3Fuoxbv81E

    Dave’s procedure is Sony-specific, so you can’t do this on diverse cameras. However there is no reason new cameras which already have GPS and already have menus for user-entered TC could not simply use GPS to simultaneously initialize TC to a user-entered time of day. It’s no different from everyone trying to hit the TC preset button at the same time, except GPS would do this with nanosecond precision. This would avoid in many cases having an external TC and jam syncing by cable, even if the cameras supported that.

    Of course there are nice external TC options such as the new relatively inexpensive Tentacle. But increasingly cameras already have the hardware to jam sync TC to a preset value via GPS, they just haven’t written the firmware. Ironically the less expensive hybrid cameras more frequently have GPS than higher-end pro video cameras, likely because the designers just didn’t think about this workflow. You can add a GPS module to many of those but you may as well then add a Tentacle or other sync box.

    https://tentaclesync.com/

    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

    March 23, 2016 at 2:52 pm in reply to: 4k editing workflow

    [Elizabeth Perlman] “I would probably have to edit in a 1080 timeline, but now sure how to output to 4k at the end of my edit. Just relink to my optimized media + export 4k?”

    FCPX makes this incredibly easy. You don’t need to edit in a 1080p timeline although you could. You basically have two options:

    (1) Import 4k, and transcode to proxy and edit in a 4k project. You can transcode during import or afterward. To use the proxy files, simply set View>Proxy in the viewer (upper-right corner drop-down menu). This automatically uses the proxy files. You edit as normal. When finished and ready to output at 4k resolution, set View>Optimized/Original in the viewer, otherwise it will output proxy resolution files. There is nothing to keep track of and nothing to relink. In general this will provide sufficient performance to edit camera native H264 4k on a MacBook Pro or even lower end machine.

    (2) Import 4k and edit in a 1080p project. If the project is created with “Set based on first video clip”, this would make it 4k, which you don’t want. In File>New>Project, simply select “Custom” and pick 1080p, then add/edit content to the timeline. This by itself will help performance somewhat without transcoding. Whether it is sufficient or you also need proxy, you’ll have to investigate. Despite being a 1080p project, and despite FCPX automatically scaling the 4k content to 1080p, you can still zoom/crop without losing the underlying 4k resolution.

    In the #2 case, if you export at 1080p, you are done — a zoom/crop will use the underlying 4k resolution even though the final output resolution is 1080p. If you want to export at 4k, you just copy/paste the timeline into a 4k project and it becomes 4k. All the edits are retained.

    The #2 case provides faster performance than using a 4k project because the internal render files are generated at 1080p, not 4k. However it is not as fast as using proxy, so if you want the best performance use proxy.

    On my 2015 iMac 27, if I’m editing a short single-camera 4K H264 piece, I just import with “leave files in place”, do not transcode and FCPX is fast enough. If I am editing multicam 4k, then I generally use proxy. If there is huge amounts of content edited down to a small piece (very high shooting ratio), it doesn’t make sense to transcode all that to proxy before editing. FCPX is fast enough on a new machine to skim through camera-native H264 4k, mark favorites and keywords, then you can transcode to proxy the initial selects.

    Although I’ve focused on proxy, you can obviously also use Optimized media. It will also give better performance than camera native 4k H264, but proxy is faster. However optimized media is typically 8x the size of H.264 hence I/O bandwidth and storage requirements will be much higher.

  • Joe Marler

    March 22, 2016 at 8:39 pm in reply to: Can we perhaps hold the triumphalism …?

    [Oliver Peters] “As I sit here transcoding a bunch of Sony A7 footage because the performance is bad enough that I don’t want to deal with bringing the computer to its knees 🙂 Granted that’s not TC (the A7 has TC), but just one of the many issues caused by consumer-ish gear (or at least consumer codecs) used in professional environments.

    If you are talking about transcoding H.264 to keep from bringing Premiere CC to its knees, I have observed that myself. In my tests on 4K H264 from an A7RII and AG-DVX200, the frame rate when fast forwarding in the timeline is about 20 times slower than FCPX. On my top-spec 2015 iMac 27 with 4Ghz i7 and 32GB RAM and Thunderbolt RAID, I generally have to transcode such content to get fast editing performance on Premiere, especially for multicam. On FCPX that is less necessary, although I sometimes use proxy when editing three-camera 4k.

    Also I don’t see the issue about consumer codecs in professional environments. Our AG-DVX200 records UHD 4k using H.264 at up to 150 mbps, yet this still requires transcoding (in Premiere) for best performance, and even FCPX benefits if doing multicam. Even the $16k Canon C300 Mark II uses H.264, with the same issues. Do you mean cameras with internal ProRes or similar codecs?

  • Joe Marler

    March 21, 2016 at 4:51 pm in reply to: Do more projects within an event slow FCPX down?

    [Mike Warmels] “Thanks for the trouble shooting page. But if I have to take this seriously, I really don’t get the ‘Pro’ part of FCPX. Because basically it says: shut down everything but FCPX, and don’t use all the features. And yes, that’s why you bought a $6000 computer from us, with 6 cores we hardly use. Personally, I think that is insane.”

    That page is not saying don’t use all the FCPX features — these are simply temporary troubleshooting procedures. I have had to do things like this with Premiere, FCPX, high-end “Pro” server software costing $20k, etc.

    I greatly empathize with your difficulties. It is extremely frustrating to try and get production work done when the software/hardware platform is unstable. I think most of us have been there. When anyone says they’ve never had a problem or a crash with product xyz, I am suspicious.

    FCPX can obviously work in used in high-end professional environments: https://www.fcp.co/final-cut-pro/articles/1781-how-swiss-tv-went-fcpx-final-cut-pro-x-in-national-network-operations

    That doesn’t solve your problem but it shows there is no generic limitation. Rather the software/hardware is very complex. While generally reliable and stable, within the multi-dimensional configuration and usage space, there are zones of instability. All software is like that — you unwittingly encroach on those and things go downhill. Unfortunately these zones are not well defined and fluctuate based on many factors.

    The best approach is generally to (1) Upgrade to the latest version, then if not resolved (2) Work step-by-step to define and narrow the replication scenario. E.g, remove plugins and re-test, discard and rebuild all generated library files, if the scenario can be narrowed to a smaller data set, move it to another storage device, etc.

    The reason for trying the latest version is not high confidence that will fix the problem, but it’s an easy step to take. Major time/effort can be wasted troubleshooting a problem on an old version only to find the problem is fixed in later versions.

    For problems which have a gradual onset with no clear demarcation, that is more difficult. However with further inspection and testing, what first appears to be a totally amorphous problem will often come into sharper focus with more distinct characteristics. This can allow an easier workaround and certainly expedites getting a fix from the manufacturer.

    There is a good case for “I shouldn’t have to do this — it should just work”. Unfortunately all complex software can manifest problems like this, even if only 5% of users experience it. Thus the good or bad experience of a single user is often not revealing. The ideal situation is to have professional enterprise-level support, where they have visibility to thousands of sites and symptom tracking databases. However this is expensive and there’s no guarantee even in that case you wouldn’t have to do troubleshooting.

  • Joe Marler

    March 20, 2016 at 3:53 pm in reply to: Do more projects within an event slow FCPX down?

    [Oliver Peters] “For clarification and to help Mike, these are new, original sequences created in one event, not duplicates or copies of each other. Correct?

    I created 10 projects, and five duplicates of each project for a total of 50 projects. All 50 projects, 5,000+ clips and 2.2 terabytes are in the event of one library. Performance remains good.

    However I have definitely seen random, unexplainable slowdowns happen, just not recently and not on ver. 10.2.3.

    In the past I’ve tracked several issues to plugins. I wish FCPX had a global “disable all plugins” setting for diagnosing problems like this. Likewise there is no uniform method to ensure all plugins are updated, or to even inspect the version of a plugin. This leads to old plugins which in turn leads to problems.

    There is some good troubleshooting advice on this page: https://fcpx.tv/Pages/top10troublesthoot2.html

  • Joe Marler

    March 19, 2016 at 5:21 pm in reply to: Do more projects within an event slow FCPX down?

    [Mike Warmels] “Now, I tried doing this: moving the older projects to a new event. And with each move (which often takes a bit of time: beach balls, the project loading even though I am not using it, just moving it) FCPX speeds up again.

    Is there some limit to the number of projects recommended within one event?”

    I am working on a doc project and have 2.2 terabytes of camera-native material in a single FCPX event, comprised of 5,667 clips — 117 hours of mixed 1080p and 4k material. This was with “leave files in place” and no transcoding. I am still developing what keywording and organizational system to use.

    I created 10 different projects (not snapshots) in this one event and inserted material into each one. It mostly seems to run OK with no performance problems. The 5000+ clips in the Event Browser are periodically a little sluggish to redraw when scrolling, but it’s not bad.

    This is on FCPX 10.2.3, OS X 10.11.3, 2015 top-spec iMac 27, with the material on an 8TB Thunderbolt Promise RAID-5 array.

    I can’t explain the performance problems you are seeing. On earlier versions of FCPX I have seen periodic unexplained slowdowns which went away when I restarted FCPX which could imply a memory leak. Other times I have tracked problems to specific plugins. It seems relatively stable on the latest version, at least on my hardware and workflow.

    Larry Jordan says don’t go over about 3,000 clips per library, but I am well above that with no problems. I have heard of other users with 7,000 clips per library on a Mac Pro without problems.

    Re events, now that FCPX supports library-wide searching and smart collections, this allows putting material in different events but still being able to search it in one step. However I don’t know what (if any) performance implications are for many events vs fewer events.

    Since you can’t search across libraries it would seem problematic to split closely-related material between different libraries.

    I believe the FCPX search scope behavior is:

    – If event is selected, search will be within that event
    – If library is selected, search will be across all events in the library
    – Keyword collections are within a single event
    – Library-wide smart collections can be created at the library root level
    – To create a library-wide keyword collection, create a Library Smart Collection using one or more keywords as the search criteria

Page 82 of 96

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