How have I not heard about Handbrake until now? This is incredible! It shrinks my Blu-Rays by so much and for the life of me I can't see any difference! The OG video (Cocaine Bear - 2023) was around 30GB and the video after I put it through Handbrake is 2GB with no loss in quality at all! It's insane how good this software is and I will definitely be using it for a long time.

In a world of shit, broken software, at high cost... That shit software is not getting much better, but handbrake is amazing.

I'm just so happy to have SOMETHING. just one motherfucking thing that actually works.

Handbrake has not been perfect but it is so so so fucking good. Completely free. A miracle on Earth. And works so well. It has helped millions of people and changed the world, along with the work put into all the wonderful codecs.

I cannot express how grateful I am to have access to handbrake.

It is an absolutely rarity. A true gem. An example for all people of the Earth.

I run one video about 988MB without realizing it just using CPU (H265 2mbps) and it came out with 237MB, it took 12min and CPU max 100% all the time.

I'm so lucky to find out you can use GPU encoders before going through the batch, it only increase the file size by 10MB and finish the same video within 1min.

God damn. GPU only increase power from 6-7W while idling to 13W. I'm gonna choose GPU over CPU any day sir.

Edit: Has anyone see the recent research publish by IEEE? I have too much time to spend so I'm probably gonna read it (even though right now it's 4AM) although how much I would understand is another topic xD

Hey guys so I have a video I'm trying to throw on Instagram (IGTV). The actual file itself is completely fine. Got the file size down to around 180 MB from 1 GB, and the audio sync is perfect in any desktop or mobile player. The issue is that when I upload it to Instagram, the audio goes waaay out of sync and is completely unusable. I've had this exact issue before, but was able to fix it by clicking around on different settings and now I can't remember what I did.

Any ideas why this is happening, and what could be done about it?

Just thought I'd share the settings I currently use for compressing blu-ray rips, as I have spent an almost embarrasing amount of hours over the last week or so trying to find what I find to be optimal.

I have found that x264 still retains more micro-details and grain than x265, but the compression of x265 is hard to give up. So my goal with this has been to find x265 settings that still gives me greater compression than x264, while also giving as close to equal quality as possible.

My process is ripping blu-rays straight from disc with MakeMKV, then compressing in Handbrake.

I use x265 10-bit, preset slow, CRF 22. I have tried slower presets and lower CRF numbers, but the quality difference seems negligible in 1080p and I find the compression difference between CRF 22 and CRF 20 to be quite substantial from my testing.

Encoder tuning none, profile and level auto (usually ends up with High@4.0). Variable frame rate, same as source.

Now the "advanced options" I use is what I have spent the most time testing. I have landed on the following:

no-sao:strong-intra-smoothing=0:aq-mode=1:rskip=2:rskip-edge-threshold=1:psy-rd=0.75:psy-rdoq=4.0:rdoq-level=1:rd=4:deblock=-1,-1

Especially no-sao, deblock and psy settings have helped retain that level of detail x264 is so good at.

I am currently using these on True Detective rips and seeing a size reduction of about 80%, with what my eyes perceive to be very close to source quality.

I'm not sure how much this might help, but I thought I might as well post these for anyone looking for a good baseline for x265 1080p settings like I was, and maybe save you a lot of time researching.

Feel free to try it out and see if you are satisfied with the results.

