HDR 4K video support - macOS vs Windows

[CreeptoLoser]

Hi

This post is to inform users about HDR 4K video support using HEVC decoding in macOS.

Hardware support

Currently macOS supports software decoding on Macs with 6th gen Skylake processors, and hardware decoding on Macs with 7th gen Kabylake processors and above.

Macs with Skylake processors are able to play 4K videos encoded with the Rec 709 color profile, but are not capable of smooth playback of videos using the HDR standard Rec 2020 color profile.

Decoding on GPU is not currently fully supported on any Mac, but the graphics card does help with scaling.

Windows does support HEVC decoding on GPU for Nvidia and AMD cards. However, Nvidia only outputs 8 bit video signals on GeForce cards. AMD supports 10 bit on all Radeon Polaris and Vega cards.

macOS vs Windows support

Under macOS High Sierra and above, no special settings need to be applied. HDR videos will automatically display the content correctly.

Macs ship with screens supporting the P3 color profile. Any HDR videos using a wider gamut than P3 will have their color space squeezed down. This isn’t an issue in most cases. Videos will still look great.

Under Windows, users must enable ‘HDR mode’ in the control panel in order to display the content correctly. Without HDR mode enabled, the video content will appear burnt out and the colors will be oversaturated.

If you enable ‘HDR mode’ the Windows desktop environment will appear washed out. This mode is only suitable for HDR video content. Currently, Windows can’t automatically enable HDR mode solely when videos play.

Streaming video support

Neither operating system currently support streaming HDR content from popular video sources.

Under macOS, HDR videos streamed from Netflix or Prime will be squeezed into the P3 color profile. This isn’t an issue unless the content uses an extremely wide gamut.

Under Windows with HDR mode on, HDR videos streamed from Netflix or Prime night attempt re-enable HDR mode and freeze. Users will need to disable HDR mode. Videos will then stream correctly but use Rec 709.

Currently iTunes only streams HDR content to Apple TV, so neither macOS or Windows can playback HDR content.

 

[EugW]

Not quite correct. Hardware GPU based decoding of 4K HDR is fully supported on Kaby Lake or later, but this is on the Intel iGPU. Not sure about the iMac Pro but I might guess it works on Vega there since it doesn’t have an Intel iGPU.

The biggest difference for streaming services is that Windows supports 4K DRM but macOS does not. You currently can’t play 4K iTunes, 4K Netflix, or 4K Amazon Prime etc. on a Mac period, regardless if it is HDR or not. However, this could change with an update for macOS Mojave.

 

[CreeptoLoser]

Not quite correct. Hardware GPU based decoding of 4K HDR is fully supported on Kaby Lake or later, but this is on the Intel iGPU

You've repeated what I have said. I didn't say it was on the discreet GPU. I said there is no discreet GPU decode at all in macOS.

 

[EugW]

You've repeated what I have said. I didn't say it was on the discreet GPU. I said there is no discreet GPU decode at all in macOS.

No, you said there is no GPU decoding. That is not correct. You did not specify discreet or not so it can be a bit confusing to some.

 

[h9826790]

