HandBrake taking 76 hours to encode REMUX to x265

HandBrake for Mac support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Post Reply
carrotferret
Posts: 14
Joined: Sat Apr 10, 2021 5:30 am

HandBrake taking 76 hours to encode REMUX to x265

Post by carrotferret »

Description of problem or question:

I'm a complete noobie to using HandBrake.

HandBrake is taking over 3 days (more than 72 hours) to encode a REMUX mkv file to x265.

The computer used is an mid-2017 iMac Kaby Lake i5-7600K @ 3.8 GHz, with 16 GB RAM & 1 TB SSD.

I created the REMUX mkv file from a complete Blu-ray BDMV folder using MakeMKV software. The REMUX file is 19 GB.


Steps to reproduce the problem (If Applicable):




HandBrake version (e.g., 1.0.0):

HandBrake 1.3.3


Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):

macOS Mojave 10.14.6


HandBrake Activity Log ***required*** (see How-to get an activity log)

Code: Select all

https://pastebin.com/0DKWm3Zd
This is my first time creating a REMUX mkv file, and also encoding it into x265, so I'm very sure it's not my computer; it's definitely an obvious setting or step I did wrong, lol. I know the process should only take a few hours using the default SuperHQ 1080p30 MKV setting. It's showing an average FPS time of 0.47 fps, ETA 76:20:39 after 17.5% completed.

Appreciate if I could get some help. Many thanks in advance. :)
User avatar
Ritsuka
HandBrake Team
Posts: 1251
Joined: Fri Jan 12, 2007 11:29 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by Ritsuka »

You set x265 to "very slow", there is a reason for that name.
carrotferret
Posts: 14
Joined: Sat Apr 10, 2021 5:30 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by carrotferret »

Ritsuka wrote: Mon Apr 19, 2021 7:18 am You set x265 to "very slow", there is a reason for that name.
Yes, I do understand that the "very slow" setting will take a lot of time. However, I see many say that it will take many, many hours, but not days. Is it because they have a very fast computer, like way faster than mine?

Also, am I'm definitely just doing a regular encode, and not transcoding? I understand transcoding is pointless and takes way lot more time energy.
Woodstock
Veteran User
Posts: 4105
Joined: Tue Aug 27, 2013 6:39 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by Woodstock »

[15:53:09] CPU: Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz
[15:53:09] - Intel microarchitecture Kaby Lake
[15:53:09] - logical processor count: 4
It isn't that difficult to have a computer "like way faster than mine?"

x265 can take advantage of double and triple the number of cores you have.

Given that, unless you're encoding for distribution via the web, you shouldn't be making use of x265 on "just" 1080p content. And if you don't need to recode it (your source is already HEVC), something that can "just" remux it into a new container would be more appropriate.
Deleted User 13735

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by Deleted User 13735 »

With your combination of CPU and settings, that is not an eyebrow-raiser.
There is no reason to encode 10 bit except to take lots up of time. Your source is 8 bit...
RF 18 is overkill IMO.
VerySlow is overkill IMO.
x265 for BD is time-wasting compression IMO.

Try the HQ 1080 p30 preset and compare times. Also consider a spiffier CPU.
carrotferret
Posts: 14
Joined: Sat Apr 10, 2021 5:30 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by carrotferret »

Woodstock wrote: Mon Apr 19, 2021 12:24 pm
[15:53:09] CPU: Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz
[15:53:09] - Intel microarchitecture Kaby Lake
[15:53:09] - logical processor count: 4
It isn't that difficult to have a computer "like way faster than mine?"

x265 can take advantage of double and triple the number of cores you have.

Given that, unless you're encoding for distribution via the web, you shouldn't be making use of x265 on "just" 1080p content. And if you don't need to recode it (your source is already HEVC), something that can "just" remux it into a new container would be more appropriate.
Haha, yes, you're right. :lol: I guess I'm ignorant/naive and just being hopeful, that computer was still good enough to achieve those times closer to hours I see others quoting, rather than days. Now, I know after giving it a run for the first time.

I see, I think, I read some where it scales okay until like 8 cores, then not so much more after that? Is that correct? Or does the new builds can take advantage of more than that? Perhaps I should look into getting a new system with more cores/faster CPU....

Yeah, I think I'll consider doing a x264 instead. It's really for myself.
carrotferret
Posts: 14
Joined: Sat Apr 10, 2021 5:30 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by carrotferret »