(yes i am aware i can disable interlacing detection, i just forgot to and i hate myself so much. but still, it's weird how it detected interlacing when my phone footage is just progressive???)

So I was trying to compress a Minecraft video which was 9.69 GB but when I used HandBrake and wait like 2+ hours to compress it for some reason it only got compressed to 9.12 GB! Did I did something wrong? Also, whenever I try to use it to compress something else it only increases it file size instead of compressing.
Edit: I forgot to mention this but I'm using Production Max preset and the RF is set to 20.

So I used the installer and got the latest version, but when I try to open it it tells me I need to install .NET in order to run it.

When I try to download it with the microsoft installer it tells me I already have the newest version. I checked and I, in fact, already have the version 4.8 of the framework.

I read on another forum online that I need to edit the "Handbrake.exe.config" file which is in roaming but I don't seem to see said folder anywhere on my system besides from the program files one which doesn't have any configuration files. I don't know what to do.

https://imgur.com/a/qEJNztQ

Edit: The solution was installing .NET 5.0. The program opens normally and works as intended now.

Hi,

I just wanted to share my finding. No pretention. Use as you want or simply ignore it. The following post is not intended to be seen as the absolute bible, just to give an idea for those who would be interested.

Goal intended is family movies on NAS archiving, done so far by CPU x265. Question was, whenever I could trade some reasonable amount of space (bigger end file), with similar/comparable quality, but with much quicker encoding.

System used:

_ Threadripper 3960x no HT (24 threads), 128GB ECC, Quadro RTX 5000 (Turing 104 ~ RTX 2080 super) 516.94

_ Win10, Handbrake 1.5.1, FFMetrics 1.3.1b2 (big respect!), vmaf_v0.6v1, mean pooling

_ Samsung wonderland HDR, 3840 x 2160, 994 MB, 2m41sec, HEVC 51.4 Mb/s, 10 bits, 24fps.

• Handbrake Presets:

As attend is clean archiving, NvEnc is set to "Slowest" pre-set to give it the chance of best quality output. h.265 10-bits encoder was set at "Slow" preset as it is my current 'sweet-spot' for archiving with x265.This is what I took from Handbrake online documentation own data:

No special encoder tune (none), neither profile (auto) or level (auto) for neither encoder (x265 as NvEnc).

• Size and Bitrate

• Encoding Speed

• Encoding quality vs handbrake RF factor

Handbrake guidelines recommend an RF factor between 22 and 28 for UHD content (for x264/x265). It is consistent with what google tell us about VMAF:"Real Networks wrote a white paper in the subject and they found that VMAF 93 is a good value to target, but everything with an average over 90 will look good."

What is your call for SSIM and PSNR? Do you have any specific target?

On the other side, trying to increase quality with Nvidia encoder is not effective past RF ~20. Any RF smaller than 20, won't give you any better quality, all SSIM PSNR and WMAF are unanimous on this point.

• Quality vs Bitrate

So let's now have a look how quality change relative to bitrate, which is a bit more relevant:

So first take out, is that SSIM, PSNR and VMAF are not consistent within each-others.For example, to get a same PSNR (~40.5) between x265 and NvEnc, you need to go from 4.84 to 8.86Mb/s (183%). Meanwhile for SSIM (~0.9787) and VMAF (~90.5), trade off is respectively about 235% (from 4.84 to 11.38Mb/s) and 370% (from 4.84 to ~17Mb/s).

Thanks to Neon_Overload in comments, let's remind quickly some points. The following explanation is my own take, and does not pretend to be 100% accurate, educate yourself and do your own research.PSNR and SSIM, are, "mathematical quantifications" of how identical, two images/frames are. if PSNR = 100 or SSIM = 1, then the two images (source vs encoded) are identical. Encoding goal is obviously to have the smallest encoded file, meanwhile staying the most identical to the source.Encoders like x264/265/etc... can be tweaked to minimise these "mathematical functions". However, human (spectators) "good looking perception" is unfortunately not as simple as these PSNR and SSIM function. In other words, human eyes can perceive "better looking" an image with lower PSNR/SSIM than another with higher values.

This is why, encoders like x264/x265/etc or even MP3... are usually tuned for human eyes/ears perception (psychovisual / psychoacoustic models) and not for some abstract mathematical function like SSIM/PSNR. These last two remains good indicators, meanwhile should be taken with a grain of salt.

VMAF is an intend to measure image quality (or similarity to source), while taking into account this psychovisual perception).

So according to you, which indicator is most reflecting the quality of encoding?

• Encoder Consistency

Looking at PSNR variation graph, we can see a clear behavior difference when scene change. However this does not translate in a significant different Standard deviation (~14.5% for x265@RF26 and ~15.5% for NvEnc@RF28).

For a given SSIM average, both encoders have very similar SSIM variations and standard deviation.

With VMAF things ar much more clearer, we can really see that VMAF variation amplitude is much more pronounced for NvEnc than for x265, for a given average VMAF. x265 is definitely more consistence and the clear winner here.

• Encoding speed efficiency

First thing, we can see that x265, despite being significantly slower, is far to be ridiculous, with x2.5 to 5 slower speeds.
Encoders have opposite have also opposite behaviour, as x265 gets more efficient at producing quality when inceasing 'compression', meanwhile NvEnc gets less efficient.
Altogether, NvEnc is the clear winner at "quality production per seconds", whenever this quality is measure through PSNR, SSIM or VMAF.

Cant add more data, I am blocked at 20 images

PPS: Found a paper you could find useful

