HandBrake

Thanks.

So the x265 dithering algorithm(s) produce different results between 8- and 10-bit output, given an 8-bit input. That seems reasonable on its face, and given the way quantization error works the 8-bit result seems appropriate. Indeed, without settings to compare, it's certainly possible some additio...

Make sure your source video has its range info defined, and use HandBrake 1.3.3 (prior versions had a couple bugs leading to possible double range conversion).

The goal of this forum is to help each other use HandBrake and sometimes other softwares can help with that. So to be clear, it's usually okay to mention another software you're using in conjunction with HandBrake. Many other softwares such as VideoReDo, OBS, MakeMKV, and others are occasionally men...

Let's make sure the friendly banter doesn't get too out of hand, folks, lest I subject everyone to sticky posts about community and codes of conduct and such.

Hmm. Is there any chance you can provide a sample?

For devices that do not support H.265, you can try x264's aq-mode 3, which biases to dark scenes: https://en.m.wikibooks.org/wiki/MeGUI/x264_Settings#aq-mode Add aq-mode=3 to the advanced options (x264 only). Helped me in a pinch once or twice. Using a 10-bit H.265 encoder is preferable if your devi...

Thanks for the Activity Log. HandBrake is certainly tripping over your file a bit. Try disabling Intel QSV decoding in HandBrake's preferences and let us know whether that helps.

HandBrake's 4K presets (with the exception of the Playstation and YouTube ones) make H.265 video, which is slower to encode, but is what most 4K video players and devices expect. You can adjust the quality as you please, see https://handbrake.fr/docs/en/1.3.0/work ... ality.html

I mean, if you want to be really specific... https://software.intel.com/content/www/ ... embly.html

Rodeo wrote: ↑Fri Jun 19, 2020 12:54 am We do have code for "smart" frame dropping written by John, maybe it's selecting the wrong frames to drop in that case?

My suspicion indeed.

Select one of the 2160p 4K presets, such as the Apple one under Devices.

Ideally, HandBrake should drop every other frame in this case. I wonder whether something is causing that to not be the exact case.

Perhaps the confusion comes from x64 also being used to denote 64-bit x86, usually on Microsoft platforms. Nevertheless, x86-64 is an appropriate designation.

Locked for rule violations. Piracy will not be tolerated here.

It would be helpful if you can create a new issue at https://github.com/HandBrake/HandBrake/issues so we can better track this (and so it doesn't get forgotten). Thanks.

Will be in 1.3.3 which we plan on releasing very soon now.

The section in that article on display sizes and viewing distance attempts to address this issue. Any time a video is enlarged to fill a display, imperfections are magnified, hence the need for higher quality encodes in such situations, as Scott also notes here. I'm open to more clarification on the...

It sounds like in naming the file in the destination field, you've removed the file extension. Add .mp4 and that should solve the issue.

Of course, this is merely speculation since the required log was not provided.

The Vimeo YouTube HQ 2160p60 4K preset might be a good starting point.

Great. :) I have an RX 580 I occasionally pop in for testing (purchased used just for that article, believe it or not). Help is always appreciated. The documentation source is at https://github.com/HandBrake/HandBrake-docs. There's a contributing document there but TL;DR it's all written in Markdown...

Good to know. Indeed, when revising the NVENC docs I used the source code for those options as reference. Naturally, it's not indicated what's available on what hardware, and there are no guards against blowing it up. :/ At some point, I'd like to better document my test setup for the performance ar...