joema

The use of 4K by the video community is rapidly evolving. This in turn drives product design decisions by the manufacturers. The 1DX was released nearly three years ago, and the design phase was at least a year prior to that. Few people shot 4K four years ago so the 1DX is not a revealing indicator. There is no question Canon is moving slowly on various fronts, not just video. If they are going to change, a key indicator will be the 5D Mark IV. We just will not know until the specs are reliably determined. Re Canon doesn't recognize Sony/Panasonic/Samsung as direct competition, maybe that's so but Nikon definitely does. We know this because Nikon spent considerable time during the D5 release talking about how much better the D5 AF system was than mirrorless cameras for high-speed sports applications. That doesn't even make good sense -- of course a D5 has better AF in that situation. The fact Nikon even made this strained comparison indicates (at least in some quarters) they are concerned. Canon obviously saw that so it will be interesting if they ever wake up and change course.

I recommend you also consider the Panasonic AG-DVX200: http://pro-av.panasonic.net/en/dvx4k/ I looked closely at the C100 Mk II -- it is a fantastic camera, but (before the recent price reduction) it was significantly more expensive, did not have 4K, could not do a smooth power zoom, and required extra lenses. I ultimately got an A7RII plus 28-135 f/4 cinema lens and am happy with that. My documentary group got a DVX200, and it is really good. Sensor is micro-4/3 but it holds up pretty well in fairly low light. Here is a night shot we did: https://vimeo.com/user4747451/review/151164510/7771fb51fa OTOH the $1k price reduction on the C100 Mk II changes things a bit. That is very tempting. It's "only" 1080p, but good quality 1080 is very good. The interchangeable lenses give a lot of flexibility. However I've gotten used to the editing flexibility that 4K gives, and it is pretty nice.

Even if the D5 had better video features, it would be terribly expensive for hybrid shooting. Back when the DSLR revolution started, there were no affordable large-sensor camcorders. That is gradually changing. My documentary group recently got a Panasonic AG-DVX200, and it works great. Yes it's "only" m-4/3 sensor but it covers many of our needs except extreme low light and super-shallow DOF. It is way easier to use for video than a traditional DSLR. The newer video-oriented mirrorless cameras like NX1, A7 series, GH4 are sort of in-between: http://pro-av.panasonic.net/en/dvx4k/ We still use the other cameras, but for anyone shooting weddings, docs, ENG, etc, this is a good option. You could get a DVX200 *plus* a D750 and still be cheaper than the D5. The next big indicator will be what Canon does with the 5D4. I fear it will be an incremental upgrade regarding video, and if so, Panasonic and Sony are not standing still. Despite what their feedback tells Nikon/Canon, we obviously live in a more video-centric world than in 2008 when the 5D2 came out.

I have done that, also tried transcoding to ProRes before importing. With either, PP is very fast. Don't remember the CPU numbers, will re-check. FCPX is not pre-rendering, that is turned off. I'm not knocking Premiere, I use both, just trying to understand what's happening.

I have five Macs and a Windows machine. I have tested many different files from various cameras on three Macs and the Windows PC (four machines in all). It is not one file -- it is any H264 4K file from an A7RII, AG-DVX200, GH4, or DJI Phantom Vision 3 Pro. It is very unlikely limited to those camera codecs; that's simply what I've tested so far. I'll shoot a video of the screen -- it will probably be tomorrow before I can do that. I'll then post the same test file. My comment about it being CPU/GPU limited was in response to the query about sufficient I/O. I simply meant I/O is almost never an issue for single-stream H264 editing. If it were the camera itself could not perform sufficient I/O to write the file. Anyone can examine this themselves using any performance monitor tool -- Windows perfmon, Activity Monitor, iStat Menus, etc. The I/O rate for single-stream H264 4K editing is quite modest. Even an SSD Thunderbolt array won't help since that's not the weak link. The CPU behavior is obvious -- when playing H264 4K material at 2x speed, Premiere uses about 600% CPU levels on the iMac (per Activity Monitor), whereas FCPX on the same material and same 2x rate uses about 40%. That is on a 4Ghz Skylake i7-6700K, and AM counts each logical core as 100%, so 600% means most of the cores are saturated. The CPU and performance behavior are similar on my 2013 iMac whether I use OpenCL or CUDA. If anyone wants to test their machine, load an H264 4K timeline, select 1/4 resolution in the program monitor and press "L" twice to play at 2x speed, and note the CPU levels. If on a quad-core machine your levels are dramatically lower than 600%, there may be some machine or config difference. If your CPU levels are about the same, we are probably seeing similar behavior but describing it differently. My best guess is there's nothing wrong with my cameras or computers. More likely we are just describing the same behavior differently.

