HandBrake

No, the nightly will not auto-update to the next nightly nor release.

No.

This hasn't been supported for over a decade now, so it's moot here.

They're more beta than alpha. Usually.

What if you try a software encoder like x265, and use software decoding (in preferences).

https://github.com/HandBrake/HandBrake/ ... S.markdown has the libraries

https://github.com/HandBrake/HandBrake/ ... er/contrib the module.defs for each library has the versions

You'll need to look at each for their license.

No... HB doesn't rip or author DVDs.

sturmtruppen wrote: ↑Mon Sep 09, 2024 10:08 amok, maybe you can advise me on which processor would be best suited for this motherboard (X570 Phantom Gaming 4 with 32GB RAM and 1GB M.2 NVMe HD system).

5900X or 5950X would be ideal; may need a firmware update for support.

High latency, low bandwidth storage ain't gonna be fast scanning all those videos.

4K content + 6 year old CPU + compute-intensive modern codec + unnecessary filtering... ain't gonna be fast.

I'd drop the unnecessary filtering and use preset veryfast for a bit of a speedup. Beyond that, you need a better CPU.

Mostly standing on the shoulders of giants, the video encoders themselves, plus lavc/lavf to support so many input options.

sturmtruppen wrote: ↑Sat Sep 07, 2024 5:25 am

rollin_eng wrote: ↑Fri Sep 06, 2024 6:17 pm Why are you converting the video if you want it the same size?

Thanks for your reply.
I don't want each video at its original size, but I want each video to be around 4.5GB

Is each video the same length?

sturmtruppen wrote: ↑Fri Sep 06, 2024 11:51 amHI,
sorry but I am not an expert in this program, I would like to ask you 2 questions:
- How to always obtain the same size when converting each file?
- How to reduce the color intensity of converted files?

Always use the same bitrate for the same file length.

Use the grayscale filter.

HB isn't for ripping disks, use MakeMKV for that.

Besides isn't it a programmer's pleasure to have some challenge to improve his creation? I believe the passthru options for subtitles should be there and it would be welcomed by the users. Not in ways arbitrarily demanded by users. Feel free to submit a patch, along with a commitment for ongoing ma...

Code: Select all

[12:22:43]        + source: 384 * 272, crop (0/0/0/0): 384 * 272, scale: 1536 * 1088

Good luck with that.

Why are you trying to encode from 47660 kb/s to 15 kb/s? A more reasonable target bitrate (1500? 15000?), or a target quality, should get you a result.

No.

I don't know the answer, but in general there's no point to using multi-pass with a hardware encoder, they're intended for single pass/realtime.

RF is unique to certain encoders, and regardless isn’t the same scale between encoders or settings.

I'd start with the H.265 QSV 1080p60 preset and adjust from there to suit your size/quality preferences.

Easier to support one subtitle processing pipeline than two. A lot less user and developer concern about subs than audio.

Woodstock wrote: ↑Fri Aug 23, 2024 3:28 pmBut handbrake is going to convert them to a compatible format for the container you specify, as mduell says.

SRT is compatible with MKV, but HB converts everything to SSA to have a common subtitle processing pipeline.

No, it will always be converted to timed text or SSA, depending on your output container.

Checkout the tag for the desired stable release and compile away.

For the HB presets, each one is optimized for what's described (a device/ecosystem, resolution, etc).

For the SVT-AV1 presets, they're documented at https://gitlab.com/AOMediaCodec/SVT-AV1 ... presets-do