Encoding with Handbrake 2017 iMac?

[FredT2]

Yes, I can only encode those options...MKV container will add a few more for you, but h.265 is the best bang for your buck.

Edit: also, it looks like you didn't select the profile after you selected the video. Could you double check that?

In the Handbrake docs it states that there will be an "H.264 (Intel QuickSync)" encode option if QuickSync is available. I did select your preset and was careful to make sure the settings were as you specified.

Have you run the H.264 encode on your machine?
[doublepost=1515518788][/doublepost]

You can always encode with H264. One of the main benefits with H265 is file size for the quality. It's close to half the file size of a comparable quality H264 which adds up if you have a lot of videos.
[doublepost=1515510221][/doublepost]
Was that using H264 or h265? My 2017 iMac wasn't able to process that test as fast so I'm curious if you did something wrong with the settings he suggested.

2017 iMac i7, 40gb ram, Radeon 575 4gb card: encoded 7110 frames in 2371.22s (3.00 fps), 36972.98 kb/s, Avg QP:21.15 (using public version)

2017 iMac i7, 40gb ram, Radeon 580 8gb card: encoded 7110 frames in 2276.09s (3.12 fps) (using the nightly build)

That was using H.265. I also did a run using H.264, and that ran much faster, 18.75 fps. I checked very carefully to see that my settings matched what Trebuin specified. This is very strange. Have you tried running H.264?

Thinking about this some more, logically there is no way that the iMac Pro should be running this encode more than 7 times faster than your 2017 i7s. And it goes without saying that they should be faster than my 2014. At the same time, it seems reasonable to me that the iMac Pro is 3 times faster than mine. So, I think there must be something off in your settings.

Just to be sure, I reran the H.265 encode one more time and got the same result.

 

[diamond3]

