macOS 11 Big Sur Safari YouTube 4K HDR VP9 support

[EugW]

Late 2013 to Mid 2015 rMBPs all use Haswell, the only rMBP that got Broadwell was the 13-inch 2015 rMBP, even then 3.1 GHz and 2 cores, LOL.

But yeah, I'm looking at the QS chart and VP9 is not in the grid for Haswell or Broadwell for hardware decode at all. And yet there it is right in the screenshots being posted, and playback is smooth (relatively on my older, am going to try to put BS on a 3.1 GHz i7 2015 rMBP and see if it improves..



It might be either a bone they're throwing to Intel machines or something some engineer snuck into the APIs, remember this is still a beta.. that 8K playback might be something they yank in the final release.. Apple has pulled crap like that before.

Let's see if 9to5Mac or MacRumors posts an article like "Big Sur Beta 5 brings 8K playback to pre-2015 Mac laptops" that would be sure to get Apple to remove it. 'Oh that was just an engineering experiment'

Intel had written drivers for partial GPU-based VP9 decode assist for Windows years ago, that supported both Haswell and Broadwell, so there is precedent for this.

New Intel IGP drivers add H.265, VP9 hardware decode support

Intel graphics drivers releases aren't usually very exciting, but this one is worth pointing out. Numbered 15.36.14.4080, this update imbues Haswell and Broadwell processors with hardware acceleration support for two...

techreport.com

However, @jyavenard said Intel removed this support from the drivers a year later.

It might be either a bone they're throwing to Intel machines or something some engineer snuck into the APIs, remember this is still a beta.. that 8K playback might be something they yank in the final release.. Apple has pulled crap like that before.

Sidecar worked on the iPad Air 2 with A8X in the iPadOS 13 beta, until it didn't... cuz they yanked it.

 

[Earl Urley]

Maybe the optimized drivers had some adverse effect on Windows systems that isn't present in macOS.

Also, it's not like there's a ton of 8K content available other than the demos on YouTube, but it's good to know that there's now technically no good excuse for not having smooth 4K/8K playback on older Mac laptops dating back to Late 2013.

 

[EugW]

Maybe the optimized drivers had some adverse effect on Windows systems that isn't present in macOS.

Also, it's not like there's a ton of 8K content available other than the demos on YouTube, but it's good to know that there's now technically no good excuse for not having smooth 4K/8K playback on older Mac laptops dating back to Late 2013.

I don't think the drivers are meant to support 8K though.

 

[white7561]

I don't think the drivers are meant to support 8K though.

To be honest. I'm fine with 4k60fps. As long as it goes all the way to old 2014 MacBooks... HDR would be nice of course on the new screens with wide color support like the 16 inch . Also hoping chrome to support it too

 

[EugW]

To be honest. I'm fine with 4k60fps. As long as it goes all the way to old 2014 MacBooks... HDR would be nice of course on the new screens with wide color support like the 16 inch . Also hoping chrome to support it too

Yes me too.

My fully supported 2017 Macs work up to 4Kp60 HDR, but not 8K SDR. That's fine by me, but I'm still confused as to how others with older and less powerful machines are getting smooth 8K playback when my 3.5 GHz Core i5-7600 iMac cannot.

 

[Superhai]

Maybe the optimized drivers had some adverse effect on Windows systems that isn't present in macOS.

After looking around internet the interest about VP9 seem to have dwarfed that of HEVC, and it seem implementation had very limited interest. I think a major reason must be that VP9 barely was introduced by Google at time and most videos on YouTube served h264. There are several issues and commits related to the partial acceleration, but most seem to be hampered by noise from other discussions or no interest.
There is this from the intel forum https://community.intel.com/t5/Grap...ver-update-posted-for-Haswell-and/td-p/456967 but seem overly negative.

There is also someone requesting the acceleration in the linux drivers from intel, but without any response so far https://github.com/intel/intel-vaapi-driver/issues/513

Also, it's not like there's a ton of 8K content available other than the demos on YouTube, but it's good to know that there's now technically no good excuse for not having smooth 4K/8K playback on older Mac laptops dating back to Late 2013.