musicvid wrote: Mon Apr 19, 2021 12:36 pm With your combination of CPU and settings, that is not an eyebrow-raiser.
There is no reason to encode 10 bit except to take lots up of time. Your source is 8 bit...
RF 18 is overkill IMO.
VerySlow is overkill IMO.
x265 for BD is time-wasting compression IMO.

Try the HQ 1080 p30 preset and compare times. Also consider a spiffier CPU.
Haha, ok ok, got it. :lol:

I'll do the HQ 1080p30 preset.

Time to look into a new system seriously. Had been putting it off a long time, because of the chip shortages for both CPU & GPU, hoping prices would come down. :P
Woodstock
Veteran User
Posts: 4105
Joined: Tue Aug 27, 2013 6:39 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by Woodstock »

Just remember that encoding is not a task that needs a lot of user interaction, after things are set up, so if you're targeting an "encoding machine", you do not have to limit yourself to Apple hardware.

The encoding capabilities of handbrake are the same, regardless of the operating system. A very capable encoding machine can be built for under 1K USD, even if you chose Intel instead of AMD for the processor.
carrotferret
Posts: 14
Joined: Sat Apr 10, 2021 5:30 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by carrotferret »

Woodstock wrote: Mon Apr 19, 2021 1:25 pm Just remember that encoding is not a task that needs a lot of user interaction, after things are set up, so if you're targeting an "encoding machine", you do not have to limit yourself to Apple hardware.

The encoding capabilities of handbrake are the same, regardless of the operating system. A very capable encoding machine can be built for under 1K USD, even if you chose Intel instead of AMD for the processor.
Yeah, you're right. Especially since my new machine will be used more like an encoding machine, left alone to crunch away, as my main computer is a Mac. Probably use it as future PleX server as well. I will look into Intel based system, as I do like the Quick Sync feature. Thanks!
mduell
Veteran User
Posts: 7438
Joined: Sat Apr 21, 2007 8:54 pm

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by mduell »

Don't bother with x265 for high quality HD encodes; x264 is way faster.

x265 shines at large frame sizes (4K+) or very low bitrates (low to medium quality); otherwise you don't get much for the speed hit.
Woodstock
Veteran User
Posts: 4105
Joined: Tue Aug 27, 2013 6:39 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by Woodstock »

For your proposed new machine - don't skimp on the CPU or case cooling. Get the heat away from the chips.

Apple spends a LOT of time designing the heat rejection in their tightly-enclosed machines, as do other major manufacturers, but a "mini tower" case has lots of room for big heat sinks and fans to do the same thing.

A lot of motherboards will slow the CPU down if you get anywhere near the temperature limits, and encoding can do that.
carrotferret
Posts: 14
Joined: Sat Apr 10, 2021 5:30 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by carrotferret »

Woodstock wrote: Mon Apr 19, 2021 5:48 pm For your proposed new machine - don't skimp on the CPU or case cooling. Get the heat away from the chips.

Apple spends a LOT of time designing the heat rejection in their tightly-enclosed machines, as do other major manufacturers, but a "mini tower" case has lots of room for big heat sinks and fans to do the same thing.