I just re-tested H264 4K from a A7RII, Panasonic AG-DVX200 and GH4 on PP 2015.1 on a top-spec 2015 iMac 27 with media on a Thunderbolt array. I don't see much if any difference regarding performance. I previously thought maybe the GH4 material was a little quicker, but upon retesting it feels about the same. Testing additional H265 4K NX1 material, there is no question PP CC 2015.1 is much more responsive on it than on H264 4K from the other cameras. That doesn't make sense, considering H265 is much more compute-intensive to decode. Re scrubbing with JKL, there are two factors: (1) The program monitor update rate when scrubbing, and (2) The responsiveness of JKL. On 1080P material it's all pretty fast. You can FF, hit stop, back up -- it responds quickly. Program monitor frame rate is fast, whether in FF or dragging the playhead. On H264 4K, when fast forwarding, the program monitor update rate can drop to about once per second or slower, and JKL lag to stop and reverse increases to several seconds. It almost feels like the keyboard is broken. This doesn't make it unusable, you just have to adopt different methods. On H265 4K from the NX1, it is a lot faster, though not equal to 1080P. Using FCPX, 4K is about as fast as 1080P on Premiere.

This is using an 8TB Promise Pegasus R4 Thunderbolt RAID-5 array. However the I/O system wouldn't make much difference since the data rate for H264 is pretty low. It is CPU and GPU limited, not I/O limited.

I just re-tested PP 2015.1 (9.1.0) on a 2015 top-spec iMac 27. I verified Renderer was set to Mercury Playback - GPU Acceleration (OpenCL). It was sluggish on UHD 4K H264 material from a Sony A7RII and Panasonic AG-DVX200. This is all at 1/4 playback resolution. By "sluggish" I mean frame rate during FF and REW, and responsiveness to JKL commands. It *could* play two-camera 4K multicam at 1/4 res with no dropped frames. Relative to FCPX viewer update rate on the same hardware and same playhead speed, it's about 20x slower -- about 1/2 Hz update vs 10 Hz. I then tried it on a 4K H265 clip from an NX1 -- program monitor frame rate was quite fast, despite the compute-intensive nature. It felt like editing 1080P material. That doesn't make sense, unless the hardware assist was more effective or somehow not working properly on H264 4K. I also tested the same H264 4K material on PP 2015.1 on a top-spec 2013 iMac 27 having a GTX-780m, using both CUDA and OpenCL. That is using the latest 7.5.22 CUDA drivers. It was similarly sluggish on both OpenCL and CUDA (by above definition), although it would play at normal speed at 1/4 res with no dropped frames. I've also tested the same H264 4K material on PP 2015.1 on a 4Ghz Windows PC with a GTX-660. It was sluggish there also, so it's not a Windows vs OS X thing. Part of this is definitional based on your editing style and what response characteristics define "fast" vs "slow". I am accustomed to the lighting-fast viewer update rate in FCPX, and before that PP on 1080P material. If using JKL to scrub through the timeline, PP CC 2015 feels sluggish on H264 4K on any platform I have tested, whether CUDA or OpenCL. It's not unusable but forces a different editing style of dragging the playhead and being patient. Overall the responsiveness of FCPX on unrendered H264 4K is about like PP CC 2015 on a fully-rendered 1080p timeline. It is highly suspicious that PP is more responsive on 4K H265 than H264. That's with both CUDA and OpenCL. IMO there is some inefficiency in the code path of the H264 renderer which degrades drastically on 4K.

Thanks for doing this test. This charger is the Sony BC-VW1. It also came with my A7RII. There is another Sony charger, the BC-TRW, which has a bar graph. I have two of these but have never tested the charging time vs the BC-VW1 or other 3rd party chargers: http://amzn.com/B00FSB749Q However the instructions with both Sony chargers state: "When the CHARGE lamp goes out, normal charging is completed. For a full charge, which allows you to use the battery pack longer than usual, leave the battery pack in place for approximately another one hour (Full charge)." So depending on whether you count charge time to light out or +1 hour after that affects how you rank them. It is possible the LED indicators on some chargers can be misleading. When the charge light goes out, the battery may not be fully charged. I'd like to test this but have not had time. It would probably require a timed discharge test after the charge.