To be honest 8k do not have a practical use, as I don't think any of the Haswell/Broadwell or other hybrid acceleration CPUs with integrated GPUs are able to drive a 8k display.

 

[Earl Urley]

My fully supported 2017 Macs work up to 4Kp60 HDR, but not 8K SDR. That's fine by me, but I'm still confused as to how others with older and less powerful machines are getting smooth 8K playback when my 3.5 GHz Core i5-7600 iMac cannot.

The 2017 Retina iMacs only use AMD Radeon 5xx GPUs. Apple seems to be leveraging undocumented capabilities in Intel Iris / 5100 GPUs and up to play VP9 / 8K videos in YouTube (so far.). That's probably why you're not getting the 8K choice in Safari BS 5.

Maybe you'd see it if you were willing to install OpenCore and enable full hardware acceleration, but that's for discussion in another thread..

Pretty much all rMBPs from Late 2013 to present have Intel iGPUs installed, either as the only GPU or as the GPU that runs when power-saving features are enabled.

To be honest. I'm fine with 4k60fps. As long as it goes all the way to old 2014 MacBooks... HDR would be nice of course on the new screens with wide color support like the 16 inch . Also hoping chrome to support it too

Nope, just tried the latest Chrome on BS Beta 5, 4K seems to be the limit, even on the 8K videos I was able to run in Safari. And I can get the 8K choice in Safari on a Late 2013 rMBP, so 2014 should be fine.

 

[EugW]

The 2017 Retina iMacs only use AMD Radeon 5xx GPUs. Apple seems to be leveraging undocumented capabilities in Intel Iris / 5100 GPUs and up to play VP9 / 8K videos in YouTube (so far.). That's probably why you're not getting the 8K choice in Safari BS 5.

Maybe you'd see it if you were willing to install OpenCore and enable full hardware acceleration, but that's for discussion in another thread..

Pretty much all rMBPs from Late 2013 to present have Intel iGPUs installed, either as the only GPU or as the GPU that runs when power-saving features are enabled.

My 2017 Retina iMac has Intel HD 630, which is GT2. The Intel iGPU is used for HEVC decode, and presumably VP9 decode as well.

Haswell Iris 5100 is GT3. Broadwell Iris 6100 is also GT3. Maybe that's the difference?

 

[white7561]

Hmm interesting. Anyways hoping for the best then!! Since even 4k on a tiny screen would definitely improve the clarity and since it uses more bitrate. It'll look so much better. I used to always use 1440p on youtube because it looks so much sharper than 1080.

 

[EugW]

Hmm interesting. Anyways hoping for the best then!! Since even 4k on a tiny screen would definitely improve the clarity and since it uses more bitrate. It'll look so much better. I used to always use 1440p on youtube because it looks so much sharper than 1080.

The ironic part is we used to have 1440p in Safari YouTube already, using h.264, and it looked very good. But then it was removed with a max of 1080p.

 

[white7561]

The ironic part is we used to have 1440p in Safari YouTube already, using h.264, and it looked very good. But then it was removed with a max of 1080p.

I know. It's not Apple. Chrome still supports it. The problem is from YouTube's part. They stopped giving videos above 1080p60fps in h264. To get 1440 to up you'll need VP9 or AV1 nowadays. That's why we don't have 1440 now haha

 

[Earl Urley]

My 2017 Retina iMac has Intel HD 630, which is GT2. The Intel iGPU is used for HEVC decode, and presumably VP9 decode as well.

Haswell Iris 5100 is GT3. Broadwell Iris 6100 is also GT3. Maybe that's the difference?

Whoops, I was looking at the 27-inch 2017s which are all Radeon driven. This is the fabled non-Retina 21.5 inch 2017, which does indeed come with an Iris 630, and also has Kaby Lake processor.

GT2 vs GT3? I dunno..

I might need to try to install BS Beta 5 on my 2012 QC Mac Mini..

 

[EugW]

Whoops, I was looking at the 27-inch 2017s which are all Radeon driven. This is the fabled non-Retina 21.5 inch 2017, which does indeed come with an Iris 630, and also has Kaby Lake processor.

GT2 vs GT3? I dunno..

I might need to try to install BS Beta 5 on my 2012 QC Mac Mini..

