Hi All , I’m still running my video on a slaved PT rig , but now I’m almost a year I on Cubase was working how video would effect CPU load ,
Is ProRes 422 best for cpu in C13
Yes & as for all such load across-the-board.
A little non-intuitive because the file sizes are much larger, but something like a smaller MP4 interpolates & doesn’t play every frame, hence, much greater load on the CPU. ProRes and other pro codecs play every frame & so less load.
Having said this, YMMV depending on CPU power, RAM, overall project load etc. Fire up a MP4 and see how it goes.
2 Likes
I’m gonna run some tests and feedback here , just go to know what current cubase users are using 
Thx
I always prefer ProRes 422 Proxy or ProRes 422 LT at best, as they are smaller in size and look good enough as a reference for my audio production even on a big screen. I see no reason to work with ProRes 422 and even less with ProRes 422 HQ.
You can go even smaller with DNxHD-36Mb, and get very smooth playback experience no less than ProRes, but DNxHD costs a bit to be used in Cubase/Nuendo, and it feels more or less the same in terms of system resources consumption and playback smoothness.
Either way here is where you get it if you’re interested.
1 Like
ProRes is hardware decoded on M1/2/3 Pro, Max & Ultra SoCs. So is H.264 and HEVC. You probably won’t gain a lot when it comes to CPU usage. Cubase will decode video with Hardware, now. The ProRes files will be much larger, though.
Isn’t DNxHD a CODEC that Apple distributes with their Pro CODEC package. Is this still required on a Mac even when the system has a usable CODEC available to use?
I think the main reason to go with DNxHD is if the editor is on Windows using software that doesn’t export ProRes (like Resolve). Does Cubase on Windows even support ProRes at all? I’ve never bothered to check. I’ve always used DNxHD or H.264 there. I bought the Cubase CODEC for that reason.
I haven’t tested this on macOS without the CODEC installed, though, so I’m kind of curious about that.
With Hardware Decode, I would just use H.264 and have much smaller file sizes to deal with.
Hi @Trensharo , DNxHD and DNxHR introduced by Avid not Apple. Apple made the ProRes codec and that is why for many years ProRes encoding was not possible on Windows machines, but in recent years many professional editing software can create it even on Windows.
ProRes is also playback fantastically well and smooth in all Steinberg’s software on Windows machines.
In general, both DNxHD and ProRes are using the same main compression concept, which is Intra-Frame compression, unlike AVC (h264) and HEVC (h265) which are using GOP compression in order to achieve a smaller size media file but are playback at best only when used as a final production master while both DNxHD and ProRes were made to for professional editing and broadcast purpose. DNxHD and ProRes are bigger in size but require much less processing power as they are simple to decode while h264 and h265 are much more complex and most of their frames are incomplete (only their I-Frames are full frame data while their B-Frames and P-Frames needs to be calculated based on their last I-Frame). Therefor, ProRes and DNxHD will always playback better in editing software.
About the hardware decoding on Apple M.x, for that to happen the video player must be capable of taking advantage of that feature, and I’m not sure Steinberg’s video engine is using it, but I can’t say for sure, only Steinberg can answer that.
In short, I would always prefer ProRes over h26x in DAW and NLEs editing software even though it is a larger file size, it plays back better and that’s what important for me when I work.
OK thanks , I am on a M2 so are you saying its Hardware decoded , so video should effect cpu load at all now?
So Just tested H 264 (606mb) - ProRes 422 Proxy (3.39GB) and ProRes 422 (13GB) On my M2 Max and there is no difference in the Mac’s Acivity Monitor , maybe H 264 stay a little lower !
I am mostly get sent H 264 so the could be good news . I am not sure if there is a way to monitor the load in a more accurate way than using Activity Monitor or cube bases built in performance monitor
You’re not understanding what I’m saying.
https://support.apple.com/kb/DL2100?locale=en_US
Apple has a Pro CODEC Package that macOS users can install to add support for Pro Video CODECs.
These include:
• Apple ProRes RAW and ProRes RAW HQ*
• Apple Intermediate Codec
• Avid DNxHD® / Avid DNxHR® decoder
• AVC-Intra 50 / 100 / 200 / 4:4:4 / LT
• AVC-LongG
• XAVC
• XF-AVC
• XF-HEVC
• DVCPRO HD
• HDV
• XDCAM EX / HD / HD422
• MPEG IMX
• Uncompressed 4:2:2
Software that uses the macOS APIs can get this without requiring uses to buy a separate license for decoding those CODECs. It’s a free download from Apple, and installed automatically if you install any of their Pro Apps on a Mac.
As you can see, Avid DNxHD and DNxHR are listed there (third down from the top).
I wasn’t inferring that Apple developed those CODECs 
As I’ve stated above, the only reason to use ProRes or DNxHR over H.264/HEVC was the lack of GPU Decode in the software - as heavily compressed CODECs have a high CPU requirement for decoding them. Now that both are GPU Decoded on M# Pro/Max/Ultra machines, there is no point going with ProRes or DNxHD because the files are exponentially larger and you won’t gain any benefit from using them - unless you’re using a machine with an ancient [i]GPU that cannot decode that CODEC.
The ProRes/DNxHD only made sense when the CPU Compute Cost for decoding the file was lower, and made dealing with the larger file sizes worth it. This situation existed largely due to the lack of GPU Decode support in DAWs. CPUs/GPUs have been hardware decoding H.264 for well over a decade, at this point.
Even if ProRes wasn’t GPU Decoded, the H.264 would still probably be better because Cubase now Decodes that CODEC with hardware. So, you’d probably end up with higher CPU usage decoding the ProRes file.
The only thing that matters is whether or not the software decodes H.26# in hardware. If no, then ProRes/DNxHD is worth it because the CPU cost for decoding is much lower - making the larger file sizes worth dealing with. If yes, then don’t bother. Just use H.264, as you will not gain enough to make the larger files worth dealing with.
1 Like
It will never be “free,” regardless of CODEC, but Hardware Decoding H.264 is going to cost way less CPU than CPU-Decoding ProRes.
With both being GPU Accelerated, the H.264 is generally better because the file sizes are considerably smaller… unless you’re using something like ProRes Proxy.
And that makes no sense when you can get H.264/HEVC that is more viewable at higher resolutions with comparable file sizes.
I have tested on my m2max. And agree with this …
“”Even if ProRes wasn’t GPU Decoded, the H.264 would still probably be better because Cubase now Decodes that CODEC with hardware. So, you’d probably end up with higher CPU usage decoding the ProRes file.””
I don’t know if what you say is a deduction theory based on things you read or something you tested thoroughly in real-life scenarios.
For me, In practice, ProRes and DNxHD still yield much smoother playback, and when I do back-and-forth scrubbing, which I do a lot as a post-production audio designer, I see much smoother video snippets during fast scrubbing on ProRes/DNxHD than with H264.
About their resource consumption, here’s a quick test to show the differences I see on my M2 studio machine:
ProRes Scrubbing in the Project window:
H264 Scrubbing in the Project window:
As you can clearly see, theories aside, ProRes is much more efficient in system resource usage than H264, even today with the latest hardware from Apple.
This doesn’t mean one can’t use H264 to save disk space and get reasonable to beautiful results.
However, heavy post-production users like me will always prefer performance and smoother workflow over disk space usage, which I have in abundance (about 4 TB of space only for projects).
Hay Sagi , whats that app showing usage ?
Thx
Not come across this , I have alway been told a Mac doesn’t need and kind of clean up utility . but the monitoring looks good .]
How does the CPU load compare in play back (not scrubbing) ? I have run lots of test using the build in CPU monitor and H264 and ProRes looked the same.
Andy
During playback the differences are very small, about 1 or 2 percent in favor of the Intra-Frame coded videos (ProRes and DNxHD). But the main issue for me is as I said the smoother workflow using ProRes while H264 gets stuck from time to time and forces me to work slower than I’m used to. If you work slowly or hardly scrub back and forth in your project window to place audio items in sync with the video (something you do a lot when you’re a post-production audio editor or designer, much less if you’re a music composer), then I can see how it wouldn’t matter to you. Another thing to keep in mind is that many users report that with H264 they never get a perfect lip-sync when they do dialogue editing work and it just looks more in-sync with ProRes or DNxHD because of their Intra-Frame compression where every video frame is a KeyFrame (I-Frame).
In short, H264 is considered an End-User format and was designed for that purpose; to be played back continuously not being scrubbed back and forth in an editing software. But there are no rules, as long as you understand the pros and cons, anyone can do whatever he feels is right for him.