Just to be clear, if you are on the latest Premiere CC and you have a subscription and you can afford a GTX-960 and your power supply can run it -- it is possible it could help with H264 and H265. This is not the GPU per se, it is not accessed via the CUDA API, rather it is special logic on that card that Premiere can utilize via NVENC -- as of two weeks ago. It would not hurt to try this.

The OP himself quoted his performance numbers during playback: "...CPU usage and GPU usage while scrubbing my CPU maxes out to 100% on all four cores but my GPU stays under 10%" The reason he observed this is because the nVidia GPU could not assist with playback. It is impossible for a traditional GPU to substantially accelerate H264 encode/decode. The algorithm cannot be productively parallelized to harness the GPU. Andrew Page (nVidia Product Manager for Professional Video Technologies), explained this in a recent interview: "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) The lead X264 developer Jason Garrett-Glaser explained how all previous attempts to meaningfully use GPU acceleration on H264 have failed: "...Incredibly difficult...countless people have failed over the years. nVidia engineers, Intel engineers...have all failed....Existing GPU encoders typically have worse compression...and despite the power of the GPU, still slower....The main problem is [H264] video encoding is an inherently linear process. The only way to make it not linear is using different algorithms [which entail] significant sacrifices." (https://www.youtube.com/watch?v=uOOOTqqI18A) Because of the GPU's inability to accelerate long-GOP codecs like H264, both nVidia and AMD have been forced to add separate fixed-function logic and APIs to access these, separate and distinct from the GPU and its APIs. nVidia's is called NVENC and AMD's is called VCE (Video Coding Engine). These are integrated on some higher-end video cards but architecturally these are a "bag hung on the side" and have nothing to do with CUDA or OpenCL. This is roughly similar to Intel's Quick Sync hardware encode/decode logic, on most Intel CPUs since Sandy Bridge. Starting with Skylake Quick Sync can handle H265. While FCPX has used Quick Sync for years, Premiere does not. The fact that a few video cards have adopted non-GPU logic and separate APIs to accelerate video encode/decode does not change the fact that a traditional GPU (meaning most in the current installed user base) cannot significantly help this task. Garrett-Glaser made very clear in his tech talk that the additional encode logic has nothing to do with the GPU. If you have a new-generation video card with separate video encode/decode logic, and if your software is specifically written to those non-GPU APIs, it may accelerate long-GOP encode/decode. But that is not the GPU doing the work, and it's not done via the CUDA or OpenCL APIs. In the case of Premiere this means the very latest version of Premiere Pro CC, 2015.1, released two weeks ago. Note this feature is not in the evaluation version of Premiere, to evaluate the H265 feature you must purchase (ie subscribe) to CC.

I meant if he ever edits H264 4K on Premiere he will need a much more powerful system, from both CPU and GPU standpoint. Scrubbing through an H264 timeline is mostly a CPU issue, as he's already observed. This is because decoding long-GOP codecs like H264 cannot be meaningfully accelerated by the GPU. It is typically not I/O bound because it's a camera codec designed to keep the data rate low. Anybody who doubts this can observe for themselves during editing using Performance Monitor (Windows) or Activity Monitor (Mac) -- the I/O rate when editing H264 is not very high. Because of his limited system, he has been forced to transcode to ProRes LT, which is a good workaround provided he does not mind the extra space. This greatly decreases the CPU load but increases I/O. So in this case it can become I/O limited. The design goal of Premiere is to allow most editing using the native codec without transcoding. However this requires a relatively powerful CPU. For H264 4K it requires an extremely powerful CPU, the fastest you can obtain. He has a NX1 so it's reasonable he'll be using 4K in some format. Transcoding to ProRes solves the CPU problem but it takes about 8x the space of H264. My documentary team shot a 1 hr two-camera interview using H264 4K and it took about 90GB. After transcoding to ProRes 422 this was about 720GB. His system cannot remotely edit 4K H264 effectively. His question was whether a better GPU would help -- the answer is not sufficiently. The GPU itself cannot meaningfully accelerate encode/decode of H264, just effects. So his options are get a much more powerful system or transcode to ProRes and be prepared for the huge space and I/O increase. If he can afford the time and space cost of transcoding everything he shoots, and only has problems with effects, then it's possible a better GPU might help that.