Mine is a 27" 2017. ALL of the regular 2017 iMacs have Intel iGPUs in them, because it's built into Kaby Lake. However, mine also has the Radeon 575 as you say. The iMac Pro doesn't have an iGPU though because it runs a Xeon. Most Xeons do not have iGPU.

 

[Earl Urley]

Mine is a 27" 2017. ALL of the regular 2017 iMacs have Intel iGPUs in them, because it's built into Kaby Lake. However, mine also has the Radeon 575 as you say. The iMac Pro doesn't have an iGPU though because it runs a Xeon. Most Xeons do not have iGPU.

But you're not getting the 8K choices in Safari under Big Sur Beta 5?

 

[EugW]

But you're not getting the 8K choices in Safari under Big Sur Beta 5?

I get the choice but 8K is a slideshow. This is all 8-bit BTW. I wasn't given the HDR option for those videos.

Intel's Windows drivers for that generation of iGPU are only supposed to support up to 4Kp60, so that makes sense. And it's interesting the way it works on my iMac Core i5 in Big Sur:

VP9 YouTube in Safari at 4Kp60 is perfectly smooth, and CPU usage is fairly low.
In contrast, 8K is mostly just a slideshow, with an image every several seconds, but CPU usage is even lower. Yes, lower, and this is consistent.

I am assuming this just means the GPU is doing the decoding work but there still needs to be some CPU usage to display it. However, for 8K, the iGPU simply can't cope, and thus only spits out occasional images, so the CPU works even less.

On my MacBook Core m3, the behaviour is almost exactly the same, except that the CPU usage is a bit higher (although still relatively low), which makes sense since m3-7Y32 is much slower than i5-7600.

 

[white7561]

What I do wonder tho , if apps like IINA , VLC , etc will add support for the new VP9 decoder.. since it'll be so nice to be able to watch movies or downloaded youtube videos using HW Acceleration. Also this should mean that Twitch on chrome won't just drain the battery like crazy! And if twitch and I think google duo app update to add support of this new hw decoder. It's prob gonna be fine


On bootcamp, does VP9 works with hw decoder for the macbook 16inch etc?

 

[ArPe]

I get the choice but 8K is a slideshow. This is all 8-bit BTW. I wasn't given the HDR option for those videos.

Better to say BT.709 which the Best of 8K Video uses. That video doesn’t have an 8K HDR option either on Mac or Windows even with HDR display connected.

You can get wide enough colour in that 709 gamma profile. You can also get 10 bit color or P3 coverage from your GPU on displays that are by default BT.1886. Conversely you can encode 8 bit color to ST.2084 video streams, so not all HDR necessarily has to be in 10 bit color.

I’m just nitpicking

 

[EugW]

Better to say BT.709 which the Best of 8K Video uses. That video doesn’t have an 8K HDR option either on Mac or Windows even with HDR display connected.

You can get wide enough colour in that 709 gamma profile. You can also get 10 bit color or P3 coverage from your GPU on displays that are by default BT.1886. Conversely you can encode 8 bit color to ST.2084 video streams, so not all HDR necessarily has to be in 10 bit color.

I’m just nitpicking

Oh I misunderstood then. I thought that Best of 8K had an HDR version. Which videos support 8K HDR (or 4K HDR) in Safari?

 

[Superhai]

Oh I misunderstood then. I thought that Best of 8K had an HDR version. Which videos support 8K HDR (or 4K HDR) in Safari?

I don't think you will find 8k HDR videos streamed in VP9 on YouTube now, they seem to be solely in AV1 format. But the best of 8k have a HDR version in 4k.

 

[juan985_Spain]

I have been testing You Tube 4k playback in Safari under Big Sur and in Mojave using Chrome and here are my numbers using a MacBook Pro Retina 15" 2015 with integrated graphics Intel Iris Pro 5200.

(iStats Menus) Safari Big Sur YouTube

CPU 20%

Temp 81ºC

YouTube Process 140% (out of 400%)

(iStats Menus) Chrome Mojave YouTube

CPU 30%

Temp 80ºC

YouTube Process 200% (out of 400%)

