HandBrake

Adjust subtitle settings in the Selection Behavior dialog and then save a new preset fir batch encoding.

Since the source is DVD, I suspect the automatic cropping of black bars is biting you here. Set cropping to manual and all values to 0 (zero) and save a new preset to use for batch encoding.

Where an odd number is required, an even supplied value is decremented by 1. More temporal frames can be very bad for chroma and introduce smearing since there's no compensation for movement. Luma, not as bad, but you won't get good matches either with high motion. 2-3 is usually good for film. The ...

I wouldn't exceed 3 or so temporal frames for film content. Try reducing 8 to 3 and increasing the spatial search range.

P.S. — If you need a current ffmpeg binary for macOS, there are prebuilt binaries here: https://evermeet.cx/ffmpeg/

NLMeans alone won't deal with these film artifacts. Given how it works, it's just not going to find nearby spatial or temporal pixels similar enough to the source artifacts to give them enough weighting in the filtering process, even when tuning the origin weight. hqdn3d is more of a blunt instrumen...

Looks like film damage and dirt. Typically, this is cleaned up in a proper editor, but I might be able to find some NLMeans settings that help. I'd say the most annoying are the white spots that periodically appear for a single frame.

Sounds about right. Fewer reference and B frames can reduce complexity, as can disabling pyramidal B frames per Rodeo. Disabling CABAC (using CAVLC instead) will inflate file size maybe 15% or more but should make the file much easier to decode... that alone might be enough. Very old devices includi...

Yes really! Thought maybe you meant to comment on viewtopic.php?f=7&t=39645

Not sure what CABAC and fast decode have to do with this topic, but maybe I'm daft.

@Rodeo I feel like your comments were meant for another thread regarding performance on older machines?

Looks like the images didn't come through. If you can provide a short sample of your source, I can try to find optimal settings and explain what they do. The reason the custom format is longer is that the parameters cascade. In YCbCr video (similar to YUV), we have a luminance channel (think black a...

Indeed, the video encoder profile (see the Video tab) affects what features are used. Baseline and Main are less CPU intensive during decoding than High. Additionally, lower RF (higher quality) means more data, which can impact decoding. Detelecine is only for NTSC sources, so if you've got 29.97 fp...

I wouldn't expect much difference between 25 and 50 fps; surprisingly the encoders can do quite well with more frames. There's a lot less overhead than one might think with typical sources. As far as deinterlacing, Decomb will create 25 fps and Bob will create 50 fps. The latter sacrifices a small a...

As for the age of the article, it was written this year just before HandBrake 1.3.0 was released. So the variances you see likely have to do with your chosen source being different enough from the one tested in the article.

This depends on the complexity of the source and various encoding parameters. Results can vary wildly.

QSV was not covered because I do not have QSV-capable hardware. I hope to revisit the article when I have it.

This article in the documentation talks a bit about the strengths and weaknesses of the software and hardware H.265 encoders: https://handbrake.fr/docs/en/1.3.0/tech ... mance.html

Hi, please see viewtopic.php?f=11&t=39542

Set peak frame rate to whatever the highest your playback devices support. For PC players this is usually not heavily constrained. Mobile devices and hardware media players are generally limited to 30 fps or 60 fps, though I imagine there are exceptions.

HandBrake cannot do this, but MKVToolNix can.

NLMeans is not single threaded, it's multiple frame threaded. It can be quite slow with high resolution sources because of how much data needs moved around, not strictly CPU. Generally, given two otherwise mostly equal systems, the one with the faster memory bus and faster/larger CPU cache is going ...

https://handbrake.fr/docs/en/latest/tec ... mance.html

Might provide some insights. x265 specifically does benefit from more cores, whereas x264 starts showing diminishing returns after about 6-8 with moderate settings.

One workaround might be to mount the ISO and point HandBrake at that.