HandBrake

Encoding speed will slow down if you encode higher resolution material. The original test was with DVD-Video 720x480 size.

What are you using to play it back? If you are using a different program, then it's normal. Color management is hard and many players get it wrong, or slightly different, because they ignore the display color profile, or because there is no standardised way to tone map HDR (but this isn't you case)....

PGS subtitles can't be muxed in a mp4 file, so they can only be burned-in.

HDR10 is supported on almost every encoder since two years ago.
HDR10+ on svt-av1 and x265 10-bit, and Dolby Vision on x265 10-bit, but only in the snapshots until the next major release.

And make sure you are not using unofficial versions. Repositories love to compile HandBrake with their packaged FFmpeg version, which breaks subtitles.
They know, we know, but they don't care.
Try the Flatpak version from https://handbrake.fr/downloads.php

Try the snapshot.

Different GPUs have different hardware encoders on them that will give different results.

HandBrake always re-encode the video, so you don't need to cut on a keyframe, because the re-encoded video will always start on one.

Fixed in https://github.com/HandBrake/HandBrake/ ... 717803b7da
I don't know if the Linux snapshot has been updated yet.

Presets have been reworked for the 1.6 release, it could be the built-in were not updated properly on one of your computers. There should be a Preset -> Reset built-in presets menu item.

VLC on my Windows 11 PC can't play back full range properly, even Windows Media Player can't. It's probably related to the AMD drivers and the hardware decoder.
MPV seems more reliable.

It's been rebranded to oneVPL, but under the hood there is still libmfx for most of the encoding part.

The "add titles to queue" option should allow you to choose the order you want. The default ordering is a bit unfortunate.

I broke it when I tried to fix some SSA subtitles files. Samples with zero duration should be dropped. I'll try to make a fix soon.

Can you provide a short sample file to reproduce the issue?

Should be already fixed, you can try a the snapshot build: https://github.com/HandBrake/HandBrake-snapshots
or wait for 1.6.2.

I think it was fixed recently, try a snapshot: https://github.com/HandBrake/HandBrake-snapshots

Please post the complete encode activity log.

It requires x265 10-bit. DV tone mapper might use an higher precision internally, and if there is a full enhancement layer. But currently only the base layer is supported in HandBrake, and x265 supports Dolby Vision only in the 10-bit encoder.

It's automatic, but the only encoder supporting it is x265 10bit.

MKVMerge would have done it in 5 seconds.

HandBrake is not the right program if all you need is to remove a track. What's the format of the file? If it's a mkv you can use mkvmerge.

1.5.1 generated the subtitles SSA header in a different way, so it didn't have this issue.
I'll change it to use a locale independent conversion, hopefully making it in 1.6.2.

I think the issue is that it uses your locale, and so it's using the wrong separator when creating the subtitles header.

It's a locale issue, it seems it's using a "," to separate the decimal numbers instead of "." at line https://github.com/HandBrake/HandBrake/ ... on.c#L5288

Anyone remember how printf locale works?