As you can see Safari is more efficient than Chrome when playing 4k videos in an old machine like mine, however as when running Mojave Im using Volta App to undervolt the processor the temps are more or less the same. Volta App does not work under Big Sur so I can not undervolt the CPU. Im sure that if I could undervolt running Big Sur the temps would be lower.

Best.

 

[lancastor]

On the latest Beta release of Big Sur release I can't play some videos. YouTube shows only a black window.

 

[EugW]

Just for fun I tried playing the Costa Rica video on my 14 year-old Mac Pro with 2 x 2.66 GHz dual-core Xeon 5150, via software decode in Chrome. (I have 10.11.6 El Capitan installed, as well as Windows 10.) 1080p60 is playable, but with extremely high CPU usage, so multi-tasking is not really viable. Sometimes even just changing the YouTube screen size during playback has a several second delay. Not surprisingly, 1440p is a disaster.

I then tried playing the video on my Windows 10 AMD Phenom II X6 1055T (which was a 10 year-old Athlon II X3 435 machine I upgraded several years ago). 1080p60 is smooth, and multi-tasking is doable at 1080p60. 1440p works but with some stutters and extremely high CPU usage, so 1440p with multi-tasking is too much for it.

It's too bad that YouTube no longer allows 1440p h.264 in Safari. 1440p is all I would need, since the Radeon 5770 in the Mac Pro maxes out at 1440p anyway.

However, I will be upgrading the Mac Pro soon to 2 x 2.33 GHz quad-core Xeon E5345. If that is successful, that should give me a machine that is about the same speed as the 1055T or perhaps just slightly faster, so 1440p VP9 will probably continue to be a big problem. An upgrade to Xeon X5365 may have been able to handle 1440p60 VP9 playback in software, but it's not worth the money (4X the CPU upgrade cost) and the TDP is almost twice as high at 150 Watts per CPU, and there are two of them. I guess I should be satisfied with "just" 1080p60 support in 2020 in a modern browser on a 14 year-old machine. 🤪

Interesting.

I have acquired a 13 year-old Mac Pro with 2 x 3.0 GHz quad-core Xeon X5365. So, a total of 8 cores of Core 2 Duo class cores.

I noticed in 10.7 Lion I had no major problem playing Costa Rica at 1440p VP9 on that machine in Firefox Legacy 67 (which is a back port of Firefox 67 to Lion). Right when it started and I was adjusting windows etc, it stuttered, but after that it was perfectly smooth with no dropped frames at all.

So I switched over to 10.11 El Capitan and again in Firefox 78 LTS (which came out at the end of June 2020 and is the last version supported in El Capitan) it played 1440p VP9 Costa Rica smoothly. CPU usage was roughly 40% to 60% or occasionally 70% at the beginning. Again, after it settled in the first few seconds, it was perfectly smooth with never a dropped frame. I could go in and out of full screen mode too without dropping frames.

Then I switched to Chrome 84 (which is the latest version). It mostly could play the 1440p VP9 but had a lot more hiccups getting settled down before it stopped stuttering, and it would occasionally still stutter even after settling down. CPU usage was 60% to 80% or occasionally a bit higher, esp. at the beginning.

So, it seems Chrome VP9 playback is significantly less efficient than Firefox VP9 playback on this machine. Why? Video card is Radeon HD 5770, which has no VP9 decode assist at all.

tl;dr:

On an ancient 8-core Xeon MacPro2,1 from 2007 with no hardware VP9 decode assist, I have a bit of trouble playing back Costa Rica 1440p in Chrome 84 (released in July) with usually about 60-80% CPU usage, but it is noticeably better in Firefox 78 LTS (released in June) with usually about 40-60% CPU usage. (Video is Radeon 5770 with no hardware decode assist.) So, why is Firefox so much more efficient than Chrome for this?

 

[johnalan]

Here's a sample of VTDecoderXPCService that says that the decoded frame is coming directly from the GPU driver:

Sampling process 628 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling VTDecoderXPCService (pid 628) every 1 millisecond
Process:         VTDecoderXPCService [628]
Path:            /System/Library/Frameworks/VideoToolbox.framework/Versions/A/XPCServices/VTDecoderXPCService.xpc/Contents/MacOS/VTDecoderXPCService
Load Address:    0x10d63d000
Identifier:      VTDecoderXPCService
Version:         ???
Code Type:       X86-64
Parent Process:  ??? [1]