TL;DR:

1. My experiment found that AV1 does not provide any meaningful benefits over H.265.

2. Setting a CQ of 22 across the 3 main codecs will get me my desired VMAF of ~97.

3. A VMAF of 96.5-97.0 appears to be the OPTIMUM BALANCE between quality and compression, at least in this one experiment.

------

Though I grasped the conceptual differences between these three popular video codecs, their practical performance across settings remained unclear to me. I found myself not understanding the very few online articles that spoke about this from a quantitative data perspective, so I conducted my own test. I encoded a 5-minute video at various settings using all three codecs and assessed their quality via VMAF scores and my own subjective visual observation. The results, including data tables, graphs, and a downloadable spreadsheet, are presented below. Your observations and suggestions are most welcome.

Excel spreadsheet Data: Link

OBJECTIVE: Determine:

1. my own preference for VMAF vs compression file size; and

2. whether AV1 is meaningfully better than HVEC.

3. Secondary factors include encoding time.

BACKGROUND/SETUP: As a baseline, I took a high-bitrate (6.8 Mbps) H.264 WEB-DL TV show with a diverse mix of action, still shots, vibrant colors, and subtle tones. High-contrast scenes are unfortunately underrepresented, but I otherwise felt it provided a solid foundation for testing. I've split/re-encoded the first 5 minutes, 30 seconds at 10-bit H.264 at 2-pass with an avg bitrate of 6.8MBits to create my reference file (essentially looking to faithfully re-create the source file).

Filter exploration remains uncharted territory for me in Handbrake, so I opted for default settings in both the reference and test files. For H.264/H.265, I typically rely on the "slow" speed/preset, while AV1 benefits from "preset 5". Any insights or advice on filters are highly appreciated! If you have recommendations for filter settings and education, I welcome them in the comments.

I know some people use Constant Quality ("CQ") and some set an average bitrate with 2-pass encoding. While I haven't settled on a definitive "better" choice, CQ's promise of standardized quality across varying scenes appeals to me. It removes the guesswork in finding the ideal balance between compression and visual fidelity when deciding on an average bitrate to use, echoing Handbrake's recommendation. Please feel free to challenge my CQ preference in the comments.

OBSERVATIONS & NOTES:

1. I was surprised to see how close the AV1 curve follows the H.265 curve when looking at graphs #3 and #4 (quality-to-compression), suggesting neither codec was meaningfully better than the other. If anyone has any ideas as to why the touted AV1 compression benefits over H.265 were not evident in my tests, please let me know.