Hello, Download handbrake (I'm using 1.0.7 (2017040900)) & set it up like this:
1) download the test file: http://4kmedia.org/samsung-sensational-picture-uhd-4k-demo/
(this is a 4k video good enough to transcode to 1080p or 4k for this test purpose)
2) download & import the profile I attached, this will get most of the work done, select the profile after you import the video
3) FPS should be same as source (it's a 60fps video, but leave it same as source)
4) verify Variable Framerate
5) verify tune is set to grain
6) verify video is set to H.265 (x265)
7) verify quality set to constant quality RF 24
8) switch to the picture tab & adjust the storage size to 1920 x 1080 (I'm only testing 1080 for now)
9) all the rest of the settings should not need any changes (everything should have been good on the file I uploaded.

after the encode is done, select "window" dropdown & select "activity window"
Mine showed this:
encoded 7110 frames in 306.44s (23.20 fps), 6026.97 kb/s, Avg QP:32.44

This is actually slightly different than the directions you sent me. You mentioned an RF of 20 vs the 24. Which did you use? I'm assuming FredT2 used the 20.

 

[FredT2]

This is actually slightly different than the directions you sent me. You mentioned an RF of 20 vs the 24. Which did you use? I'm assuming FredT2 used the 20.

No, I used 24, and that's probably the difference. 20 is higher quality and so should take longer. Rerun with 24 and see what you get.

 

[diamond3]

No, I used 24, and that's probably the difference. 20 is higher quality and so should take longer. Rerun with 24 and see what you get.

Here's my settings. I'm using his preset. I'll run the test again, but it's not looking like it's anywhere near the speed you're getting. You don't have your preset changed from medium or fast encode?

 

[joema2]

In the Handbrake docs it states that there will be an "H.264 (Intel QuickSync)" encode option if QuickSync is available. I did select your preset and was careful to make sure the settings were as you specified...

I'm not sure Quick Sync is available in current "already built" Handbrake binaries for Mac. Handbrake is open source, so it's possible to get the source code, set up a build environment and compile and link your own version of Handbrake. There is apparently a special source tree that calls the appropriate APIs, but it hasn't been officially tested:

https://github.com/HandBrake/HandBrake/issues/1060

The normal way to access Quick Sync (on Windows or Linux) is using Intel's Media SDK, which contains Intel's libmfx library that apps call for encode/decode operations: https://software.intel.com/en-us/me...fst1Hb7xr0iiMU_ooyEaAnPxEALw_wcB&gclsrc=aw.ds

It appears that is not available on macOS so Mac apps wishing to perform these functions must call Apple's VideoToolBox framework: https://developer.apple.com/documentation/videotoolbox

This might help explain why some apps that use Quick Sync on Windows do not use it on macOS. However FCPX has had no problem using Quick Sync for years, and it produces extremely high quality output that I personally cannot distinguish from pure software encoding.

The fact there's even a test version of Handbrake source code which uses Quick Sync on macOS shows it has always been possible. Handbrake is developed by volunteers working for free in their spare time. The niche editing software Edius has used Quick Sync on Windows for H264 encoding since 2011. There's no good explanation why a highly-paid software developer at a big commercial company like Adobe cannot figure out how to do this.

Adobe Premiere Pro has not used Quick Sync on Windows (much mess macOS) since it was made available in 2011 with Intel's Sandy Bridge CPU. I think maybe Premiere on Windows may have recently started using Quick Sync in some cases, but I'm not sure.

Utilities like Handbrake and VLC will not use Quick Sync unless the developers write the necessary code -- whether that be on Windows or macOS. The API and software framework for doing this on macOS is different from Windows, so they can't just copy/paste their source code and compile it, they have to do actual work.

Even given the correct coding methods, the hardware must also support it. All PCs and Macs since 2011 using Sandy Bridge or later have had the hardware capability. Whether the iMac Pro has this is unknown, in general Xeon does not have Quick Sync but the iMP is obviously using some kind of hardware acceleration, possibly AMD's UVD/VCE. Handbrake, Premiere or any other app could also use this if developers wrote the necessary code. The nVidia equivalent is NVDEC and NVENC.

UVD: https://en.wikipedia.org/wiki/Unified_Video_Decoder
VCE: https://en.wikipedia.org/wiki/Video_Coding_Engine

 

[FredT2]

Here's my settings. I'm using his preset. I'll run the test again, but it's not looking like it's anywhere near the speed you're getting. You don't have your preset changed from medium or fast encode?

My settings are exactly as you show.

This is crazy. I reran at quality=20 in 7.3 fps. One of us has something set wrong.

 

[Trebuin]

This is actually slightly different than the directions you sent me. You mentioned an RF of 20 vs the 24. Which did you use? I'm assuming FredT2 used the 20.

Sorry about that, I did adjust the RF so you should have higher numbers. RF 24 & adjusting to 1080 is going to be about the worst case real world info. It should give higher numbers and if the 2017 imac gets any advantage through 1080 encoding, it should help increase the numbers.
[doublepost=1515523204][/doublepost]

In the Handbrake docs it states that there will be an "H.264 (Intel QuickSync)" encode option if QuickSync is available. I did select your preset and was careful to make sure the settings were as you specified.

Have you run the H.264 encode on your machine?
[doublepost=1515518788][/doublepost]
That was using H.265. I also did a run using H.264, and that ran much faster, 18.75 fps. I checked very carefully to see that my settings matched what Trebuin specified. This is very strange. Have you tried running H.264?

Thinking about this some more, logically there is no way that the iMac Pro should be running this encode more than 7 times faster than your 2017 i7s. And it goes without saying that they should be faster than my 2014. At the same time, it seems reasonable to me that the iMac Pro is 3 times faster than mine. So, I think there must be something off in your settings.

Just to be sure, I reran the H.265 encode one more time and got the same result.

I can run a H.264 encode tonight. H.264 should encode faster than 265. Either QS version should also help out more.

 

[diamond3]

Just so we are on the same page..

Hello, Download handbrake (I'm using 1.0.7 (2017040900)) & set it up like this:
1) download the test file: http://4kmedia.org/samsung-sensational-picture-uhd-4k-demo/
2) download & import the profile I attached, this will get most of the work done, select the profile after you import the video
3) FPS should be same as source (it's a 60fps video, but leave it same as source)
4) verify Variable Framerate
5) verify tune is set to grain
6) verify video is set to H.265 (x265)
7) verify quality set to constant quality RF 24
8) switch to the picture tab & adjust the storage size to 1920 x 1080 (I'm only testing 1080 for now)
9) all the rest of the settings should not need any changes (everything should have been good on the file I uploaded.

I was converting to 4k H265 using the other instructions I got. So, I'll test all of the settings above with both h265 and the h264 at the 1080 resolution and list the encoding stats. I'm guessing my numbers will improve to the 10-12 fps range given that it's a quarter of the pixels. I'll report back.

 

[Trebuin]

Just so we are on the same page..

Hello, Download handbrake (I'm using 1.0.7 (2017040900)) & set it up like this:
1) download the test file: http://4kmedia.org/samsung-sensational-picture-uhd-4k-demo/
2) download & import the profile I attached, this will get most of the work done, select the profile after you import the video
3) FPS should be same as source (it's a 60fps video, but leave it same as source)
4) verify Variable Framerate
5) verify tune is set to grain
6) verify video is set to H.265 (x265)
7) verify quality set to constant quality RF 24
8) switch to the picture tab & adjust the storage size to 1920 x 1080 (I'm only testing 1080 for now)
9) all the rest of the settings should not need any changes (everything should have been good on the file I uploaded.

I was converting to 4k H265 using the other instructions I got. So, I'll test all of the settings above with both h265 and the h264 at the 1080 resolution and list the encoding stats. I'm guessing my numbers will improve to the 10-12 fps range given that it's a quarter of the pixels. I'll report back.

Thanks for this...I just realized I was not set to grain on this test...That will speed up my results, I need to test again and repost my numbers.

Corrected numbers:
encoded 7110 frames in 443.10s (16.05 fps), 8496.98 kb/s, Avg QP:26.01


I haven't looked it up yet, but I think the Avg QP is the quality match, it matches other peoples tests where the speed does not match.

 

[FredT2]

Thanks for this...I just realized I was not set to grain on this test...That will speed up my results, I need to test again and repost my numbers.

Corrected numbers:
encoded 7110 frames in 443.10s (16.05 fps), 8496.98 kb/s, Avg QP:26.01


I haven't looked it up yet, but I think the Avg QP is the quality match, it matches other peoples tests where the speed does not match.

Bummer. 3X my iMac seemed like such a nice number. Oh well, 2X is still good. How about H.264?

 

[diamond3]

2017 iMac 4gb GFX: encoded 7110 frames in 763.99s (9.31 fps), 8996.07 kb/s, Avg QP:26.01

 

[pl1984]

2017 iMac 4gb GFX: encoded 7110 frames in 763.99s (9.31 fps), 8996.07 kb/s, Avg QP:26.01

Thought I would give this a go. HP Z620, dual 8 core (32 threads), 2.93GHz, 64GB RAM, Z-Turbo drive, Ubuntu Linux 16.04 LTS, Handbrake 0.10.2: encoded 7110 frames in 168.26s (42.26 fps), 5629.57 kb/s, Avg QP:32.52

 

[diamond3]

Thought I would give this a go. HP Z620, dual 8 core (32 threads), 2.93GHz, 64GB RAM, Z-Turbo drive, Ubuntu Linux 16.04 LTS, Handbrake 0.10.2: encoded 7110 frames in 168.26s (42.26 fps), 5629.57 kb/s, Avg QP:32.52

Something must be different with the settings since the Avg QP not in the same area as the mine or Trebuin (26.01)

 

[pl1984]

Something must be different with the settings since the Avg QP not in the same area as the mine or Trebuin (26.01)

I was unable to load the profile provided. Perhaps that may explain the difference? I'll try it on my Mac Pro which can use the latest version of Handbrake.

 

[Trebuin]

Bummer. 3X my iMac seemed like such a nice number. Oh well, 2X is still good. How about H.264?

Looks like the output for x264 is a bit different, but I got this in the completion time:
[18:05:29] work: average encoding speed for job is 36.770073 fps
[doublepost=1515550278][/doublepost]

I was unable to load the profile provided. Perhaps that may explain the difference? I'll try it on my Mac Pro which can use the latest version of Handbrake.

you can build it using the photos attached to this post:

 

[pl1984]

Here is the Z620 system again with the adjustments for the profile:

encoded 7110 frames in 215.95s (32.92 fps), 12446.01 kb/s, Avg QP:28.42

Does this seem more appropriate?

EDIT: 2013 Mac Pro, 3.5GHz hexa-core, 16GB RAM: High Sierra, Handbrake 1.0.7:

encoded 7110 frames in 728.10s (9.77 fps), 8466.47 kb/s, Avg QP:26.42

 

[FredT2]

Looks like the output for x264 is a bit different, but I got this in the completion time:
[18:05:29] work: average encoding speed for job is 36.770073 fps

Thanks. That's consistent with the H.265 result, about twice as fast as the 2014 iMac.

 

[Trebuin]

Here is the Z620 system again with the adjustments for the profile:

encoded 7110 frames in 215.95s (32.92 fps), 12446.01 kb/s, Avg QP:28.42

Does this seem more appropriate?

EDIT: 2013 Mac Pro, 3.5GHz hexa-core, 16GB RAM: High Sierra, Handbrake 1.0.7:

encoded 7110 frames in 728.10s (9.77 fps), 8466.47 kb/s, Avg QP:26.42

The second one seems much closer. Double check you have the same version of Handbrake.

 

[Traverse]

I’ve been using Handbrake on my iMac 2017 4.2 GHz for the first time for hours a day for last two weeks.

Some days all day and others for a few hours I’ve been importing my older media collection that cannot be purchased. It pushes all cores to their max and the fan to its. But I’ve had no issues. Doesn’t get hot to touch, just warm. Still runs fine as I’m using a virtual machine at the same time along with Safari, iTunes, etc. No slowdowns which impressed me.

I’m sure running on max constantly would shorten its life, but theoretically they’re built to withstand certain conditions. These are well within its tolerance or it would shut itself done.

TLDR: You’re good.

 

[pl1984]

The second one seems much closer. Double check you have the same version of Handbrake.

It's not the same version. It's an older version (exact version was given in an earlier post)

 

[Trebuin]

It's not the same version. It's an older version (exact version was given in an earlier post)

Ok, that should account for the issues importing & the difference in the quality value.

 

[pl1984]

Ok, that should account for the issues importing & the difference in the quality value.

I suspect it is. It's definitely with the inability to import the profile. The older version doesn't read the JSON format. I may install a later version (they have 1.0.4 available as a pre-compiled binary) but I'm unsure if I want to go to that effort given I did this just...because.

 

[Robotronic]

Hello, Download handbrake (I'm using 1.0.7 (2017040900)) & set it up like this:
1) download the test file: http://4kmedia.org/samsung-sensational-picture-uhd-4k-demo/
(this is a 4k video good enough to transcode to 1080p or 4k for this test purpose)
2) download & import the profile I attached, this will get most of the work done, select the profile after you import the video
3) FPS should be same as source (it's a 60fps video, but leave it same as source)
4) verify Variable Framerate
5) verify tune is set to grain
6) verify video is set to H.265 (x265)
7) verify quality set to constant quality RF 24
8) switch to the picture tab & adjust the storage size to 1920 x 1080 (I'm only testing 1080 for now)
9) all the rest of the settings should not need any changes (everything should have been good on the file I uploaded.

after the encode is done, select "window" dropdown & select "activity window"
Mine showed this:
encoded 7110 frames in 306.44s (23.20 fps), 6026.97 kb/s, Avg QP:32.44

Edit (I did not set to grain and the numbers above are incorrect):

Corrected numbers:
encoded 7110 frames in 443.10s (16.05 fps), 8496.98 kb/s, Avg QP:26.01

Would you mind sharing where you came up with these settings for x265 encoding with Handbrake? I've been researching over the last few days, and there doesn't seem to be a generally accepted ideal preset for x265 yet.

Point of reference - on my base model iMac Pro I got nearly identical results as yours:

encoded 7110 frames in 428.12s (16.61 fps), 8996.07 kb/s, Avg QP:26.01

 

[FredT2]

Anyone with a 10-core iMac Pro want to run this test?

 

[Trebuin]

Would you mind sharing where you came up with these settings for x265 encoding with Handbrake? I've been researching over the last few days, and there doesn't seem to be a generally accepted ideal preset for x265 yet.

Point of reference - on my base model iMac Pro I got nearly identical results as yours:

encoded 7110 frames in 428.12s (16.61 fps), 8996.07 kb/s, Avg QP:26.01

I've been encoding for a very long time so I have been able to tune this to what I like. Basically, H264 & & 265 difference in the file size output for the same quality. Tuning to grain gives you higher quality by focusing on film grain...probably not any different than selecting a higher quality itself. I haven't tested the film grain that completely yet, but I do know it increases the file size. Variable Framerate/same as source will give you the fastest framerate which should make the movie look original. Constant quality vs avg birate is your meat & potatoes. Average bitrate gives you a predictable size, but it requires 2-pass to make sure you meet higher qualities. Constant Quality will balance the film in another way. The RF defines the quality, but doesn't translate between video qualities. I'm using the following as references:
480-576p: 18-22
720p: 19-23
1080p: 20-26
2160p: 22-28
These are rough matching translations between resolutions. I used to use average bitrate & shrink the video down to 780p, but the RF quality tends to do a better job at keeping the quality higher overall. The bottom side of those numbers tends to be where the human eye should not notice a difference when played for entertainment vs the original film. A lot of this is just trial & error. I used to use the Disney intro & look at the windows & shingles of the castle to verify differences in settings. Just think about this & the advanced settings. With 265, I can accept larger files due to the lower bitrate required.