HandBrake

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.

Yea that's the issue, a lot of the OEMs don't keep the drivers up to date or submit for WHQL, so WIndows Update may not offer them.

Update your GPU driver to the latest (546.33); you're on 528.96 if I'm reading it right.

Given that your source doesn't look as good as their encode, either they started with a better source, or did some filtering that looks desirable to you (denoise, sharpening, etc).

Auto, of course

x265 10-bit for the encoder preset veryslow and RF 18

And of course, start with a pristine clean source.

Indeed. Choosing a slower preset can help mitigate that somewhat, but not much.

Again, with the log, and maybe a description of the quality reduction, we may be able to provide additional recommendations.

RF, assuming everything you've said is accurate and complete. The encoding log would help understand if that's the case.

Code: Select all

[matroska,webm @ 0x157610de0] 0x00 at pos 6334250028 (0x1798cfc2c) invalid as first byte of an EBML number

So check that location for what the EBML is.

Errors in the source, but try the current release.

You didn't set the track to forced, you said only include subs from the track that are flagged as forced.

MP4 do support text-based soft subs, but the PGS subs you provided are bitmap subs and not supported by MP4, so the subs will be hard subbed.

[16:19:19] * destination [16:19:19] + container: MPEG-4 (libavformat) [16:19:19] * subtitle track 1, English (PGS) (track 0, id 0x4, Picture) -> Render/Burn-in, Forced Only You picked to only include forced subs, and no subs were flaggged as forced, so no subs are in the output. Also, you picked MP...

The activity log is also available in the app if you just did the encode.

Without the log, we have little idea what you're doing.

https://handbrake.fr/docs/en/latest/tec ... esets.html still lists Email 25 MB Small 10 Minutes 288p30

Does it occur if you use a non-toy encoder? Like x264?

No, it shouldn't be a problem.