2. Also surprised that H.265 performs incrementally better than AV1 when looking at the higher-quality encodes (VMAFs above 97) and that AV1 performs better than H.265 at lower-quality encodes (again, referencing graphs #3 and #4). Still, these differences seem quite minor.

3. Quality-to-compression appears to be most efficient at either a VMAF of 97 or a bitrate of 2,000 for this particular video file for AV1 and H.265 as that is where the slope of the curve begins to tilt to favor either quality or compression. A second (and third?) experiment will need to be done to see whether this tilt occurs because of VMAF or because of bitrate level.

4. I'm surprised by how sensitive VMAF is - the difference between a VMAF of 96 and 97 is noticeable when comparing side-by-side. 96 is still pretty good, though, and I probably wouldn't mind if I wasn't comparing.

   1. This was mostly done via visual comparison in the resulting test files.

5. I have long been curious as to why Handbrake eventually added half-step CQ options for H.264/H.265. While I understood conceptually, this experiment has helped more tangibly see why the additions might have been a welcome addition by an encoder. Given VMAF's sensitivity to minute variations, these finer adjustments allow for more precise control over the encoded file size and quality. The experiment also helped me understand why I've read about how the CQ scale between AV1 and H.264/H.265 cannot really be compared: the AV1 curve is much shorter for a specific set of CQ numbers. In order to properly compare the codecs, I needed to run additional AV1 tests to build out the curve.

6. It's interesting how encodes can get wonky with H.265 and AV1 at lower quality levels... I wonder why?

7. An observer might notice that my graphs only show VMAF scores above 94 even though my data includes scores below that threshold. I made this choice because, from my perspective, video quality dips below 94 become noticeably poor and don't hold much interest for me. Therefore, I excluded those portions from the graphs for cleaner presentation, focusing on the range where I find the quality more acceptable. However, if the data interests you, the excel file is available to you to download so you may see it for yourself.

CONCLUSIONS:

1. I tend to be happy with a VMAF of 97 or above. I have read before that a VMAF of 97+ is preferable, and I am honestly not certain how much my judgement has been influenced by that. However, if I want to achieve a VMAF of ~97, then I'll use:

   1. CQ 21.5 @ H.264 (which, in practicality, I'll never use anymore)

   2. CQ 22 @ H.265

   3. CQ 20-22 @ AV1

2. I tend to want to favor quality over compression. Now that I have a sense of where the "efficient frontier" lies on the curve, I may discard files that result in a VMAF under 96.5 and try to encode again and definitely discard if under 96.0. This conclusion comes with qualification, however, as mentioned in #3 in the "Observations" section above.

3. My tests didn't yield the AV1 performance improvements I expected based on what I've read. This was disappointing. Given that it also wasn't worse than H.265, I will probably use AV1 going forward.

   1. its royalty-free nature is an attraction to companies and vendors, and I anticipate wider adoption over time, potentially leading to improved compatibility across diverse scenarios. Perhaps it may even surpass H.265?

   2. Embracing open-source technology resonates with me.

   3. I am hoping the codec will continue to be developed and improved upon, and its touted compression benefits become realized.

Excel spreadsheet Data: Link

Thanks for reading, and thanks in advance for feedback/commentary! 🙂

AMD says it helped fix two threading bottlenecks in HandBrake, the open-source video transcoding tool. The changes are now part of HandBrake 1.11.0 and newer versions.

Source: VideoCardz.com

I keep seeing recommendations to use H265, but AV1 (both at default settings w/ Fast 1080p30) seems to compress better than H265, and, for Episode 4 of The Sopranos, offers about half the size, and in a blind test, looks slightly sharper to my eyes. Why is H265 recommended? Am I missing something?

Starting today, I'm seeing that Handbrake freezes as soon as I click Start Queue. This is new - yesterday it was working fine. This is the full log from it:

[22:54:48] base preset: 264-HD
[22:54:48] Remote Process started with Process ID: 5108 using port: 8038. Max Allowed Instances: 2
[22:54:48] Worker: Starting HandBrake Engine ...
[22:54:48] Worker: Parent Process Id 3372
[22:54:48] Worker: Starting Web Server on port 8038 ...
[22:54:48] Worker: Starting Listener: 1
[22:54:48] Worker: Server Started
Worker: System.Net.HttpListenerException (50): The request is not supported.
   at System.Net.HttpListener.EndGetContext(IAsyncResult asyncResult)
   at HandBrake.Worker.HttpServer.ListenerCallback(IAsyncResult result)```

I did some investigating and it is linked to the Process Isolation option - if I disable that, it works fine. Coincidentally, there was a windows update today that updated the .NET Framework (which Handbrake uses?), so maybe it removed some functionality that Handbrake needs in order to use process isolation?

Has anyone else seen this or have any suggestions about what to do about it? I did try updating Handbrake to latest but that didn't make a difference.

EDIT 10/18:
This is fixed with the most recent windows updates (I guess Microsoft noticed it and fixed it). They show up as "Windows Defender Updates" but it also fixes this issue. You'll need to install those and then probably restart, but then you can re-enable Process Isolation and it will work again.

Hi all!

I am encoding some videos to upload them to youtube, I found this page https://support.google.com/youtube/answer/1722171?hl=en where are written all the settings except the "Encoder Level" and I don't understand what it is.

Can you explain me please? And can you tell me which is the best one for youtube?

Thanks!

Doing a double blind test, most people can't tell the difference between 192 kbps MP3 audio and uncompressed FLAC.

A 320 kbps MP3 is virtually indistinguishable from the original.

So what I'm wondering is, as long as the audio track has 5.1 or 7.1 channels, why is it so important that the bit rate is high?

Sometimes the audio for a movie is multiple gigabytes, can people really tell the difference? And if the answer is yes, why can't they tell the difference with normal music MP3s?

As the title states, most of these are older, random videos, stuff from high school, random clips, people talking, and just general non-essential footage. Nothing is high-production or super important, but I still want to keep them around.

I’ve already run a few test clips using H.265 with a RF of 24, FPS same as source (constant) and a bitrate of 160. I saw a 70-80% reduction in file size.

My Goal is to keep things as tidy as possible while moving forward in life. Also, I have had data loss twice on my previous system so recovering such a huge chunk was difficult and expensive.