[Joe Marler]

[Lucy Slavinsky] “By “final product” do you mean distribution? I am not sure if I understand it fully. The film is intended for broadcast, festivals. Further distribution strategy is probably streaming or downloading. How would you handle the interlacing issue?”

There are two frequent issues with handling large amounts of older SD material for 16:9 progressive distribution: (1) 4:3 aspect ratio and (2) Interlacing.

You often will have a mix of original camera-native material and other content which has been processed, rendered or cut up by unknown tools. Depending on the processing sequence this can “bake in” certain interlacing, window boxing or pillar boxing effects. In reviewing the content it’s a good idea to try and assess if this has happened and where possible backtrack to the original camera-native content, even if this entails re-capturing data off tape.

DVD distribution further complicates this since the playback methods could be a software player, hardware player, etc — each of which can have different handling of de-interlacing and wide screen content. You basically have to check it on a bunch of different playback devices. If you won’t be using DVD, at least that part is simplified.

There is no single procedure for handling this. You just need to be aware and watch for interlace “combing” artifacts on horizontal moving subjects on both original content and your final rendered content, also undesirable window boxing, then make adjustments to handle these if present. You will frequently see videos where this was not handled properly and interlace artifacts or window boxing got baked in and the playback system can’t undo that.

In general FCPX will do the right thing when conforming content with mixed aspect ratios or interlacing as you add it to the project. However it’s best to do a periodic test export and evaluate how it looks — before adding a hundred clips that all must be then fixed. The “fixing” could be as simple as changing the field dominance or deinterlace checkbox settings under Inspector>Info for that clip. Unfortunately it can be a matter of trial and error. If not discovered early you could have already added a transition between two clips with different characteristics that then must be removed to fix the problem.

Another good way to minimize some image quality issues of older 4:3 NTSC content is using split screen. There are various split screen plugins for FCPX. Here is a MacBreak Studio on one of them:
https://www.youtube.com/watch?v=dAaspNUSSkU

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]

No matter what the project properties are, the final export will have full access to the native media resolution. E.g, you can drop a 4k clip into a 720p timeline, zoom way in, and the full resolution will be present.

In fact there are advantages to editing on a lower-res timeline since the intermediate render files are smaller, hence faster to generate. With FCPX this does not lock you in to that lower resolution for final output. There is also the built-in proxy mode which accomplishes something similar, but you can use both proxy and a lower-res timeline yet still have full res for final export. E.g, I often edit 4k in a 1080p project, plus use proxy mode, yet can zoom way in and FCPX will automatically harness the original 4k resolution for final output. You just have to get used to not visually seeing that detail during the edit phase.

[Joe Marler]

[Bill Davis] “And it’s TOTALLY escaping me how much some people seem to be questioning the utility of this. Do they, for some reason, need to hate the new Laptops THAT much? “

I think objective assessment of the touchbar has been damaged by the removal of the SD slot, the USB-C-only decision and related dongle issues. Professional users who need those removed features lump them all together as excessive emphasis on aesthetic elements by out-of-touch Apple designers.

In fact the touch bar seems like a good idea, and it still does function keys. You lose the tactile response but in return you gain a lot more flexibility and functionality. In future versions they could add haptic feedback to the touch bar that might help.

Going from buttons to a touch interface always has tradeoffs. But even aerospace — which historically valued the tactile feedback of physical switches — is going to touch panels. Here are photos of an actual production (not mockup) F-35 fighter plane touch-screen panel: https://joema.smugmug.com/Aerospace/F35-Touch-Screen-Instrument/n-85xJrM/

Likewise the SpaceX Dragon capsule will use mostly touch screen panels: https://blogs-images.forbes.com/alexknapp/files/2014/05/DragonV2-10.png

[Joe Marler]

[Lucy Slavinsky] “there are all the formats that were available at that time and from all the different sources. You have mentioned EditReady. I have Compressor. Besides the significant diference in the conversion time are there any other advantages for using EditReady? Should I consider Priemier over Final Cut? Am I looking for ProRes 422 as the editing format? “

EditReady uses Apple’s own ProRes codec, but it is much faster than Compressor. As a documentary editor I normally do not externally transcode before ingesting to FCPX, since FCPX usually does OK by itself. However for importing huge batches of widely varying older content, I find it’s often better to externally transcode, esp. the older stuff which may have already been processed by some clipping tool. Here is a recent review of EditReady by Larry Jordan:
https://larryjordan.com/articles/product-review-editready-from-divergent-media/

Re Premiere vs FCPX, both are OK and I have edited documentaries in both. However FCPX has a major advantage for projects with high shooting ratios like documentaries. This is especially so for older material captured off tape which usually produces several very long files. FCPX can tag ranges within clips and present those as searchable items.