This is good advice. While his Radeon R7 240 video card is pretty slow, and a GTX-960 might seem a worthwhile upgrade, if he is CPU-limited even an infinitely fast video card will not help. Playback of H264 is a decoding issue, not a rendering issue. Decoding of long-GOP codecs cannot be generally GPU-accelerated. He is working only with 1080p timelines but has an NX1 so what codec he uses is a big factor. If he transcodes to some variation of ProRes that should help a lot. If he will ever be doing 4K, he needs to think about a much more powerful system. Likewise for H265 he needs hardware playback support from the newest high-end nVidia cards. Note NVENC hardware acceleration is not coming from the GPU but separate logic integrated on the same card. I assume he is using Premiere. If Adobe ever supports Intel Quick Sync that would make a big improvement.

I agree. I have tested Premiere CC 2015 on Windows 10 and Mac OS X 10.11.2, and timeline responsiveness is slow on both with H264 4K. Running on identical hardware (a top-spec 2015 iMac 27) FCP X is much faster than PP CC at various things. This difference is much less noticeable at 1080p. In my experience PP CC timeline performance falls off a cliff at 4K. By contrast FCP X slows down some but it is still usable and generally responsive. That is with CC on 1/4 resolution and FCPX viewer on "performance". By "various things" I mean the most common timeline editing operations that convey an impression of responsiveness. IOW how rapidly it responds to JKL input. How much lag to keyboard input when changing directions from fast forward to reverse. How many frames per sec the Program Monitor updates when fast forwarding through the timeline in both forward and reverse. PP is almost a slide show relative to FCPX, especially on multicam 4K. OTOH I have talked to other experienced filmmakers who claim they have no problems with PP CC performance on H264 4k -- on similar iMac hardware. Part of this may be editing style. If you never use JKL to rapidly survey material but just drag the playhead and wait a second, you can get work done. PP seems to eventually cache a buffer around the current playhead location so that smaller trim or jog movements within that buffer are pretty quick. But larger timeline movements exhaust that buffer and become very slow and laggy. Also if you never compare FCPX and CC back-to-back on the same hardware with the same material, you get accustomed to the editor's responsiveness and that becomes "the new normal". You can adapt to almost anything. However CPU utilization is much higher in CC than FCPX when moving at the same speed through the timeline on the same hardware. This indicates the CC playback code path is far less efficient. Encode/decode of Long-GOP codecs is inherently CPU bound unless algorithm-specific specific hardware acceleration is used. A general purpose GPU cannot do this, maybe FCPX is using Quick Sync. OTOH others observe FCPX is still very fast on Mac Pros which use Xeon that does not have Quick Sync. That implies a code path optimization. With FCPX I never used proxy files on HD but I often use those on 4K and always on multicam 4K. It is built-in, seamless and easy. With CC there is no built-in proxy feature and ironically it needs it much more than FCPX due to the slower performance on H264 4K. PP CC really needs a lot more optimization on the playback engine. This is ironic since traditionally "Mercury Playback" has been so fast, but it is not handling 4K well.

You are absolutely correct. I have done a lot of recent performance testing on PP CC 2015 vs FCP X on the same hardware. PP does fine on H264 1080p material but bogs down drastically on 4k. On a top-spec 2015 iMac, PP has several seconds of viewer lag when fast forwarding through the timeline. When doing rapid JKL editing, the keyboard lag to go from fast forward to rewind is several seconds. On FCP X direction change is instantaneous and the viewer update rate is over 10x as fast. If doing multicam 4k it's even worse. IMO PP is borderline unusable on multicam H264 4k -- even at 1/4 resolution. Maybe a custom-built workstation with an overclocked liquid-cooled CPU and a Titan GPU would do better, but it would seem extreme to require that. The fact that PP has no built-in proxy mode like FCP X makes it even worse because of the workflow overhead of manual proxies. It's not OS X as I also tested PP CC 2015 on Windows. I noticed when fast forwarding on the timeline that Premiere's CPU utilization is much higher than FCP X. Maybe FCP X is using Quick Sync to offload the CPU burden of encode/decode. I'm not slamming PP in general -- it is a great suite, very capable and feature rich. But 4k is rapidly proliferating on the production side, regardless of what happens on the consumption side. Years ago Mercury Playback was a revolution, mostly doing away with transcoding and mezzanine codecs. Adobe hitched their wagon exclusively to native codecs with no built-in proxy support, and now that wagon is breaking down under the 4k load.