The Vega on iMac Pro can actually do the hardware decoding (and obviously it's a dGPU).

Also, it's confirmed that the RX580 (the same GPU as in the Apple eGPU developer kit) also able to perform HEVC hardware decoding in the current 10.14 beta. I have this GPU in my Mac Pro now. I have done the test by myself (as per the following screenshot). 4K HDR HEVC BT.2020 video can be play back smoothly in QuickTime Player on my Samsung CHG 90 with just the RX580.

I tried to show you the required info in a single unmodded screenshot (I only remove the serial numbers).

The video is the Sony_4K_HDR_Camp.mp4, it's widely available on the internet. Clip info as per Mediainfo shows.

CPU is very low workload (but QuickTime is working). The CPU is W3690 (as per my signature), and definitely not capable to doing any HEVC 10 bit high bitrate decoding in both software and hardware method.

GPU is the Apple recommended (for Mac Pro 5,1), Sapphire PULSE RX580 8GB. Which has reasonable workload when decoding the video. And system info confirmed that was the only GPU installed, and displaying 30-bit colour.

iStat showed both the CPU and GPU usage, plus the monitor was working at around 60 FPS (because the video was playing at smooth 60FPS). If the video was not playing, it will be like this (2.2 FPS in this case). Also, no QuickTime shows in the CPU process because no demand from it.

Or if the playback is not smooth, then it will shows the playing frame rate. I use IINA to play the same clip with software decoding. CPU was stressed to 1000%, only 10FPS (The colour seems over saturated in IINA as well)

And if I was playing around the mouse pointer etc to achieve higher FPS, then it will easily jump to 144FPS because CHG 90 is a 144Hz monitor.

Anyway, I think this is good enough to show you that MacOS can play HEVC 10bit HDR BT.2020 smoothly with dGPU hardware decode. And this is on a 9 years old Mac Pro without Skylake (or newer) CPU installed.

 

[CreeptoLoser]

The Vega on iMac Pro can actually do the hardware decoding (and obviously it's a dGPU).

Also, it's confirmed that the RX580 (the same GPU as in the Apple eGPU developer kit) also able to perform HEVC hardware decoding in the current 10.14 beta. I have this GPU in my Mac Pro now. I have done the test by myself (as per the following screenshot). 4K HDR HEVC BT.2020 video can be play back smoothly in QuickTime Player on my Samsung CHG 90 with just the RX580.
View attachment 774878

I tried to show you the required info in a single unmodded screenshot (I only remove the serial numbers).

The video is the Sony_4K_HDR_Camp.mp4, it's widely available on the internet. Clip info as per Mediainfo shows.

CPU is very low workload (but QuickTime is working). The CPU is W3690 (as per my signature), and definitely not capable to doing any HEVC 10 bit high bitrate decoding in both software and hardware method.

GPU is the Apple recommended (for Mac Pro 5,1), Sapphire PULSE RX580 8GB. Which has reasonable workload when decoding the video. And system info confirmed that was the only GPU installed, and displaying 30-bit colour.

iStat showed both the CPU and GPU usage, plus the monitor was working at around 60 FPS (because the video was playing at smooth 60FPS). If the video was not playing, it will be like this (2.2 FPS in this case). Also, no QuickTime shows in the CPU process because no demand from it.
View attachment 774880

Or if the playback is not smooth, then it will shows the playing frame rate. I use IINA to play the same clip with software decoding. CPU was stressed to 1000%, only 10FPS (The colour seems over saturated in IINA as well)
View attachment 774883

And if I was playing around the mouse pointer etc to achieve higher FPS, then it will easily jump to 144FPS because CHG 90 is a 144Hz monitor.
View attachment 774882

Anyway, I think this is good enough to show you that MacOS can play HEVC 10bit HDR BT.2020 smoothly with dGPU hardware decode. And this is on a 9 years old Mac Pro without Skylake (or newer) CPU installed.

Hi,

Thanks for testing.

It seems the iMac Pro was given GPU decoding because it is a pro machine but has a Skylake CPU, therefore the graphics drivers are better.

On MacBook Pro's with Polaris graphics there is no decode on GPU so if RX580 has it then that's neat.

I don't have an RX580 or Vega based system. Can you please try any of the following videos that I have confirmed to be using Rec 2020. These do not play well at all on a 2016 MacBook Pro with Radeon graphics.

They are available at 4kmedia.org:

Sony New York Fashion HDR

Sony Whale Tonga HDR

Sony Swordsmith HDR

Sony Camping in Nature HDR available on that site plays perfectly on the 2016 MacBook Pro with Radeon graphics because it is actually a Rec 709 file that has been wrongly labelled. Unless you have a Rec 2020 version from another site.

 

[h9826790]

Hi,

Thanks for testing.

It seems the iMac Pro was given GPU decoding because it is a pro machine but has a Skylake CPU, therefore the graphics drivers are better.

On MacBook Pro's with Polaris graphics there is no decode on GPU so if RX580 has it then that's neat.

I don't have an RX580 or Vega based system. Can you please try any of the following videos that I have confirmed to be using Rec 2020. These do not play well at all on a 2016 MacBook Pro with Radeon graphics.

They are available at 4kmedia.org:

Sony New York Fashion HDR

Sony Whale Tonga HDR

Sony Swordsmith HDR

Sony Camping in Nature HDR available on that site plays perfectly on the 2016 MacBook Pro with Radeon graphics because it is actually a Rec 709 file that has been wrongly labelled. Unless you have a Rec 2020 version from another site.

The Xeon (on the iMac Pro) doesn't have iGPU (same as the Mac Pro). Therefore, Apple must activate the iMac Pro's GPU hardware decoding and encoding ability. Otherwise, it will be way slower than even a MacBook on HEVC export. And make that super expensive "pro" machine a ridiculous joke.

No problem, test done.

Sony New York Fashion HDR. Smooth

Sony Whale Tonga HDR. NOT smooth

Sony Swordsmith HDR. NOT smooth

Couldn't figure out what makes the Sony New York Fashion HDR so special (I compared the media info and found nothing). But the other two video perform exactly like in High Sierra (without HEVC hardware decoding support)

 

[CreeptoLoser]

The Xeon (on the iMac Pro) doesn't have iGPU (same as the Mac Pro). Therefore, Apple must activate the iMac Pro's GPU hardware decoding and encoding ability. Otherwise, it will be way slower than even a MacBook on HEVC export. And make that super expensive "pro" machine a ridiculous joke.

No problem, test done.

Sony New York Fashion HDR. SmoothView attachment 774917

Sony Whale Tonga HDR. NOT smooth
View attachment 774918

Sony Swordsmith HDR. NOT smooth
View attachment 774919

Couldn't figure out what makes the Sony New York Fashion HDR so special (I compared the media info and found nothing). But the other two video perform exactly like in High Sierra (without HEVC hardware decoding support)

Thanks, man.

Those are the results I expected.

Even though some videos are encoded in Rec 2020 or 10 bit, it appears GPU decoding is only efficient if the video itself is less detailed and has less color palette being used.

The fashion video isn’t so sharp if you look closely. It looked like it has been uprezzed from HD.

Those two videos that don’t play well on the GPU are very detailed with a wide color range.

On Kabylake CPUs and above they play completely smooth though, obviously.

 

[h9826790]

Thanks, man.

Those are the results I expected.

Even though some videos are encoded in Rec 2020 or 10 bit, it appears GPU decoding is only efficient if the video itself is less detailed and has less color palette being used.

The fashion video isn’t so sharp if you look closely. It looked like it has been uprezzed from HD.

Those two videos that don’t play well on the GPU are very detailed with a wide color range.

On Kabylake CPUs and above they play completely smooth though, obviously.

Thanks for the explaination but that doesn’t quite make sense to me. Bitrate is just bitrate, 71.4 and 74.5 isn’t make much difference. Variable bitrate may make some difference, however, the peak is just 114 in the Swordsmith video. Not really that high.

It looks like able to give us “more details” in the other two videos simply becasue the picture is simpler than the fashion video (or the “rate of change of details between each frame” is less on the other two videos), therefore, more bitrate can be used to preserve the details. However, as video codec point of view, they are still HEVC, still roughly the same bitrate, the difficulty level of decoding the video is more or less the same.

I’m fact, in video encoding / decoding aspect, the fashion video is much more demanding. Each frame has lots of changes if compared to the reference frame. This is the reason why it can’t preserve as much details as per the other two videos.

The real issue in the case is, the behaviour suggested that other two videos don’t utilise the hard decoding, but not the GPU unable to decode them. And we can’t find out the why.

 

[EugW]

I am away from home, and I am having trouble downloading the files on hotel WiFI. However, I did manage to download the Swordsmith 4K HDR video via my tethered cell phone. (Don't worry, I have a good data plan.) I'm getting about 17-23% overall CPU usage on my Kaby Lake Core m3 with hardware decoding, on macOS 10.13.6 High Sierra. Smoooooooth.

The percentages listed per application in my screengrab work out to well over 30% CPU usage, but that's because there are 2 physical cores and 4 virtual cores. Activity monitor will report up to 400% CPU usage on Core m3. The real CPU usage is at the bottom, and it is 17.4%.

This is one of the reasons I waited until 2017 to buy, BTW.

Sony Camping in Nature HDR available on that site plays perfectly on the 2016 MacBook Pro with Radeon graphics because it is actually a Rec 709 file that has been wrongly labelled. Unless you have a Rec 2020 version from another site.

Dunno about that site, but there are two separate versions of Sony Nature Camp. One is 8-bit SDR, and the other is 10-bit HDR.

 

[CreeptoLoser]

I am away from home, and I am having trouble downloading the files on hotel WiFI. However, I did manage to download the Swordsmith 4K HDR video via my tethered cell phone. (Don't worry, I have a good data plan.) I'm getting about 17-23% overall CPU usage on my Kaby Lake Core m3 with hardware decoding, on macOS 10.13.6 High Sierra. Smoooooooth.

View attachment 774945

The percentages listed per application in my screengrab work out to well over 30% CPU usage, but that's because there are 2 physical cores and 4 virtual cores. Activity monitor will report up to 400% CPU usage on Core m3. The real CPU usage is at the bottom, and it is 17.4%.

This is one of the reasons I waited until 2017 to buy, BTW.


Dunno about that site, but there are two separate versions of Sony Nature Camp. One is 8-bit SDR, and the other is 10-bit HDR.

Thanks for the test but you have true Kaby Lake so no surprise it will be smooth.
[doublepost=1533701721][/doublepost]

Thanks for the explaination but that doesn’t quite make sense to me. Bitrate is just bitrate, 71.4 and 74.5 isn’t make much difference. Variable bitrate may make some difference, however, the peak is just 114 in the Swordsmith video. Not really that high.

Bit rate is one thing but take a close look at how grainy and detailed the Samurai and Whale videos are.

In the Fashion videos the models faces are blurry compared to better 4K content.

There is another Fashion video on that site that is more demanding but it is a TS file and I can’t play it on macOS. It works on Windows.

 

[EugW]

Thanks for the test but you have true Kaby Lake so no surprise it will be smooth.

I agree, but I just include that for reference, esp. since it's just a fanless Core m3.

When the High Sierra betas came out last year, some people had a hard time believing their Skylake Core i7 machines would fail so bad at this.

 

[h9826790]

Thanks for the test but you have true Kaby Lake so no surprise it will be smooth.
[doublepost=1533701721][/doublepost]

Bit rate is one thing but take a close look at how grainy and detailed the Samurai and Whale videos are.

In the Fashion videos the models faces are blurry compared to better 4K content.

There is another Fashion video on that site that is more demanding but it is a TS file and I can’t play it on macOS. It works on Windows.

I understand that. That’s why I explained the “why”.

For H265, the video is devided into many many reference frame.

Each frame devided into many many different sizes squares.

And then the encoder have to analyse the reference frame, decide the size of each square and encode them accordingly.

The following frame will be base on the reference frame, but only contain the data about the difference. Therefore, more complex picture, or fast moving scene will cost more bitrate.

e.g. two videos, each of them are 1min long.

The first one shows “A” and “B” alternately ever 1/60 frame.

The other one shows “A” for 30s, then “B” for 30s.

Both video contains 30s of “A” and 30s of “B” in total.

But 2nd video will be much shaper (if we pause the video) with the same bitrate because there is no change between frames (except that the 30s mark), therefore, all bitrate can be used to preserve detail.

On the other hand, the 1st video will require lots of bitrate to “teach” the decoder how to change an A to a B (or B to A) between each frame, end up much less bitrate to preserve details.

It’s very easy to explain what happened on that 3 videos (I mean why the fashion video is not that sharp).

There are lots of black area in the swordsmith video, resulting more bitrate can be used the preserve the details.

The Whale video is mainly blue, and consist lots of slow moving scene, also allow more bitrate to preserve details.

The fashion one is relatively fast moving scenes and lots of different details on the clothes / face / etc. Which resulting require more bitrate to “describe” the changes from the reference frame. And less bitrate can be used to preserve details.

However, on the decoder point of view. H265 is just H265, parameters are just parameters, as long as the video is encoding with the same method, and has similar bitrate. They should be all playable or all not playable for the same player.

Also, I can hardly believe the iGPU of the Kabu lake is more powerful than the Polaris video engine (hardware wise).

Anyway, the truth is truth, that two videos are not playable via hardware decode with a RX580 yet is the fact. But I am quite sure it’s completely software issue. Not because of lack of CPU support or the video’s are too high quality etc.

Just like you can’t play the TS file, same codec, different container, then the player don’t know how to handle it properly. 100% software issue.

 

[CreeptoLoser]

I understand that. That’s why I explained the “why”.

For H265, the video is devided into many many reference frame.

Each frame devided into many many different sizes squares.

And then the encoder have to analyse the reference frame, decide the size of each square and encode them accordingly.

The following frame will be base on the reference frame, but only contain the data about the difference. Therefore, more complex picture, or fast moving scene will cost more bitrate.

e.g. two videos, each of them are 1min long.

The first one shows “A” and “B” alternately ever 1/60 frame.

The other one shows “A” for 30s, then “B” for 30s.

Both video contains 30s of “A” and 30s of “B” in total.

But 2nd video will be much shaper (if we pause the video) with the same bitrate because there is no change between frames (except that the 30s mark), therefore, all bitrate can be used to preserve detail.

On the other hand, the 1st video will require lots of bitrate to “teach” the decoder how to change an A to a B (or B to A) between each frame, end up much less bitrate to preserve details.

It’s very easy to explain what happened on that 3 videos (I mean why the fashion video is not that sharp).

There are lots of black area in the swordsmith video, resulting more bitrate can be used the preserve the details.

The Whale video is mainly blue, and consist lots of slow moving scene, also allow more bitrate to preserve details.

The fashion one is relatively fast moving scenes and lots of different details on the clothes / face / etc. Which resulting require more bitrate to “describe” the changes from the reference frame. And less bitrate can be used to preserve details.

However, on the decoder point of view. H265 is just H265, parameters are just parameters, as long as the video is encoding with the same method, and has similar bitrate. They should be all playable or all not playable for the same player.

Also, I can hardly believe the iGPU of the Kabu lake is more powerful than the Polaris video engine (hardware wise).

Anyway, the truth is truth, that two videos are not playable via hardware decode with a RX580 yet is the fact. But I am quite sure it’s completely software issue. Not because of lack of CPU support or the video’s are too high quality etc.

Just like you can’t play the TS file, same codec, different container, then the player don’t know how to handle it properly. 100% software issue.

Good explanation.

I think TS is a Samsung format so I doubt it will be playable by Quicktime.
[doublepost=1533707366][/doublepost]

I agree, but I just include that for reference, esp. since it's just a fanless Core m3.

When the High Sierra betas came out last year, some people had a hard time believing their Skylake Core i7 machines would fail so bad at this.

Reminds me of when DVD came out. I had a PowerBook G3 Lombard. There were two models. One with software decoding that could not play DVDs and one with hardware decoding that could.

 

[h9826790]

Good explanation.

I think TS is a Samsung format so I doubt it will be playable by Quicktime.
[doublepost=1533707366][/doublepost]

Reminds me of when DVD came out. I had a PowerBook G3 Lombard. There were two models. One with software decoding that could not play DVDs and one with hardware decoding that could.

TS is a standard of container. Which is widely use in board casting because it's designed for streaming, has error correction and synchronisation functions. My LG TV can also play TS 265 video. In fact, that's the very 1st gen 4K TV that can support H265, and only can play TS container's H265 video. If I have H265 video in any other container (e.g. MP4 or MKV), I have to use remux (not re-encode) that into a TS container again before I can play that on the TV (with hardware decoder, of course).

But I don't know if it's possible to remux a video for QuickTime player. TBH, I almost never use it, until very recently because of the HEVC hardware decode support in 10.14. beta, then I start to use it. I never really try any remux for QT player.

 

[h9826790]

Just try to play those "problematic" HEVC video again. No problem at all. It's proved that a RX580 is all we need, no new CPU required.

The previous issue is actually software issue. All I need to do is just reboot, and then I can play this Sony Swordsmith HDR video smoothly in Preview.

But once I close it and re-play it again, it become choppy. So, it's software issue, something is stuck and unable to provide hardware decoding. But not the CPU / or any other hardware is limiting.

And that's nothing about how detail the video is.
[doublepost=1534889608][/doublepost]The Sony Whale Tonga HDR can also playback smoothly now

 

[h9826790]

What surprise me is that now even IINA can utilise the hardware decoding on my Mac Pro 5,1 with the RX580 to smoothly playback those 4K HEVC HDR BT2020 video

 

[fhturner]

h982....(do you have an actual name we can call you? )...I posted this in the "official Mojave Mac Pro Metal GPU list" thread, but perhaps it's better discussed here? Pardon me and let me know if dual posting in this case is bad form:

Great News!!
I just installed the Mojave public beta, HEVC 4k 60fps decoding is now enabled on my RX 580. I can now playback HEVC 4K 60FPS in QuickTime with very low cpu usage !!! It's super smooth!

HEVC GPU decoding is supported for Rec 709 profile. That's the HD color space so it's nothing special even at 4K.
For Rec 2020 HDR color space there is still not good smooth playback on GPU.
View Get Info on a media file to check the color space.

Thomasthegps, how many of those sample videos did you test out for HEVC decoding? This (hardware decoding for 4K H.264/265) is what I've been dying for...it's the only thing that really hamstrings my Mac Pro for editing compared to my MacBook Pro, since no Quick Sync. I don't mind waiting for encoding to use CPU, but choppy playback is a killer.

Not sure if contrary to what Soy said above, but as of Mojave DP8, I'm only getting good results (GPU engaged and very little CPU) on 10-bit content, NOT 8-bit. But perhaps that's 10-bit Rec709? That camping video is 10-bit, as is the Bravia OLED glass-blowing video, and they play back w/ under 10% CPU usage on my 12-core 3.46GHz machine, at about 30% RX 580 GPU usage.

The others, such as Surfing and Aquarium, are 8-bit, and they utilize a LOT more overall: 300-500% CPU and around 85% GPU. This is the same as I see in High Sierra 10.13.6...well, HS actually uses less GPU. Also, a 4K H.264 test file of my own from my Lumix G85 shows no improvement that I can tell between HS & MJ. HEVC is welcome, of course, but for me, I'd rather have 4K H.264 decode before anything.

Thoughts? Below are my results.
Fred

HEVC Playback/Decode Tests
1. Bravia OLED 4K [73Mbps, 4k60, 10-bit]
10.13.6 HS: CPU 450-650%, GPU 40%
10.14 DP8 MJ: CPU <10%, GPU 30%

2. Surfing [77Mbps, 4k60, 8-bit]
HS: CPU 350-500%, GPU 25-30%
MJ: CPU 350-500%, GPU 85%

3. Aquarium [80Mbps, 4k60, 8-bit]
HS: CPU 300-450%, GPU 25-30%
MJ: CPU 300-500%, GPU 85%

Note that the 8-bit GPU usage in Mojave is quite a bit higher than High Sierra...but the CPU usage doesn't really change.​

But then....

The previous issue is actually software issue. All I need to do is just reboot, and then I can play this Sony Swordsmith HDR video smoothly in Preview.

But once I close it and re-play it again, it become choppy. So, it's software issue, something is stuck and unable to provide hardware decoding. But not the CPU / or any other hardware is limiting.

So I went back to test further. Yes, indeed, it's a glitch, not a function of the 8-/10-bitness of the video or anything like that. It's definitely software. I didn't even need to reboot, as you said 'h'— quitting QuickTime Player and relaunching took care of it. But only for the first video loaded, even if it's not played. I will try to submit a bug report on that.

EDIT: You mentioned "Preview", which I assume you mean QuickLook. That's not as easy to reset (as QT Player) w/o rebooting, but if you Force Quit "QuickLookUIService (Finder)" in Activity Monitor, you can avoid having to reboot each time you want to test w/ QuickLook.

Also, still no acceleration of my 4K H.264 files. Surely the AMD UVD playback would accelerate those if it handles HEVC 4K, right?

Fred

 

[h9826790]

h982....(do you have an actual name we can call you? )...I posted this in the "official Mojave Mac Pro Metal GPU list" thread, but perhaps it's better discussed here? Pardon me and let me know if dual posting in this case is bad form:

Thomasthegps, how many of those sample videos did you test out for HEVC decoding? This (hardware decoding for 4K H.264/265) is what I've been dying for...it's the only thing that really hamstrings my Mac Pro for editing compared to my MacBook Pro, since no Quick Sync. I don't mind waiting for encoding to use CPU, but choppy playback is a killer.

Not sure if contrary to what Soy said above, but as of Mojave DP8, I'm only getting good results (GPU engaged and very little CPU) on 10-bit content, NOT 8-bit. But perhaps that's 10-bit Rec709? That camping video is 10-bit, as is the Bravia OLED glass-blowing video, and they play back w/ under 10% CPU usage on my 12-core 3.46GHz machine, at about 30% RX 580 GPU usage.

The others, such as Surfing and Aquarium, are 8-bit, and they utilize a LOT more overall: 300-500% CPU and around 85% GPU. This is the same as I see in High Sierra 10.13.6...well, HS actually uses less GPU. Also, a 4K H.264 test file of my own from my Lumix G85 shows no improvement that I can tell between HS & MJ. HEVC is welcome, of course, but for me, I'd rather have 4K H.264 decode before anything.

Thoughts? Below are my results.
Fred

HEVC Playback/Decode Tests
1. Bravia OLED 4K [73Mbps, 4k60, 10-bit]
10.13.6 HS: CPU 450-650%, GPU 40%
10.14 DP8 MJ: CPU <10%, GPU 30%

2. Surfing [77Mbps, 4k60, 8-bit]
HS: CPU 350-500%, GPU 25-30%
MJ: CPU 350-500%, GPU 85%

3. Aquarium [80Mbps, 4k60, 8-bit]
HS: CPU 300-450%, GPU 25-30%
MJ: CPU 300-500%, GPU 85%

Note that the 8-bit GPU usage in Mojave is quite a bit higher than High Sierra...but the CPU usage doesn't really change.​

But then....



So I went back to test further. Yes, indeed, it's a glitch, not a function of the 8-/10-bitness of the video or anything like that. It's definitely software. I didn't even need to reboot, as you said 'h'— quitting QuickTime Player and relaunching took care of it. But only for the first video loaded, even if it's not played. I will try to submit a bug report on that.

EDIT: You mentioned "Preview", which I assume you mean QuickLook. That's not as easy to reset (as QT Player) w/o rebooting, but if you Force Quit "QuickLookUIService (Finder)" in Activity Monitor, you can avoid having to reboot each time you want to test w/ QuickLook.

Also, still no acceleration of my 4K H.264 files. Surely the AMD UVD playback would accelerate those if it handles HEVC 4K, right?

Fred

Call me h98 is fine.

There are at least two version of Sony camping HEVC videos can be downloaded on the internet.

The first one is a 8bit BT709 HEVC video.

The second one is a 10bit BT2020 HEVC video.

Yeah, I mean QuickLook need reboot to play another high demanding HEVC video smoothly. I know we can restart that in terminal, but far from ideal for normal use. Anyway, I reported this bug to Apple already, already got some reply and working on it.

IINA (1.0.0-beta3) is pretty much the same, it can play one of those BT2020 video smoothly (QuickTime must be fully closed), then we need a complete re-start of IINA to play another one.

 

[CreeptoLoser]

Call me h98 is fine.

There are at least two version of Sony camping HEVC videos can be downloaded on the internet.

The first one is a 8bit BT709 HEVC video.
View attachment 777638

The second one is a 10bit BT2020 HEVC video.
View attachment 777639

Yeah, I mean QuickLook need reboot to play another high demanding HEVC video smoothly. I know we can restart that in terminal, but far from ideal for normal use. Anyway, I reported this bug to Apple already, already got some reply and working on it.

IINA (1.0.0-beta3) is pretty much the same, it can play one of those BT2020 video smoothly (QuickTime must be fully closed), then we need a complete re-start of IINA to play another one.

Thanks for further tests.

When iTunes will be able to play HDR videos on macOS then this will be useful.

 

[fhturner]

Yeah, I mean QuickLook need reboot to play another high demanding HEVC video smoothly. I know we can restart that in terminal, but far from ideal for normal use. Anyway, I reported this bug to Apple already, already got some reply and working on it.

Hey h98, any new info from Apple on this bug report? I just tried DP10 and see that it is still there. Also, I guess I should submit a "feature request" for H.264 decoding as well...or have you already mentioned that too?

 

[h9826790]

Hey h98, any new info from Apple on this bug report? I just tried DP10 and see that it is still there. Also, I guess I should submit a "feature request" for H.264 decoding as well...or have you already mentioned that too?

Just try PB9, the bug still there.

And no, for video decoding, I never mention the H264 issue in my bug report.

Also, just check the hardware encoding bug. Apple fixed the QuickTime Player's export error, but not the way we want. They rather fix the hardware encoding issue, but just put us back on software encoding.

 

[walexago]

Hi,

I followed this thread with much interest because I need to replace my IMac 27 mid-2011 and I would like to buy (or build) a 4k HDR Mojave machine.

I am waiting to Mojave's official release and some news about new iMac Pro but I'm also thinking to build an hackintosh: as hardware I would have chosen at the moment

CPU: i7 8700K
GPU: Vega64
Monitor: Dell UP2718Q (true 10 bit, HDR10, DP1.4)

These components, as far I know, are certainly able to play 4k HDR h264/h265 without problems (hardware decoding): maybe I will add also Windows (with bootcamp) to play UHD blu-ray discs.

I have some doubts about Mojave and 2k HD-4k HDR: hardware/software encode/decode of h264/h265 videos (also with iTunes), HDR support.

Based on the h98 test, I would say there should not be any problems but I would like to have your opinion.

Thanks

 

[h9826790]

Hi,

I followed this thread with much interest because I need to replace my IMac 27 mid-2011 and I would like to buy (or build) a 4k HDR Mojave machine.

I am waiting to Mojave's official release and some news about new iMac Pro but I'm also thinking to build an hackintosh: as hardware I would have chosen at the moment

CPU: i7 8700K
GPU: Vega64
Monitor: Dell UP2718Q (true 10 bit, HDR10, DP1.4)

These components, as far I know, are certainly able to play 4k HDR h264/h265 without problems (hardware decoding): maybe I will add also Windows (with bootcamp) to play UHD blu-ray discs.

I have some doubts about Mojave and 2k HD-4k HDR: hardware/software encode/decode of h264/h265 videos (also with iTunes), HDR support.

Based on the h98 test, I would say there should not be any problems but I would like to have your opinion.

Thanks

It should work, even though Apple now officially said they have no intention to support the Vega card on cMP (which means no support for standard PCIe Vega graphic cards), but we know it will work because of the iMac Pro. However, you can still expect fan issues etc.

 

[SoyCapitanSoyCapitan]

It should work, even though Apple now officially said they have no intention to support the Vega card on cMP (which means no support for standard PCIe Vega graphic cards), but we know it will work because of the iMac Pro. However, you can still expect fan issues etc.

The fan issues in cMP is because off the shelf graphic cards can’t talk to the cMP’s SMC properly. In a Hackintosh that shouldn’t be a problem.

I don’t support Hackintosh use though.