Fast 4K Editing on OSX and Windows 10

[Sekhar]

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.

OK, there is definitely something specific to your system going on, no issues on my machine (specs in my earlier post). @Don Kotlos, I've tried NX1's H.265 and GH4's H.264. @joema, could you post the file that's giving you trouble and perhaps capture the scrubbing behavior in a video if possible? We can then compare to figure out what's going on. You said it's CPU and GPU limited, how did you confirm that? Did you check the performance windows and did you try a tool like GPU-Z?

[Don Kotlos]

OK, there is definitely something specific to your system going on, no issues on my machine (specs in my earlier post). @Don Kotlos, I've tried NX1's H.265 and GH4's H.264. @joema, could you post the file that's giving you trouble and perhaps capture the scrubbing behavior in a video if possible? We can then compare to figure out what's going on. You said it's CPU and GPU limited, how did you confirm that? Did you check the performance windows and did you try a tool like GPU-Z?

 

Unless I am messing up some setting, or the Xeon is more problematic than the i7, there is no bottleneck that I can think of in my system. 

 

[jcs]

Using Samsung SSDs- not IO limited. 12 2.93GHz cores, 24GB RAM, GTX 980ti 6GB- not compute limited.

The fact that OpenCL runs fully real-time (as one would expect with this hardware), on NVidia gfx (would expect CUDA to be faster), points to some kind of issue with Premiere/NVidia drivers.

With earlier versions of Premiere, OpenCL ran much slower than CUDA on this hardware.

[joema]

OK, there is definitely something specific to your system going on, no issues on my machine (specs in my earlier post). @Don Kotlos, I've tried NX1's H.265 and GH4's H.264. @joema, could you post the file that's giving you trouble and perhaps capture the scrubbing behavior in a video if possible? We can then compare to figure out what's going on. You said it's CPU and GPU limited, how did you confirm that? Did you check the performance windows and did you try a tool like GPU-Z?

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. 

[Sekhar]

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.

I wonder if FCP is pre-rendering, so CPU is free during scrubbing/playback. Why don't you pre-render on Premiere Pro also and compare? If you aren't familiar with it, you can pre-render with Sequence->Render In to Out, and the yellow bar at the top will turn green. If you get similar CPU numbers after that, that's probably what's happening.

[Don Kotlos]

I wonder if FCP is pre-rendering, so CPU is free during scrubbing/playback. Why don't you pre-render on Premiere Pro also and compare? If you aren't familiar with it, you can pre-render with Sequence->Render In to Out, and the yellow bar at the top will turn green. If you get similar CPU numbers after that, that's probably what's happening.

No it is not. As you can see from my test scrubbing performance is not related to any effects or the playback resolution.

It just inefficient decoding of 4K H264. 

In order to decode a single frame with an interframe codec, multiple frames needed.  While the buffer can keep up duting playback, anytime you place the playhead on a random location it has to read a bunch of frames at once and you get the delay. 

 

[Sekhar]

No it is not. As you can see from my test scrubbing performance is not related to any effects or the playback resolution.

It just inefficient decoding of 4K H264. 

In order to decode a single frame with an interframe codec, multiple frames needed.  While the buffer can keep up duting playback, anytime you place the playhead on a random location it has to read a bunch of frames at once and you get the delay. 

I'm not sure you got my point (and I was responding more to what @joema was experiencing): if you pre-render, there is no decoding of H.264, no inter-frame issues, no slow-down by effects, etc. All those issues are irrelevant. If your bar is yellow (or red, obviously), that COULD be what's going on. Just a thought, I'm not familiar with FCP.

[jcs]

C300 II 4K files are ALL-I, no P or B frame interpolation. Thus it's not an H.264 decode issue. The issue reported was purely PP CC's 4K pipeline. Switching from CUDA to OpenCL shouldn't make any noticeable difference in performance (I wouldn't be surprised if NVidia runs OpenCL commands through a translation layer and executes CUDA internally).

FCPX is still snappier/faster (uses more CPU too (not just related to GPU)), however at least PP CC is usable now for 4K material on OSX El Capitan, GTX 980ti, etc.

[Don Kotlos]

I'm not sure you got my point (and I was responding more to what @joema was experiencing): if you pre-render, there is no decoding of H.264, no inter-frame issues, no slow-down by effects, etc. All those issues are irrelevant. If your bar is yellow (or red, obviously), that COULD be what's going on. Just a thought, I'm not familiar with FCP.

Sekhar, yes pre-rendering can remove any lag in the system but as soon as you make ANY change in the effects you will have to render again, so it makes it near-useless for online editing. 

Now it could be that FCP renders again each clip every time you make a change, but that is something that I don't know. So if your question was on that yes, I misunderstood. 

@jcs Premiere does not give me an opencl choice so I cannot test it. Also it is not a general 4K pipeline problem since many codecs work just fine (see my tests for a comparison), others are just not optimized. 

[jcs]

@jcs Premiere does not give me an opencl choice so I cannot test it. Also it is not a general 4K pipeline problem since many codecs work just fine (see my tests for a comparison), others are just not optimized. 

The 4K C300 II files played OK at 1/2 resolution or in a 1080p sequence. If it was a codec issue, this would not be possible. Another user on the Adobe forum verified the issue, and suggested transcoding ( https://forums.adobe.com/thread/2043865?q=C300 II ). While this worked on their machine, it did not work on mine: even ProRes was slow in a 4K sequence unless played at 1/2 resolution. 4K in a 1080p sequence worked OK too. Neither case worked as well as switching to OpenCL and playing the native C300 II files. Looks like a bug somewhere.

[Don Kotlos]

Probably we are talking about different problems. Yours seems to be GPU dependent and as you say a bug. 

[joema]

I wonder if FCP is pre-rendering, so CPU is free during scrubbing/playback. Why don't you pre-render on Premiere Pro also and compare? If you aren't familiar with it, you can pre-render with Sequence->Render In to Out, and the yellow bar at the top will turn green. If you get similar CPU numbers after that, that's probably what's happening.

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.

[tellure]

It seems like we have enough data points of people with high-spec PCs and high-spec Macs all finding Premiere Pro's 4K h264 performance poor (without rendering the timeline - agree that solves these issues).

Sigh.  Doubting this is something that will be fixed soon if ever.  Maybe Adobe can hire some of those FCP programmers and rewrite their engine.

[Xavier Plagaro Mussard]

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.

IMHO, that makes sense. Adobe programmed the h264 part a long time ago. The h265 more recently. Computer-intensive is everything video related. Responsiveness depends more on well programmed software/fast storage, than on CPU/GPU brute force potential. 

[hmcindie]

Changing Premiere Pro CC 2015's Renderer to Mercury - OpenCL (from CUDA)

Where do you find that setting?

[Gregormannschaft]

Having the same sorts of issues others have had here with Premiere Pro, think there is a bug somewhere along the latest updates. Right now editing 4K footage in a 1080 timeline works best, if I want to export 4K I'll change it at the very end.