A lot of motherboards will slow the CPU down if you get anywhere near the temperature limits, and encoding can do that.
Yeah, been reading reviews yesterday seeing if I would go for the AMD / Intel route, and also if I'd opt for 8, 10 or 12 core CPU between generations. AMD CPUs where I am in Asia seem to be priced higher than Intel's (I assume that's a global trend due to low stocks it seems). Considering the lower TDP CPU's too, which don't overheat as much.

Will need to get good cooling solution & motherboard too as you said, may throttle the CPU. I'm near the equator, so it's basically hot and humid every day, lol. Also, the air-conditioning may not be turned on 24/7. :lol:

mduell wrote: Mon Apr 19, 2021 4:20 pm Don't bother with x265 for high quality HD encodes; x264 is way faster.

x265 shines at large frame sizes (4K+) or very low bitrates (low to medium quality); otherwise you don't get much for the speed hit.
So I completed the encode with x264 yesterday, and it took 2 hours 15 mins on my iMac, instead of the 4 days before, lol. :lol:

However, I'm slightly concerned that the file size produced is 4.8 GB from 19 GB. I mean, I'm happy it's much smaller, but I didn't expect it to shrink so much, so concerned about quality loss during the process. I use the default H.264 HQ 1080p30 preset. Audio is AC-3 5.1 passthrough. The video bit rate is 5233 kbps. I was expecting around the half-size mark.

Is this normal?
Woodstock
Veteran User
Posts: 4105
Joined: Tue Aug 27, 2013 6:39 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by Woodstock »

On anime, x264 can shrink Bluray data by 85% or more at an RF value of 20, because it is very compressible. A high-motion, high-detail action film at that same RF... Not so much, more like 50%.

Lossy compression always creates some artifacts. People authoring disks usually seem to use a compression level that "just" lets them fit the feature on a disk, to minimize artifacts. Choosing how much compression to use for most of us comes down to "how many artifacts are you willing to tolerate?"
carrotferret
Posts: 14
Joined: Sat Apr 10, 2021 5:30 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by carrotferret »

I see. I'll have to compare how it looks, or rather, if there any obvious increase in artifacts, the remux file with my encode on my bigger display. Thanks!
mduell
Veteran User
Posts: 7438
Joined: Sat Apr 21, 2007 8:54 pm

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by mduell »

carrotferret wrote: Wed Apr 21, 2021 8:48 amHowever, I'm slightly concerned that the file size produced is 4.8 GB from 19 GB. I mean, I'm happy it's much smaller, but I didn't expect it to shrink so much, so concerned about quality loss during the process. I use the default H.264 HQ 1080p30 preset. Audio is AC-3 5.1 passthrough. The video bit rate is 5233 kbps. I was expecting around the half-size mark.
Have you looked at the result? Is there anything wrong to your eye?
carrotferret
Posts: 14
Joined: Sat Apr 10, 2021 5:30 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by carrotferret »

So, I tried direct playing both files on PleX on my 46" Sony 1080p LCD via Google Chomecast; unfortunately; I wasn't able to make a proper comparison as my PleX Dashboard was showing my server was transcoding it, so images definitely looked a lot worse than on my Mac.

I ended up having to take screenshots down to the second/frame and made comparisons that way. I don't have a proper set-up like what photographers have for side-by-side comparisons, so it was all done with my untrained eye. I zoomed the images just once, and moved really close up to the screen.

In fine details (like in the face), and front main subjects, I could not see any differences between the REMUX and encoded x264 file. However, there were, really very subtle loss of grain or smoother backgrounds, and that's only if I go really close up and look for them. But when I move back at proper viewing distance, I don't see it at all.

Overall, I'm really happy with the results. For the time and space saved, I would continue using the same settings.

Thanks for all for the help. :)
mduell
Veteran User
Posts: 7438
Joined: Sat Apr 21, 2007 8:54 pm

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by mduell »

carrotferret wrote: Thu Apr 22, 2021 3:07 pmI ended up having to take screenshots down to the second/frame and made comparisons that way. I don't have a proper set-up like what photographers have for side-by-side comparisons, so it was all done with my untrained eye. I zoomed the images just once, and moved really close up to the screen.
This is useless, actually worse than useless, unless you enjoy watching movies that way.
Deleted User 13735

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by Deleted User 13735 »

Oh, the trials and tribulations of entertainment!
carrotferret
Posts: 14
Joined: Sat Apr 10, 2021 5:30 am

Re: HandBrake taking 76 hours to encode REMUX to x265

Post by carrotferret »

mduell wrote: Thu Apr 22, 2021 4:35 pm
carrotferret wrote: Thu Apr 22, 2021 3:07 pmI ended up having to take screenshots down to the second/frame and made comparisons that way. I don't have a proper set-up like what photographers have for side-by-side comparisons, so it was all done with my untrained eye. I zoomed the images just once, and moved really close up to the screen.
This is useless, actually worse than useless, unless you enjoy watching movies that way.
No, I mean, I was just doing that comparison process once to see if my encode was good enough that I don't see any difference compared to the remux. So, moving forward, I know what to expect with the HandBrake settings I used, and probably just end up using that for all future encodes. I won't be doing that whole side-by-side comparison process any more. Since that was my first x264 encode, I will think, okay, the quality is near identical, the size is like this for this kind of movie, and will take this long. I'll just the encode, and go away, and then come back and watch the film. :)
Post Reply