Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
HEVC Support
- Thread starter Eliottjames
- Start date
- Sort by reaction score
I know the facts regarding hardware. This is why I said someone should try.
I remuxed some files, it worked fine with your script. The only problem is, that I can't jump to a later point of the movie in the timeline. Not in Quick Look, not in VLC. VLC seems to crash every time i try to skip some minutes of the movie.
Is there a solution? Thank you!
If I'd be Apple's marketing team, I'd hold the HEVC gpu support until they're ready to release the next version of FCPX. That way they'd have an edge ahead of the competition. Along with the release of the iMac Pro they could promote the huge difference the HEVC makes. Apple doesn't want to give Adobe months time to tool Premiere Pro before they get FCPX out.And they got criticised for a long time for being backwards, closed minded and falling behind Windows. This year they signalled several times that they accept the criticism and will modernise the OS. That meant playing a lead with HEVC, improving Metal, attracting more gamers, developing VR, supporting eGPU, and reintroducing the modular tower Mac.
You see now? If we get all the above but then a big FU for HEVC decode on GPU it would be a real insult to Mac users. We're being sold this idea that finally Apple is going to be serious about graphics again. Let's see it happen. Otherwise it's another year of ******** hype and products with planned obsolescence built in.
That's all I need to say now
That's potentially illegal of course and similar to the trouble Google and Microsoft have had. Apple too have been slapped for this.
It's possible that Apple has already done this with FCP by having GPU encode drivers only activate within that application but not available to other apps.
On the Mac Pro forum I famously benchmarked Premiere h264 encoding on a Mac Pro. It was a very thorough test comparing the rendering time in macOS and Windows on the same machine.
On macOS when we selected the OpenCL or CUDA renderer, they were no faster than CPU.
The Windows version encoded 4 times faster. This was a sign to us that the macOS version of Premiere didn't have access to h264 encoding on GPU.
Sure it is controversial, but not that much different than what Cuda is with Nvidia. Apple doesn't want to open too much to give the competition an edge. As doesn't Nvidia with Cuda.
But to avoid bad press, Apple could bring HVEC for everybody same time with FCPX release. It gives Apple at least 6 months time to be the best in class. On Mac platform.
Marketing wise releasing iMac Pro same time with new FCPX would work - of course along with the 10.13.2 update with HVEC.
Last edited:
Can you stop talking about things you don't know?
Accelerated H.264 encoding via QuickSync is available for all apps on macOS. The only reason Premiere can't use it is because Adobe didn't bother do add it. There is no acceleration outside of QuickSync.
You were comparing two completely different H.264 encoders with different settings and different applications. That's not the right way to compare two encoders.
Accelerated H.264 encoding via QuickSync is available for all apps on macOS. The only reason Premiere can't use it is because Adobe didn't bother do add it. There is no acceleration outside of QuickSync.
You were comparing two completely different H.264 encoders with different settings and different applications. That's not the right way to compare two encoders.
Last edited:
Quick sync is only available via the AVFoundation framework, which uses the hardware behind the scenes and does not allow developers "direct" access.
Premiere uses a different video engine, so it cannot access Quick Sync.
On Windows, I believe intel makes Quick Sync available at a much lower level, so all apps can use it.
It's always been this way with Apple. They don't allow hardware vendors to expose certain features. Apple enables them via high-levels frameworks. It was the case with H.264 hardware decoding, which was only accessible via AVFoundation. They only made it available at a lower level (VDADecoder) because customers complained about the poor performances of flash.
EDIT. Maybe quick sync is available via VideoToolBox.framework. That's relatively low level and could be used by Premiere... maybe.
Premiere uses a different video engine, so it cannot access Quick Sync.
On Windows, I believe intel makes Quick Sync available at a much lower level, so all apps can use it.
It's always been this way with Apple. They don't allow hardware vendors to expose certain features. Apple enables them via high-levels frameworks. It was the case with H.264 hardware decoding, which was only accessible via AVFoundation. They only made it available at a lower level (VDADecoder) because customers complained about the poor performances of flash.
EDIT. Maybe quick sync is available via VideoToolBox.framework. That's relatively low level and could be used by Premiere... maybe.
Last edited:
It's been available in VideoToolBox.framework since years.
But as every hardware encoder, quality is horrible if you compare it to x264. I had implemented it in HandBrake years ago, but there weren't many advantages, just set x264 to ultrafast and you get the same result.
But as every hardware encoder, quality is horrible if you compare it to x264. I had implemented it in HandBrake years ago, but there weren't many advantages, just set x264 to ultrafast and you get the same result.
Ah, nice to see the G4 iMac again... one of my favorite Mac designs!
Now I'm curious... anyone has run a quality/bitrate comparison between x264 and Apple's HEVC encoder? Part of why h.264 was so huge was because of the perceptible quality improvements... if HEVC is just about reducing file size then it's useful for streaming but less compelling for personal media. And even then, I wonder how Apple's encoder compares to x264.
I haven't done this test, and I don't have a link, but I thought I read somewhere that some people claim that x265 superfast is similar quality to Intel Quick Sync for h.265 HEVC encoding, while being roughly as fast too.
However, it's not really about encoding speed IMO. For me it's about CPU usage. x265 superfast would still use a ton of CPU.
For me though, the main issue is CPU usage for playback. With some of the TV demos for 4K 10-bit HEVC, my iMac using Kaby Lake's Quick Sync uses less than 10% CPU, and even my MacBook only uses 25% CPU. For software-only playback, it doesn't even work properly on either machine. Can't play those files cleanly even with 100% CPU, and multitasking is impossible. For my i5-7600 iMac, it's like trying to play a 20 Mbps h.264 1080p file on a 2.0 GHz Core Duo without hardware h.264 playback support. You're able to get clearly rendered video but it's still unwatchable because of all the stutters. For the i7-7700K iMac, it's almost smooth but not quite, and not only is the CPU at maximum, so is the case fan, drowning out the audio. And on the MacBook with software-only decode it's a total lost cause.
Apple's HEVC encoder might be quite good, but x265 is a different story depending on the content. Higher bitrate stuff is often better on x264 still, but if you want HDR then x265 is the only consumer player in town.
Of course as apple's is a hardware encoder its not going to be as flexible or as high quality as software anyway, so we'd have to say whats good at lower quality bitrates.
http://iphome.hhi.de/marpe/download/Preprint-Performance-Comparison-AV1-HEVC-AVC-PCS2016.pdf
Maybe a bit harsh but good demonstration of how slow x265 is for encoding, will probably be a long time before its up to the quality of commercial encoders.
Of course as apple's is a hardware encoder its not going to be as flexible or as high quality as software anyway, so we'd have to say whats good at lower quality bitrates.
http://iphome.hhi.de/marpe/download/Preprint-Performance-Comparison-AV1-HEVC-AVC-PCS2016.pdf
Maybe a bit harsh but good demonstration of how slow x265 is for encoding, will probably be a long time before its up to the quality of commercial encoders.
On the Pentium Skylake I tried with above videos, Windows Media Player did software decoding of 10bit 4K HEVC at 25% CPU. That's a dual core CPU with no hyperthreading. 60FPS Playback and real time scrubbing.
Which demo videos? Some of the videos are harder to decode than others. The one I have been using the most is the Sony Camp 10-bit (not 8-bit) 76 Mbps HEVC video. Using IINA, I couldn't even do it completely cleanly with an i7-7700K in software on the Mac.
http://www.4ktv.de/testvideos/
Note though that Windows Media Player does use Quick Sync including for HEVC. It could be doing hybrid decode on Skylake, unless you're inadvertently using a discrete GPU to decode.
Fortunately, the iPhone encoded 8-bit 4K HEVC is pretty easy to decode in software... although my iPad Air 2 (with A8 SoC) still can't do it well.
Sony Camp, Bravia glassmaking, and a few other latest ones that had the highest bit rates on that site.
25% CPU on a dual core system on Windows means 50% of a CPU core right? I really don't like how windows reports CPU usage.
Anyhow 50% CPU usage for a 4K 60fps HEVC video just seems impossible. A 4K 24fps video takes ~250% CPU of my Kaby lake i5 in VLC. The Sony Camp (Nature) 60 fps video is unplayable (350+% CPU and the image stays black). In quicktime, it takes 25% of a CPU (adding usages of QT player, VTDecoderXPCService and WindowServer).
I'd be very surprised if VMP could do miracles and use like 8x less CPU than VLC in software. My guess is that you have hardware decoding going on (by the GPU maybe?).
There's no GPU in that system. It's a very basic black box I use as a storage server. CPU is Pentium Skylake G4400.
I'll redo the test and post pics and vids.
Last edited:
Hang on, looking for the video codec. I did a clean install 2 weeks ago and don't have it. It's asking me to join the insider programme if I want to download it from the store.
NB I didn't use VLC. I used Windows Media Player.
I just tested both of the Sony Camp videos on my hackintosh with i7-7700K @5.1GHz and GTX 10880 on Sierra 10.12.6.
- On VLC, it was unwatchable.
- QuickTime reported that the files could not be opened.
- IINA played both files fine.
- Camp SDR 8-bit showed ~260-300% (out of a possible 800%) CPU usage.
- Camp HDR 10-bit showed ~260-370% (out of a possible 800%) CPU usage.
Thanks. Just note though that it would be the most useful to test QuickTime in 10.13.
The way to do the test for software playback in QuickTime would still be in 10.13.
In 10.12 it doesn’t work at all regardless of the hardware. In 10.13 it’s hardware 10-bit decode for Kaby Lake but software 10-bit decode for anything earlier.