The lead developer of x264 reviewed the efforts to GPU-accelerated H264 encoding, saying: "...countless people have failed over the years. nVidia engineers, Intel engineers...have all failed" His technical seminar reviews the problems and challenges: https://www.youtube.com/watch?v=uOOOTqqI18A The X264 team only used GPU acceleration on one component of X264 called Lookahead, which comprises only about 10-25% of the total H264 runtime. This was the only part which could be feasibly accelerated, and the benefits were limited (though useful in some cases). It was not a huge improvement on the scale typically associated with hardware acceleration, such as the 4x or 5x improvement in encode/decode performance from Quick Sync. The inability of GPUs to accelerate long-GOP encode/decode is why nVidia and AMD have added extra non-GPU circuitry to their recent high-end video cards. This extra functionality is bundled with the GPU but architecturally has little relationship. The situation with H265 and x265 is similar. It is a long-GOP codec but much more compute-intensive than H264. There is even greater need for hardware acceleration but for the same reasons as H264 a regular GPU cannot provide this. It takes specialized algorithm-specific hardware which means Quick Sync, or the nVidia/AMD hardware accessed by their NVENC and VCE APIs.

At first I thought (as Pavel said), that only H265 decode hardware (not encode) is on new high-end video cards from AMD and nVidia. E.g, the AMD Fury. However this thread indicates nVidia at least has both encode and decode support for H265, but the only software I've seen is the experimental command-line tool mentioned here: http://forum.videohelp.com/threads/370223-NVEncC-by-rigaya-NVIDIA-GPU-encoding Note this "GPU" acceleration of H265 is not really the GPU but a logically separate ASIC that is integrated into the same assembly. A traditional GPU cannot effectively accelerate either encode or decode of long-GOP formats like H264, MPEG-4 or H265. See discussion here: http://www.eoshd.com/comments/topic/18574-a-story-about-4k-xavc-s-premiere-and-transcoding/?do=findComment&comment=123689 Use of these features is not automatic -- the software must use specific APIs which are unique to either the AMD or nVidia video card. AMD's is called VCE and nVidia's is called NVENC. Skylake CPUs have enhanced Quick Sync which does support both encode and decode of H265. However I don't think any software takes advantage of this yet. FCP X uses Quick Sync for both encode and decode of H264, and it makes a huge performance difference. It also avoids the requirement to have a specific video card. I hope they add similar Quick Sync support for H265 soon. Some versions of Handbrake on some platforms can use Quick Sync for H264 but not yet H265.

That may be true in general, but note -- all these magazine covers are frame grabs from a video camera: http://www.red.com/shot-on-red/photography

Don thanks for all your research and testing on this. It was beneficial to my documentary group as we investigate more effective workflows in the 4k era. Re Quick Sync and filters, I just did a test on my 2015 iMac, where I have both FCP X 10.2.2 and Premiere CC 2015.0.2 installed. I exported a 5 min H264 4k clip from my Sony A7RII. On both FCP X and Premiere I applied color correction and sharpening. I did not render the timeline in either one which forced this to happen during export. Below are my numbers (note this is on the same physical machine): Premiere CC 4k H264 export, 1-pass VBR: 12 min 40 sec FCP X 4k H264 export, 1-pass: 3 min 45 sec Premiere CC 1080p H264 export, 1-pass VBR: 7 min 38 sec FCP X 1080p H264 export, 1-pass: 2 min 15 sec. This is almost certainly due to Quick Sync although I don't have a Xeon machine for comparative testing. Others have tested similar scenarios on Xeon-powered Mac Pros running FCP X and they are a lot slower at exporting to H264 than i7-powered machines. Quick Sync may seem like a "one trick pony" because (before Skylake) it only did MPEG-2 and MPEG-4/H264, and only worked in single-pass mode. However I cannot see any visible difference in my tests between single and multi-pass modes. My group's workflow like many others involves final H264 products for web upload. So while a "one trick pony", it is a very effective one.

