[Joe Marler]

[Bret Williams] “But the guys at Ripple were hyping up the newest release of compressor, saying that send to compressor is now optimized in the same way as exporting directly from X with a compressor setting is or the same as exporting in compressor is. And that previously using send to compressor was slower than a direct compressor setting export from x. But Tangier’s tests don’t seem to confirm this.
“

The Ripple guys are correct — before the latest version, Compressor was slower than FCP X if exporting single-pass H.264 material. On my limited tests it was about 50%-100% slower. This probably wasn’t purely lack of Quick Sync, since that usually makes a 4x or 5x difference.

Re-testing on Compressor 4.2 and FCP X 10.2.1 shows Compressor is much faster. Whether single-pass H.264 (which uses Quick Sync) vs multi-pass H.264 (which does not), Compressor is now modestly faster than FCP X, whereas before it was slower on both.

Whatever they did Compressor is now a lot faster. It must be using Quick Sync because otherwise it would be impossible to beat FCP X on single-pass H.264. There may be other GPU refinements or optimizations besides this.

If someone did back-to-back testing on a Mac Pro with prior versions of Compressor and FCP X, they might find it’s relatively improved. However it will never be as fast as an iMac on single-pass H.264 because of the lack of Quick Sync.

This doesn’t mean an 8-core or above nMP isn’t a good machine — it’s better than an iMac for most heavy duty tasks.
These are very brief tests on a 2013 iMac 27, 32GB, 8TB Pegasus R4, GTX-780m.

On my iMac it takes about 53 sec for FCP X to export a 07:30 720p video to single-pass H.264; Compressor 4.2 takes about 47 sec.

So I am not convinced Tangier’s slow export is due to lack of Quick Sync. It shouldn’t take 20 minutes. I suggest he try exporting with these parameters as a test from FCP X:

– Master File
– Format: Computer
– Video codec: H.264 Faster Encode
– Resolution: 1280 x 780

If that is a lot faster then create a Compressor pre-set with similar settings and export to that.

[Joe Marler]

The GPU can greatly accelerate certain *effects*. E.g, applying color correction to every pixel of a frame is parallelizable, so the many parallel elements in a GPU can help.

Parallelizing transcoding when using an interframe codec like H.264 is extremely difficult. In a recent interview with editor Scott Simmons and Andrew Page (nVidia Product Manager for Professional Video Technologies), they explained:

“there are a lot of tasks that can’t be broken down to be parallel: encoding is one, decoding some of the camera compressed formats is another one…what happens in frame 2 depends on frame 1, we do something to frame 1 then feed the results into frame 2….that’s pretty much an encoding problem…everything is interrelated, so we can’t break it up into lots of different simultaneous things.” (That Studio Show podcast, 5/20/14: https://itunes.apple.com/us/podcast/that-studio-show/id293692362?mt=2)

Maybe eventually some clever developer will figure out how to more effectively harness the GPU for encoding but as of today it hasn’t happened to a great degree.

This is why Intel’s Quick Sync feature works so well: it is essentially an on-chip ASIC (Application Specific Integrated Circuit) designed for transcoding. It only works for a narrow range of codecs (MPEG-2, H.264 single-pass) but for those it is really fast. The upcoming Intel Skylake CPU will have an improved Quick Sync that supports more codecs. Unfortunately Xeon CPUs (which means Mac Pro) do not have Quick Sync. This was probably because Quick Sync — while not implemented totally in the GPU — requires some on-chip GPU resources, so Intel would have to put the entire GPU on Xeon to get that function. That would have cost millions of transistors, when the design priority for Xeon was server and workstation performance, and those use discrete GPUs or don’t need one.

Much academic research is still being done in this area and there are many papers about possible future ways to accelerate video encoding/decoding with a GPU. So maybe someday a future FCP X update will more fully harness the Mac Pro GPUs for video encoding. However as of today it’s not generally done, at least for interframe codecs like H.264.

[Joe Marler]

[Noam Osband] “Why do so many industry types use 720 rather than 1080? I’m sure they could get 1080 if they wanted. What’s the appeal of 720?”

Back when the entire TV broadcast industry transitioned from analog NTSC to digital ATSC, the technology didn’t exist for a cost-effective dual resolution capture, distribution and switching infrastructure. As it was, the expense was incredible for each local network affiliate to upgrade all their equipment, and in fact some local affiliates only upgraded around 2012.

This was further exacerbated by the then-limited state of codecs, cameras, and other infrastructure to handle 1080i at the full 1920 x 1080 resolution. For years much so-called 1080i sources were actually shot and broadcast at 1440 x 1080, because the full 1080i data rate wasn’t supportable.

Another factor was the predominate characteristic of the material each network owned. In the case of ABC, Fox and the sports networks, they had a lot of sports content which tended to favor the higher frame rate of 720p/60. They also knew that much of the competing 1080i material would not be true 1920 x 1080 for years, so this lessened the static resolution advantage of 1080.

Around the mid-to-late 1990s when the big decision was required, they had to go one way or another, so each network decided and invested as they thought best.

I don’t know the situation today and haven’t checked the broadcast parameters for the 720p stations. But years ago when ABC was definitely 720p, certain shows like “Lost” had beautiful, detailed cinematography. Much of it was shot on location in brightly lit conditions. By contrast a reality TV series shot at full 1080 with mostly interior sets and practical lighting will not look as good, despite the higher static resolution.

Under controlled conditions I can tell the difference between 1080i and 720p if I am prepared ahead of time and looking for it. However I seriously doubt most viewers — unprompted — would notice it. Ultimately we are making material for the final customer, not for critical analysis of fellow technicians.

Most of our material is shot at 1080p/30 (29.97) with some 720p/60 (59.94). In those cases we generally use a 1080 project and upscale the 720p (using FCP X).

I have read that Compressor can use a better quality upscaling algorithm, but this would require importing your 720p material into Compressor, setting 1920 x 1080, resizing using the Statistical Prediction option, exporting as ProRes 422 and importing the resized ProRes 60p clips in FCPX. I have not tested that personally.

[Joe Marler]

[Noam Osband] ” If I make the timeline 1080, then it means I get the full quality of my 1080 shots but the 720 shots are slightly worse quality since they’re now expanded BUT if I do a 720 timeline, the 720 wont lose any quality but I don’t get the full quality of the 1080.”

I’m not sure it will make that much difference. Many networks shoot and broadcast exclusively in 720p. This includes ABC, Fox, ESPN Networks (ESPN, ESPN2, ESPNews), A&E Networks (A&E, History, History International, Crime & Investigation, Biography), Fox Sports Net, Fox News, Fox Business, FX, CBS College Sports, MLB Network, Disney Channels (Disney, DXD, Disney Kids, ABC Family), Speed Channel, Fuel, & Big Ten Network.

Everything you view from those sources is upscaled 720p. I doubt most people notice the difference between that and 1080p on adjacent channels. In theory 720p/60 has higher temporal resolution, whereas 1080p/30 has higher spatial resolution but in practice other factors swamp this such as exposure, lens, post processing, playback equipment, viewing distance, etc.

[Joe Marler]

As you may know, blown out audio is very difficult to fix because the waveform is clipped. That is essentially lost information. Just reducing the level in post doesn’t fix the clipped waveform. Izotope RX4 can de-clip those cases by analyzing the waveform and attempting to reconstruct the lost information.

I used it last week on a similar situation and it worked fairly well. It wasn’t perfect but the audio was significantly improved. The downside is it’s expensive. However you don’t need the (even more) costly Advanced version for de-clipping as the regular version has that feature.

Obviously the real solution is get the levels right in the field but sometimes this doesn’t happen, you can’t reshoot and the only option is fix it or discard the material.

[Joe Marler]

[Morten Slemdal] “I will screen my 20 minutes video (old footage 720×576) on a tv. Should I play it directly from my mac (prores 422) or burn it to a dvd? “

While you can’t change the standard-def nature of the older material, I suggest evaluating whether (given the years of progress) you could polish it in post to look better.

This needn’t take lots of time. At least looking at each clip to ensure the levels (via video scope), white balance, audio, sharpening and stabilization are OK.

Was the source 576i? Either way you want that handled properly when rendering the final output, so avoid ugly combing artifacts.

Also make sure the final output as played on the final display device is optimized to the degree possible re aspect ratio. If it’s 4:3 material then pillar boxing on a 16:9 display is unavoidable. If it’s 16:9 anamorphic, then make sure the final file on the final playback device displays as intended. You don’t want a letterboxed, squeezed or cropped image. Allow plenty of time to examine and fix this, as these things always seem to rear their ugly head when you’re under a tight schedule.

In general I’d recommend just playing from a digital device like a MacBook as it avoids the complication of burning a DVD and worrying about how various playback devices might handle that. E.g, there are old and new DVD players, hardware and software players, some do interlacing some don’t, some do motion compensation and some don’t, etc. However even with HDMI playback from a MacBook, you must verify the audio path is workable and the playback chain handles it OK.

In similar situations, as a contingency I usually take a wired/wireless portable speaker like a Jawbone Big Jambox in case the house sound system has problems.

[Joe Marler]

[shawn convey] “I would assume that if your LAN port is supplying the rest of the edit suites it can’t be transferring any quicker than the gigabit LAN port coming out of my Synology… is that thinking correct or am I missing something?”

You are correct. In general link aggregation (if available) increases ethernet backbone capacity, not point-to-point transfer performance. You can see some typical NAS performance numbers here: https://www.smallnetbuilder.com/tools/charts/nas/view and compare to posted numbers on directly attached storage using BlackMagic, QuickBench or other disk benchmarks.

You can also Google BlackMagic and whatever NAS you’re interested in and compare to variously directly-attached storage systems using that same benchmark.

Even though 100 MB/sec is no faster than a bus-powered USB portable drive, it is enough for editing H.264 HD video, even a few concurrent streams. It’s not because the NAS is so fast, but because the I/O demands are fairly modest. The data rate on H.264 HD video is limited by the compression and resolution.

OTOH if you ever intend to edit 4k or multiple streams of less-compressed video such as ProRes 422, you can encounter the I/O limit sooner. E.g, a single ProRes 422 stream at 1080p/30 is about 147 megabytes/sec. The BlackMagic benchmark helps by indicating whether your read/write performance is sufficient for various popular codecs and resolutions.

NAS definitely has advantages if sharing content between multiple editors.

[Joe Marler]

[chris walker] “…most people mixing 1080p and 4k on a 1080p timeline are using 1080p and 4K footage from exactly these types of cameras, and I haven’t come across any complaints on the various forums about the 4k looking worse rather than better than the 1080p because of this enlarged noise/grain issue, even when cropping the 4k footage, so I assumed the noise/grain increase with the 4k was quite small….are there some other settings I can use to decrease apparent grain in 4K? There are always denoisers like Neat Video, but I’m hoping not to have to resort to using those..”

I’m not sure casual reports from other users are a good indicator. Most of them did not do focused testing like you did at different ISOs. As you found, in a well-lit environment using lower ISOs there’s less difference between 4k and 1080 noise (on a camera doing pixel binning at 1080). At higher ISOs the difference is more apparent.

This is similar noise behavior to a still camera if comparing native resolution and down-sized photos at low and high ISO. At low ISO there’s not much noise so there’s less difference between native and down-sized stills. At high ISO there’s more noise so the down-sizing helps those stills but the native res stills don’t benefit from that.

3200 ISO is pretty high for a m4/3 sensor. Even on my 5D3 I don’t like going beyond 6400 shooting 1080p.

My advice:

(1) Make sure you aren’t using some in-camera setting which aggravates noise. Some flat exposure curves can worsen noise. I can’t count the number of times I’ve seen 5D3 shooters say “All I did was use Cinestyle and ALL-I codec, now there’s noise everywhere”.

(2) In general if you “expose to the right” this may help.

(3) If your situation mandates low light, consider high-speed lenses such as the Voigtlander 25mm f/0.95 ($1k). If this seems expensive consider the f/0.7 Zeiss lens Stanley Kubrick used to shoot candle-lit scenes in Barry Lyndon cost $12 million (adjusted USD). https://www.bhphotovideo.com/c/product/1044065-REG/voigtlander_ba259m2_nokton_25mm_f_0_95_type.html

(4) By all means consider noise processing such as Neat Video. IMO every clip of the final product should be meticulously post-processed, whether for color, exposure, stability, etc. Noise processing is just one more step of many. Here’s a review of some: https://nofilmschool.com/2014/10/neat-video-vs-denoiser-ii-which-plug-better-noise-reduction

[Joe Marler]

[shawn convey] “many have said that the 1813+ has super impressive speeds with gigabit LAN ports (4 of them) but still I really don’t know what that means in terms of what I need.”

As Noah said, directly attached storage is normally a lot faster. Actual real-world file transfer speed of gigabit ethernet is often slower than people expect. A typical figure might be 100 megabytes/sec (on a good day), which is about as fast as a cheap bus-powered USB 3 portable drive.

If your situation absolutely mandates NAS for other reasons such as collaborative file sharing, then the performance penalty may be worth it. However even a less expensive directly attached RAID system will be a lot faster. E.g, OWC Thunderbay 4, or even G-RAID.

[Joe Marler]

The LX100 is primarily a still camera. The still resolution is way too high for HD video. When shooting 1080p, they may use “pixel binning” to combine groups of adjacent pixels and down-rez to 1080. This might reduce noise as a side effect.

Also as Noah said, any codec difference between 4k and 1080 could play a factor. On the 5D Mark III people sometimes report more noise when using the ALL-I codec vs the IPB codec, even when both are used at 1080p/30.