Date/Time:       2020-08-09 08:06:11.835 +0200
Launch Time:     2020-08-09 08:05:42.596 +0200
OS Version:      macOS 11.0 (20A5343i)
Report Version:  7
Analysis Tool:   /usr/bin/sample

Physical footprint:         174.7M
Physical footprint (peak):  174.7M
----

Call graph:
    2 Thread_8585   DispatchQueue_1: com.apple.main-thread  (serial)
    + 2 start  (in libdyld.dylib) + 1  [0x7fff6bc98851]
    +   2 main  (in VTDecoderXPCService) + 16  [0x10d640f96]
    +     2 xpc_main  (in libxpc.dylib) + 437  [0x7fff6bf254fb]
    +       2 _xpc_objc_main  (in libxpc.dylib) + 825  [0x7fff6bf25a73]
    +         2 -[NSRunLoop(NSRunLoop) run]  (in Foundation) + 76  [0x7fff2d3893e4]
    +           2 -[NSRunLoop(NSRunLoop) runMode:beforeDate:]  (in Foundation) + 212  [0x7fff2d2fafd1]
    +             2 CFRunLoopRunSpecific  (in CoreFoundation) + 563  [0x7fff2a927134]
    +               2 __CFRunLoopRun  (in CoreFoundation) + 1315  [0x7fff2a927d40]
    +                 2 __CFRunLoopServiceMachPort  (in CoreFoundation) + 316  [0x7fff2a929650]
    +                   2 mach_msg  (in libsystem_kernel.dylib) + 60  [0x7fff6be07590]
    +                     2 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff6be0721e]
    2 Thread_8595
    + 1 start_wqthread  (in libsystem_pthread.dylib) + 15  [0x7fff6bed04c3]
    + ! 1 _pthread_wqthread  (in libsystem_pthread.dylib) + 414  [0x7fff6bed1556]
    + !   1 __workq_kernreturn  (in libsystem_kernel.dylib) + 10  [0x7fff6be088de]
    + 1 start_wqthread  (in libsystem_pthread.dylib) + 0  [0x7fff6bed04b4]
    2 Thread_9123
    + 2 thread_start  (in libsystem_pthread.dylib) + 15  [0x7fff6bed04d7]
    +   2 _pthread_start  (in libsystem_pthread.dylib) + 224  [0x7fff6bed49b4]
    +     2 ???  (in AppleGVA)  load address 0x7fff3edea000 + 0x6b7be  [0x7fff3ee557be]
    +       2 ???  (in AppleGVA)  load address 0x7fff3edea000 + 0x6ba03  [0x7fff3ee55a03]
    +         2 ???  (in AppleGVA)  load address 0x7fff3edea000 + 0xb0978  [0x7fff3ee9a978]
    +           1 ???  (in AppleGVAVPXDecoder)  load address 0x10d760000 + 0x2e1c  [0x10d762e1c]
    +           ! 1 _CFRelease  (in CoreFoundation) + 238  [0x7fff2a9f2910]
    +           !   1 BBufFinalize  (in CoreMedia) + 144  [0x7fff2bdae860]
    +           !     1 receivedMemoryAllocator_Deallocate  (in CoreMedia) + 338  [0x7fff2be8b5ab]
    +           !       1 receivedMemoryAllocator_tellOriginToDecrementUseCountOfBlock  (in CoreMedia) + 270  [0x7fff2be8b6e5]
    +           !         1 -[OS_xpc_object dealloc]  (in libxpc.dylib) + 17  [0x7fff6bf157ec]
    +           !           1 _xpc_dictionary_dispose  (in libxpc.dylib) + 34  [0x7fff6bf15bbf]
    +           !             1 _xpc_dictionary_node_free  (in libxpc.dylib) + 68  [0x7fff6bf15cdf]
    +           !               1 -[OS_xpc_object dealloc]  (in libxpc.dylib) + 47  [0x7fff6bf1580a]
    +           !                 1 _objc_rootDealloc  (in libobjc.A.dylib) + 62  [0x7fff6aa15f42]
    +           !                   1 objc_destructInstance  (in libobjc.A.dylib) + 146  [0x7fff6aa16011]
    +           !                     1 objc_object::sidetable_clearDeallocating()  (in libobjc.A.dylib) + 83  [0x7fff6aa16315]
    +           !                       1 _os_unfair_lock_lock_slow  (in libsystem_platform.dylib) + 162  [0x7fff6bec5145]
    +           !                         1 __ulock_wait  (in libsystem_kernel.dylib) + 10  [0x7fff6be0896e]
    +           1 ???  (in AppleGVAVPXDecoder)  load address 0x10d760000 + 0x2ee4  [0x10d762ee4]
    +             1 VTDecoderSessionEmitDecodedFrame  (in VideoToolbox) + 1247  [0x7fff375093c8]
    +               1 ???  (in VideoToolbox)  load address 0x7fff37500000 + 0xf8cdd  [0x7fff375f8cdd]
    +                 1 ???  (in VideoToolbox)  load address 0x7fff37500000 + 0xe4074  [0x7fff375e4074]
    +                   1 xpc_connection_send_message_with_reply_sync  (in libxpc.dylib) + 238  [0x7fff6bf1b852]
    +                     1 dispatch_mach_send_with_result_and_wait_for_reply  (in libdispatch.dylib) + 50  [0x7fff6bc57abe]
    +                       1 _dispatch_mach_send_and_wait_for_reply  (in libdispatch.dylib) + 518  [0x7fff6bc576c6]
    +                         1 mach_msg  (in libsystem_kernel.dylib) + 60  [0x7fff6be07590]
    +                           1 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff6be0721e]
    1 Thread_8591
    + 1 start_wqthread  (in libsystem_pthread.dylib) + 15  [0x7fff6bed04c3]
    +   1 _pthread_wqthread  (in libsystem_pthread.dylib) + 414  [0x7fff6bed1556]
    +     1 __workq_kernreturn  (in libsystem_kernel.dylib) + 10  [0x7fff6be088de]
    1 Thread_8594
    + 1 thread_start  (in libsystem_pthread.dylib) + 15  [0x7fff6bed04d7]
    +   1 _pthread_start  (in libsystem_pthread.dylib) + 224  [0x7fff6bed49b4]
    +     1 _dispatch_worker_thread  (in libdispatch.dylib) + 284  [0x7fff6bc505e3]
    +       1 _dispatch_semaphore_wait_slow  (in libdispatch.dylib) + 58  [0x7fff6bc42066]
    +         1 _dispatch_sema4_timedwait  (in libdispatch.dylib) + 76  [0x7fff6bc41c3a]
    +           1 semaphore_timedwait_trap  (in libsystem_kernel.dylib) + 10  [0x7fff6be07272]
    1 Thread_8594   DispatchQueue_93: vtdecoder-connection-event-queue-0x7f9331419a00  (serial)
    + 1 thread_start  (in libsystem_pthread.dylib) + 15  [0x7fff6bed04d7]
    +   1 _pthread_start  (in libsystem_pthread.dylib) + 224  [0x7fff6bed49b4]
    +     1 _dispatch_worker_thread  (in libdispatch.dylib) + 218  [0x7fff6bc505a1]
    +       1 _dispatch_root_queue_drain  (in libdispatch.dylib) + 326  [0x7fff6bc507a5]
    +         1 _dispatch_lane_invoke  (in libdispatch.dylib) + 426  [0x7fff6bc4805e]
    +           1 _dispatch_lane_serial_drain  (in libdispatch.dylib) + 263  [0x7fff6bc47407]
    +             1 _dispatch_mach_invoke  (in libdispatch.dylib) + 498  [0x7fff6bc59508]
    +               1 _dispatch_lane_serial_drain  (in libdispatch.dylib) + 263  [0x7fff6bc47407]
    +                 1 _dispatch_mach_msg_invoke  (in libdispatch.dylib) + 441  [0x7fff6bc58997]
    +                   1 _dispatch_client_callout4  (in libdispatch.dylib) + 9  [0x7fff6bc417c7]
    +                     1 _xpc_connection_mach_event  (in libxpc.dylib) + 935  [0x7fff6bf1c140]
    +                       1 _xpc_connection_call_event_handler  (in libxpc.dylib) + 56  [0x7fff6bf1d2d4]
    +                         1 ???  (in VideoToolbox)  load address 0x7fff37500000 + 0xe4f33  [0x7fff375e4f33]
    +                           1 ???  (in AppleGVAVPXDecoder)  load address 0x10d760000 + 0x2c8d  [0x10d762c8d]
    +                             1 ???  (in AppleGVA)  load address 0x7fff3edea000 + 0xb0609  [0x7fff3ee9a609]
    +                               1 ???  (in AppleGVA)  load address 0x7fff3edea000 + 0xafab6  [0x7fff3ee99ab6]
    +                                 1 ???  (in AppleGVA)  load address 0x7fff3edea000 + 0x6b6b8  [0x7fff3ee556b8]
    +                                   1 ???  (in AppleGVA)  load address 0x7fff3edea000 + 0x6b77d  [0x7fff3ee5577d]
    +                                     1 ???  (in AppleIntelKBLGraphicsVADriver)  load address 0x114344000 + 0x2474b  [0x11436874b]
    +                                       1 ???  (in AppleIntelKBLGraphicsVADriver)  load address 0x114344000 + 0x277456  [0x1145bb456]
    +                                         1 ???  (in AppleIntelKBLGraphicsVADriver)  load address 0x114344000 + 0x277312  [0x1145bb312]
    +                                           1 ???  (in AppleIntelKBLGraphicsVADriver)  load address 0x114344000 + 0x20c222  [0x114550222]
    +                                             1 ???  (in AppleIntelKBLGraphicsVADriver)  load address 0x114344000 + 0x210005  [0x114554005]
    +                                               1 ???  (in AppleIntelKBLGraphicsVADriver)  load address 0x114344000 + 0x6b65d  [0x1143af65d]
    +                                                 1 ???  (in AppleIntelKBLGraphicsVADriver)  load address 0x114344000 + 0x65cae  [0x1143a9cae]
    +                                                   1 ???  (in AppleIntelKBLGraphicsVADriver)  load address 0x114344000 + 0x253b7e  [0x114597b7e]
    +                                                     1 IOAccelResourceFinishEvent  (in IOAccelerator) + 148  [0x7fff529e6354]
    +                                                       1 IOConnectCallMethod  (in IOKit) + 186  [0x7fff2da5491f]
    +                                                         1 io_connect_method  (in IOKit) + 383  [0x7fff2da54b08]
    +                                                           1 mach_msg  (in libsystem_kernel.dylib) + 60  [0x7fff6be07590]
    +                                                             1 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff6be0721e]
    1 Thread_8597
      1 start_wqthread  (in libsystem_pthread.dylib) + 0  [0x7fff6bed04b4]