I believe liork is correct -- significant GPU acceleration of long-GOP encode/decode/transcode (e.g, H264) is almost impossible. The terminology is confusing since we often refer loosely to exporting the file as "rendering", or we say "render it out". However technically you render an *effect*, but but encode or export to a video stream or file. If the timeline is not rendered, then exporting may require rendering as one phase but they are distinct actions. Parallelizing transcoding for 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) There are dozens of academic papers where the smartest researchers have tried to apply GPU acceleration to H264 encoding. In general they have not been successful. Jason Garrett-Glaser, (lead developer of X264) described this: "...Incredibly difficult...countless people have failed over the years. nVidia engineers, Intel engineers...have all failed....Existing GPU encoders typically have worse compression...and despite the power of the GPU, still slower....The main problem is [H264] video encoding is an inherently linear process. The only way to make it not linear is using different algorithms [which entail] significant sacrifices." By contrast Quick Sync does not target rendering but encode/decode. Those are two different things. Quick Sync can accelerate encoding by 4x or 5x -- it is a huge improvement. The downside is software must use that. To my knowledge FCP X and Handbrake do; Premiere does not. This will become much more critical as H265 is rolled out since it is far more compute-intensive than H264. Intel CPUs starting with Skylake have enhanced Quick Sync that supports H265. Because of the inability of GPUs to handle this, both nVidia and AMD have recently added separate, fixed-function hardware encoders to their GPUs. Architecturally it's a bag hung on the side. nVidia's is called NVENC and AMD's is called VCE. They are both essentially a separate ASIC run by a proprietary microcontroller, but integrated into the GPU die or on the card. The downside is they both require separate and proprietary APIs to access, as opposed to Intel's Quick Sync that is on nearly every Intel CPU since Sandy Bridge (except unfortunately Xeon). The Puget Systems tests were showing GPU accelerated *effects*, not encode/decode/transcode. Any purported benefit to export was during timeline rendering, not encoding.

His numbers are roughly correct. The 5D3 might go a little longer than 1.5 hr, but not much. My documentary group uses the 5D3 and A7RII. If you keep the 5D3 "spun up" in video mode you have to replace the battery several times per day. For the A7RII we use the battery grip, which is almost required (from a handling standpoint) when using longer lenses. Configured this way and used similarly for video, there is little operational difference between the two in battery life. Even though you may be changing two batteries in the A7RII, you have to stop and service both cameras at about the same frequency. The A7RII batteries are smaller and lighter so they don't take up any more space or weight than the spare batteries for the 5D3. Also we use a Zacuto EVF Pro on the 5D3, which has its own Canon battery. The A7RII does not require this. The Zacuto battery lasts longer than the 5D3 battery but still must be changed at about 1/2 that frequency, so that's another battery required to produce equivalent functionality to the A7RII.

It's not specific to Premiere. I edit lots of 4k from the GH4 and A7RII on FCP X on a top-spec 2013 iMac. A single H.264 4k stream is mostly OK but for multi-cam, transcoding to proxies is mandatory. Fortunately FCP X has a totally integrated seamless proxy workflow. Re the OP question about what Mac to "smoothly editing 4k", this is a challenge on nearly any computer, esp. if multicam. But even for a single stream, remember that almost everything you do -- every effect -- is manipulating 4x the data. Applying effects that were momentary and quick on HD become slow on 4k, sometimes agonizingly slow. Some of these effects can be done on the GPU but it's up to the software and how amenable the core algorithm is to GPU-style parallelization. The bottom line is you want the fastest iMac you can possibly afford, and even that won't be comfortably fast for certain 4k operations. This currently means the late 2015 5k iMac 27 with 4Ghz Skylake CPU, M395X GPU and 16GB or more RAM. I'm getting one of these next week. I personally prefer a SSD boot drive but I have several Mac with both SSD and Fusion Drive. FD is OK but with 4k you will almost certainly have your media on a fast external drive, probably a Thunderbolt array. Since most of your data is external, a 512GB or maybe even 256GB SSD might be sufficient. At least the new Skylake CPU has an improved Quick Sync on-chip transcoder which supports H.265 and VP9. In the future that will be important, esp for 4k. For reasons I don't understand Premiere still doesn't support Quick Sync, which can make a 4x difference in export and encode/decode operations. It is supported by FCP X and Handbrake. OTOH most Xeons do not have Quick Sync so no Mac Pro has that, regardless of software.