The skimmer and Event Browser in FCPX enables hyper-fast review and tagging of content. That enables a different workflow than is traditionally used. With most editors the ability to rapidly evaluate and tag content is limited, so you tend to do this outside the editor. IOW use VLC or some playback utility to review and separate the desired clips, then import only those, then re-review and re-classify them within the editor. For a large documentary this is redundant and slow, plus there is no easy way to mark short regions of interest within longer clips.

By contrast with FCPX it is often better to just import *everything* and do the initial review and classification within the editor. The unwanted stuff can later be excluded when you copy the used material to another library. Taking time up front to keyword tag and mark favorite and rejected ranges (not just clips) — before putting anything on a timeline — will greatly expedite things.

Re what ProRes format to use, most of your content is apparently standard-def older stuff. I’m not sure how much visible advantage there would be from using ProRes 422 HQ vs LT but you could transcode a couple of clips and see if there is any difference.

Another key issue is interlaced material and how you handle that. This is further complicated if the final product is a DVD vs a video file. You will often see material that has “baked in” interlacing artifacts because of improper handling.

[Joe Marler]

The material is probably in various formats — some already captured off tape, AVI files, etc. Some of it may have been pre-edited with an external clipping utility to cut up long files captured from tape. Although she said mostly SD, if it includes through 2015 there could even be consumer AVCHD content. You never know the pedigree and handling of that.

This is especially problematic when those clipping utilities extract ranges from long-GOP formats like AVCHD. They can often mangle the head and tail of the file which in turn can crash or destabilize editing software.

Even if FCPX is capable of editing the (allegedly) native files, it might be good to externally convert it to ProRes/MOV using EditReady or a similar tool, then verify the result is OK before importing it to FCPX.

Before doing some big bulk import or transcode, I’d suggest taking an inventory of each media type and testing the transcode/import method on a sample of each type. Then if that works, proceed to larger batches of data.

Pointing the editor import dialog at some huge folder tree of unknown (but old) media and codec types will often cause unpredictable behavior.

[Joe Marler]

[Oliver Peters] “Funny. An SD slot wasn’t cumbersome in the last version of the MBP. The truth is that Apple sees photography as only the iPhone, therefore no need for an SD slot. It’s also nice to know that the 3.5mm headphone jack defines professionals. “

Exactly right. This is nothing like eliminating the optical drive years ago. In that case it was obvious optical media would be declining, the drive mechanism itself took up a huge amount of internal space.

With high-megapixel cameras like the Sony A7RII, Canon 5DS and Nikon D810, SD is by far the best way to transfer thousands of raw stills. My doc team uses only the fastest available high-capacity SD cards — not because the camera needs them but because they transfer faster to the laptop. The newest, fastest cards have a 150 megabyte/sec read rate. There is no wireless camera transfer protocol that can remotely match that.

There is a valid argument this is a pro scenario and most people don’t need that. But a $4300 15″ MacBook PRO is not something most casual users would purchase.

Re Schiller’s statement about camera wireless transfer being “very useful” vs the SD slot being “cumbersome” — for who? An SD slot is definitely not cumbersome for the pro users it would benefit. He apparently means Apple’s designers view it as *aesthetically* cumbersome. That is a topsy-turvy view of things. These products should be practically designed for the end user — not for the personal gratification of a multi-millionaire designer who envisions his product on a little satin pillow illuminated by a spotlight.

What’s “cumbersome” is current camera wireless transfer techniques. By contrast an SD card slot in an expensive Pro laptop is “useful”.

[Joe Marler]

[Grant Peacock] “On the choking and machine slowdowns – with further digging, I realized that all the project materials, being sent over to me (from Keynote), were in aprox 2K. I had allowed the timeline to conform to that originally…I’ve gone back and moved each project into a 1080p timeline, and also opened a new library for each individual edit. The machine is no longer choking, but it’s unclear to me which of my simplifying actions would have had a significant impact….Another strange issue – on these new 1080p timelines, I’m getting…Random audio drop outs in voice track, either with waveform representations still painted in, or not (both scenarios are happening). I’m also getting functioning audio playback at points on the timeline where the waveform depiction has vanished…I am starting to wonder if my 2011 MBP is just getting too old!”

I don’t know the answer. My library is now up to 8,085 clips (181 hr of 1080p and 4K material), comprising 4.75 TB total size — most in a single event. On my top-spec iMac 27 and using several Thunderbolt arrays, performance is mostly OK. This is on 10.2.3; I’d like to upgrade to 10.3 and test it but can’t afford the risk.

The easiest step would be transcoding your content to proxy (not optimized) then flipping the Viewer mode to proxy. This can be done after import and it usually makes performance must faster. Just remember to change it back to optimized/original before the final export.