Total number in stack (recursive counted multiple, when >=5):

Sort by top of stack, same collapsed (when >= 5):

I have no idea how you can say that's not hardware accelerated.

This is really interesting and great to see.

Here's a noob question, if the hardware was there in intel Macs, why didn't Chrome/Firefox use it? It is because API wasn't available in OS before BigSur?

EDIT: Ah another user already answered:

It doesn‘t work like that on macOS. Software doesn‘t have direct access to the decoders and encoders. They need to use Apple‘s VideoToolbox (AppleGVA) framework to implement it. It‘s Apple who did the poor job not supporting VP9 for so long. Now as they do, other browsers beside Safari will for sure offer accelerated VP9 playback as well.

 

[Superhai]

Here's a noob question, if the hardware was there in intel Macs, why didn't Chrome/Firefox use it?

What is interesting is why there is limited use of it on hassell, broadwell, crystalwell and similar on Windows. In chrome the video acceleration is deliberately blacklisted on those cpus. They claim poor performance per watt. Also why it was supposedly removed from the intel drivers. From threads there are claims of no benefit, black screen or frame, high cou usage. But it seem to be working good for some. Maybe the subset of Apple machines and cpus don’t are affected.

 

[Earl Urley]

Trip report for Big Sur Beta 6:

They took it away!

8K vids that played before now back to a maximum of 1080p60. Oh well.

8K vids only playing with avc1 codec. Looks like they yanked VP9 support.