Yes we are shooting mixed 1080p/4k doc material now with the A7RII, GH4, D810 and 5D3. Unfortunately I don't have releases to post any samples. Before getting the A7RII and 28-135 f/4 cinema lens, I looked very closely at the C100MkII. That is a great camera and I love the built-in features (ND, XLR, etc). The C100 deploys very fast, which is important for field doc work. By contrast it takes 10 minutes to rig a DSLR with EVF, brackets, HDMI, cable protectors, etc. It's fragile in that state and every time we change sites we must decide to de-rig it, have someone hand hold it or risk balancing it on a car seat. However the C100 is essentially video-only and I wanted combined stills/video, plus we do lots of time lapse and that wears out a DSLR, whereas the A7RII has a non-mechanical silent shutter mode. We'd have used regular Canon L lenses on the C100, which means no smooth motorized zoom. We have all kinds of focus aids (sticks, knobs, Zacuto rigs, etc) but they can be a a hassle for field work. We won't distribute in 4k anytime soon, but shooting in 4k for 1080p distribution has advantages. - Allows looser framing and fine-tuning composition in post - In many cases 4k frame grabs (which are 8 megapixels) are usable as stills, which saves switching between still & video mode or using two cameras. We shot a project two weeks ago which the customer said was video-only, then afterward they wanted stills. We fortunately shot in 4k so the frame grabs were good enough for this purpose. I always use the battery grip on the A7RII, which (a) Makes it a lot easier to hold with a big lens on the camera, and (b) essentially eliminates battery life issues. There is functionally no difference between shooting video with that vs the 5D3. In both cases you have to change batteries at least once or twice per day depending on shooting duty cycle. Last weekend I shot mixed 4k video & stills all day in direct sunlight at 95F ambient temps, and the A7RII did fine. OTOH it will definitely overheat and shut down if shooting non-stop, long-duration 4k, but that is not a common usage for us. We would never shoot a classroom lecture at 4k, and a 30 min. interview is very rare (for us); not sure we'd shoot that in 4k either. For me the biggest negative on the A7RII is the fiddly, consumerish user interface. I am frequently changing it in/out of Super 35 mode, and it is maddening this requires diving into the menus every time. Formatting a memory card takes a long time, and invoking that also requires diving into the menus. The GH4 is a great camera with much better UI and lots of aftermarket support. But we shoot mostly full frame so haven't fleshed out the GH4 config. In Super 35 mode the A7RII is very good at low light video (better even than the 5D3). We do lots of existing light shooting so that's important. The Sony 28-135 lens is a good match for A7RII video work. The smooth motorized zoom and ability to pop between manual and auto-focus by sliding the focus ring forward/backward are very handy. The lens and camera are expensive but still cheaper than a C100MkII body, plus you get 4k and 42 megapixel stills. That said if it were not for that lens I'd have probably gotten the C100. We are still evaluating various post-processing and color profile options for matching 4k from the A7RII with the other cameras.

The most notable difference I've seen is in low light conditions. 1080 on the A7RII is significantly worse in low light than my 5D Mark III, whereas 4k/Super35 on the A7RII is significantly better. There are several different 1080 codecs and bitrates on the A7RII. I should re-test this in both normal and low light using each one, but I won't have time for at least a week. So far I haven't had any problems with the A7RII shutting down from overtemp when shooting 4k documentary material in real world conditions. However that is mainly because the ratio of shooting to non-shooting time is typically high, e.g, 1:3, 1:5, 1:8, etc. If you set it on a tripod and let it record a 2 hr lecture in 4k (restarting every 29:59), it will definitely overheat in ambient conditions above roughly 65F.

There are various ways to view this. Historically all feature films until about 2002 were limited by 1000 ft. film magazines, which translated to 11 minutes maximum shot length. From that standpoint a 30-40 min. 4k continuous recording limit doesn't seem bad. I've shot hundreds of interviews for various documentary projects, and don't recollect one over 30 min per take, and usually not over 30 min total. Normally you wouldn't even use 4k on an interview, or a public speaker -- it's just not needed and burdens post production with more data. That said, 4k gives new capabilities and allows us to approach tasks differently. E.g, I shot an interview last week with the A7RII and intentionally used 4k to frame it looser, giving the editor final control over composition. You could hypothetically shoot a two-person interview in 4k, simulating two separate cameras. In very dark conditions (e.g, some concerts or plays) you might have to use 4k/Super35 whether you need the resolution or not -- simply because that's the most sensitive high ISO mode. 4k has such good resolution it encourages longer-duration wide covering shots which can be cropped/zoomed in post. Also Super35 gives a 1.5x effective zoom, so even if you don't need 4k this might be used for the extra reach. Even if you never plan on distributing 4k material, shooting in 4k has such compelling features that you start using it in new situations. This in turn makes the 4k thermal recording limit on the A7RII more troublesome than it may first appear.