I looked up your 2011 MBP in the MacTracker app. If you have the top-spec 15″ version it is not that slow. Of course new machines are faster — GeekBench 4 numbers for the 2.4Ghz 2011 MBP are 3015 single-core and 8800 multi-core. This compares to my 2015 MBP which is 4367 single-core and 14469 multi-core. There might be a bigger difference in the GPUs.

[Joe Marler]

[Noam Osband] ” I was able to save MTS files. I wanna use these clips in a FCP X movie? Recs on how to do that? Should I convert to Pro Res first?”

In general FCPX can import and edit the files in native format without transcoding. However AVCHD-format files are re-wrapped automatically during import, hence the “leave files in place” option is greyed out. If the same .MTS files are removed from the AVCHD file bundle, they can be imported with “leave files in place”.

I have seen some excessive I/O problems on very large libraries (about 3.5 terabytes, 7,000 clips) apparently caused by a small group of .MTS files which were imported with “leave files in place”. The majority of content in this library was H.264 1080p and 4k, with only a few hundred .MTS files. This problem manifested as very sluggish, halting thumbnail generation in the Event Browser in filmstrip mode when scrolling down. In some cases it would halt for 30-60 sec.

During this phase, the command-line Dtrace utilities bitesize.d and iopending indicated a huge number of small I/Os were being done against the .MTS files and associated Info.plist files. The mean I/O size was about 12KB, but the I/O histogram showed many were 4KB. When the .MTS files were deleted from the library and externally re-wrapped using the 3rd-party EditReady utility, then reimported with “leave files in place”, the I/O problem went away.

I don’t recollect seeing this on properly-packaged AVCHD files but the above problem only became obvious in a huge library. It might exist in smaller libraries but go unnoticed. OTOH, it might only happen with bare .MTS files, not those properly contained in the AVCHD bundle.

I don’t know if importing them and transcoding to proxy or optimized media would have avoided this. In general proxy is roughly the size of the original H264 content (1/4 total res but 1/4 the compression). Optimized media is about 8x the size so that would normally increase the I/O load. Even on this huge library, skimming the content was pretty fast. Hardware: 2015 top-spec iMac 27, 16TB OWC Thunderbay 4 in RAID-5.

It is conceivable the MTS files were somehow being dynamically re-wrapped each time the Event Browser needed to show their thumbnails, and maybe that caused excessive I/O.

Of course the best practice is don’t copy the MTS files out of the AVCHD bundle, but this is commonly done.

In general I would recommend externally re-wrapping AVCHD media using ClipWrap: https://www.divergentmedia.com/clipwrap, EditReady: https://www.divergentmedia.com/editready, or the free utility ReWrapAVCHD: https://www.macupdate.com/app/mac/39800/rewrapavchd

I have never used ReWrapAVCHD but it supposedly works. I have used ClipWrap and EditReady many times and they work great.

Note the Dtrace utilities cannot be used starting with El Capitan unless System Integrity Protection is first disabled: https://apple.stackexchange.com/questions/208762/now-that-el-capitan-is-rootless-is-there-any-way-to-get-dtrace-working

[Joe Marler]

[Oliver Peters] “[Joe Marler] “Deadpool would be the last feature film that could be edited on a nMP. ”

Why do you say that? Do you mean because of the timeframe or something else?”

I should have said last feature film of that type which required those compute resources. My point was post production is constantly expanding and pushing the limit. If the nMP hardware was somehow fundamentally flawed regarding thermal management in high-end workloads, this would imply that Deadpool’s workload is the end of the line — they reached the limit and nMPs will just burn out like overloaded fuses at that load factor — no matter how many GPUs are replaced.

In fact it is unlikely that the nMP thermal design or Premiere’s use of the hardware is flawed. It was more likely just a bad batch of GPU cards. If it was something deeper, the nMPs would keep burning out under that workload or any future post-production workload of similar type.

The nMP is widely used in many industries. Surely (after three years) if unsafe thermal margins existed at high workloads OR if some software “no man’s land” existed where an app could burn it up, we would know that.

[Joe Marler]

Note that recall was for a specific defective batch of AMD GPU cards, manufactured from February 8, 2015 to April 11, 2015. The repair process consists of replacing these cards, not redesigning the nMP cooling system.

If it were an inherent thermal design problem OR a problem with Premiere or any other software, the nMPs which failed in a specific heavy workload would keep burning up after the GPUs were replaced, repetitively and without end. Deadpool would be the last feature film that could be edited on a nMP.

Just because the reported failures happened on Premiere or Resolve does not mean it’s a software problem. Different software exercises different load paths. In general it is the hardware’s responsibility to handle this, no matter what the software does. This is especially so with workstation-class hardware.