HandBrake

Multitasking wouldn't be a HB issue, that would be a macOS scheduler issue. HB only uses the resources the OS allocates.

We'd need to see logs from before and after to explain why it's slower now; probably different settings than he used previously.

That's not 30 fps, but you could try without low power hardware encoding enabled in settings.

For issues with a specific encode, the encode log needs to be provided; see the text in the red box in the support forum for more details.

You want SubRip, not HandBrake.

For editing, the Production Standard (or Production Max) preset is recommended.

Your first two questions are unanswerable not knowing anything about the content.

For your third question, just reduce the quality of the Production Standard preset by increasing the RF a few points.

Code: Select all

[12:14:44] scan: 10 previews, 720x576, 25.000 fps, autocrop = 74/74/0/0, aspect 16:9, PAR 64:45, color profile: 5-1-6, chroma location: left

Black bars were found for 74 pixels top and bottom, and are cropped off by detault; 576 - 2*74 = 428.

As a general answer to a general question, it could be.

Your system management controller should be handling fan speeds, not a random application.

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.

What are "matroska subtitles"? Matroska is a container that supports a variety of subtitle formats, but it is not a subtitle format.

What if you do passthrough on the audio track instead of pointlessly reencoding it at a higher bitrate?

Best you can do with HB is pick an unreasonbly high quality setting (e.g. RF 1) then cap the bitrate with vbv-bufsize/vbv-maxrate.

rollin_eng wrote: ↑Thu Jan 11, 2024 1:12 pm https://handbrake.fr/docs/en/1.7.0/tech ... s-abr.html

CBR/constant bitrate does not appear anywhere on that page.

Flake198 wrote: ↑Mon Jan 08, 2024 3:17 pm

mduell wrote: ↑Mon Jan 08, 2024 2:40 pm No, due to duration uncertainty, can't meet user's expectations for accuracy without decoding the entire source first.

Why does DVDFab implement this? You set the file size and the bitrate is automatically adjusted.

Less picky users? Decoding the entire video first?

rect=1 (the default) is used when the options are empty, do I understand this correctly? Yes. Is there a good overview or guide? https://x265.readthedocs.io/en/stable/cli.html My conclusion is that H.265 10-bit, without options, takes about twice as much time as H.265, but the output file is smalle...

No, due to duration uncertainty, can't meet user's expectations for accuracy without decoding the entire source first.

Eh, I'd keep at least rect=0; rect=1 (the default) is excessively slow for what it gains.

You've specified additional options on your 10-bit encode that improve the speed of the encode at the cost of compression: [18:32:52] + encoder: H.265 (libx265) [18:32:52] + preset: veryslow [18:32:52] + profile: auto [18:32:52] + level: auto [18:32:52] + quality: 18.00 (RF) [18:30:32] + encoder: H....

Post an encoding log from before with the previous behavior, and now with the new behavior, so we can see what differences may have lead to your observation.

The preset you're using would be a very reasonable. Not sure what you've been encoding from previously if not disk rips.

Ok byeeee

Since it's just distorted, some players like VLC can fix the aspect ratio.

For 4K with a lot of grain, I'd use SVT-AV1 10-bit as long as it's not DV.

If you have to use x265, I'd use encoder tune grain and a higher RF. Or use a lot stronger nlmeans strength.

Either way, disable decomb/deinterlace.

We'd need to see the encode log, not just the scan.

Also you've posted conflicting information about if constant frame rate has the problem or not.

Yes, H.265 with VTB will be better than H.264 with VTB at the same bitrate.

If you want 4-5GB for a 2h movie, you need a video bitrate around 5000 kbps not 20000 kbps.

Size, speed, quality: pick two.