HOW TO: 10-bit x264 and 10/12-bit x265 encodes with HandBrake! (Mac OS X, Linux, Windows)

Update #2 (Jan 2018): The latest nightlies ( seem to include 10/12 bit for x265. So if that’s all you need, you don’t need to read/do anything below – just grab the latest nightlies. OTOH if you’re looking for 10-bit x264, that info is still below.

Update (July 2017): This was originally written back in Feb 2016, and the libraries I supplied back then are now too old for newer versions of HandBrake and likely won’t work or will have issues. I built a new Mac version on July 3rd 2017 which is below, and fortunately there are now good alternate options for Windows/Linux. Details as follows:

  • If using Windows, under the Windows section below I have a link to the Handbrake forums where they provide updated libraries. Use that! The 10-bit-only CLI version I have linked in the Windows section should work too, but it’s old.
  • If using Linux, Stephen Smith was kind enough to mention in the comments that the x265 libraries are now available on Ubuntu ( apt-get install libx265-dev ). Use that (don’t follow the rest of the instructions in the Linux section). I suspect other distros have variants available, and there’s also the Fedora repo listed in the Linux section.
  • If using Mac OS, the original (2016) and newer (2017) 10-bit-only builds should work. I wouldn’t suggest using the .dylib option, as those .dylibs are from the original write-up and quite old now.

The original write-up is still below, but keep the above in mind.

I recently got a Tronsmart Vega S95 (media player) which claimed to support 10-bit HEVC encodes. Unfortunately, I didn’t have any 10-bit encodes on hand to test out those claims with!

Short version is that I wanted to get 10-bit encoding working with HandBrake on OS X. Long version ends with figuring it out on Linux and Windows too because I figured it’d be helpful for people who don’t have 3 OS’s to swap between. These are the results:

8/10/12-bit HandBrake on Mac OS X8/10/12-bit HandBrake on Linux (Ubuntu)10-bit HandBrake CLI on Windows

Before somebody decides to encode their entire library in 12-bit HEVC and ends up utterly disappointed, once you’ve grabbed whatever info/files you want for your OS, scroll down waaaaaay to the end and have a read.

Okay, so one at a time, here we go…

(jump to Linux instructions)
(jump to Windows instructions)
(jump to the note on HandBrake and 10-bit)

Mac OS X

You basically have 2 options here:

  1. A separate 10-bit version (which I’ve included in the writeup) that you can run beside your current HandBrake install.
  2. Use the “nightly” HandBrake, and manually install some library files (which I’ve included at the end).

Option 1

I compiled a 10-bit version (both x264 and x265). Just download it, unzip, throw it in your Applications folder if you want, and run it (the same way you’d run your current version). A few notes on it:

  • It’s the easiest/cleanest option. If you decide to get rid of it, uninstalling is as simple as dragging to the trash.
  • It’s ONLY 10-bit. So don’t go un-installing your current version.
  • For x264 encodes, you must change the Profile to “high10” (not auto), or the encode will instantly fail.
  • Don’t “check for updates” or anything, because if it actually finds an update, it’ll be from the HandBrake website (and for the standard 8-bit version most likely).
  • The 2016 version was built on “El Capitan” (OS X 10.11.3), and 2017 version on Sierra. I didn’t muddle through things to see what the minimum OS version was set at. So if you’re using an older version of OS X, it may or may not work, but feel free to leave a comment if you try.

If you’re interested, you can grab it here: (July 3, 2017) (mid-2016)

Option 2

I compiled some x264 and x265 libraries for 8/10/12-bit support that will work with the latest “nightly” version of HandBrake. You can grab it from the main HandBrake website at:
(note: you are after the result that does not have “CLI” in the file name)

Get it installed (you can sit it beside your regular version if you want). Next, you have to download the libraries I’ve packaged together:

Unzip the file and you should have a new folder called “handbrake-libs-mac”, with contents that look like this:

handbrake-libs-mac folder

Those are the library files that you need to install on your system. For HandBrake to see them, they have to go in the /usr/local/lib/ folder, which is hidden from the Finder by default. If you’re comfortable in the terminal, a sudo cp will likely do it.

Otherwise, you can tell Finder to manually go to the correct folder by opening a new Finder window and clicking “Go” from the top menu, then “Go To Folder“. A few images below to help (click for larger versions):

Finder: Go To FolderFinder: /usr/share/lib/Finder: Drag and Drop to copy to "/usr/share/lib/" folder


Basically, drag the libraries you downloaded into the /usr/local/lib/ folder and you should be good to go!

Note that technically you only need to copy the 3 that have a “10” or “12” in the filename if you’re using the HandBrake nightly build (since it already contains the standard 8-bit versions built-in), but it shouldn’t hurt anything to just copy them all.

Now open up HandBrake (or exit/restart if it was running). You should now have access to 8/10-bit versions of x264 and 8/10/12-bit versions of x265!

A few notes:

  • 10-bit x265 might immediately crash on the slowest settings (slow, veryslow, etc). The separate 10-bit-only version I compiled above doesn’t seem to suffer from this issue, so you may want to use that if you’re doing x265 10-bit at those speeds.
  • On my machine, the x264 10-bit version was often coming up as the default selection. If you’re in the habit of just assuming x264 8-bit is the default, make sure you double-check before you hit encode!
  • At some point, there will undoubtedly be new versions of x264 and x265. When that happens, the ones you installed will be a bit dated, so keep that in mind. They don’t auto-update or anything.

(jump to Windows instructions)
(jump to the note on HandBrake and 10-bit)


A quick note for Fedora/RHEL users… has a HandBrake repo and they now have the 8/10/12-bit stuff enabled there. I strongly suggest just adding their repo via their instructions if you’re on one of those distros.

These instructions are primarily for Ubuntu, though other similar (debian-based) distros should work. Non-debian-based distros should be doable if you can locate a program that converts .deb packages to whatever you need (for example, Alien is common for converting from .deb to .rpm).

Anyway, let’s get on to it.

Step 1 – Grab/Install the Latest Nightlies

If you’re using a supported version of Ubuntu, follow the instructions for installing the PPA at: . Basically, the commands (if you’re both lazy and trusting) are:

sudo add-apt-repository ppa:stebbins/handbrake-git-snapshots
sudo apt-get update
sudo apt-get install handbrake-gtk

If NOT on Ubuntu but are on another Debian-based distro, you can still manually download one of the packages in .deb format and install it. Head to: , expand one of the down arrows – generally the top arrow if you’re on a fairly recent version of your distro, and grab the .deb that includes “gtk” in the file name (the “amd64” variant for 64-bit). Incidentally, this is also what you’d do if on a non-debian-based distro and were using a package converter. Then try and install the package – if you don’t have a built-in package manager, you can usually do it from the command line with sudo dpkg -i theFileName.deb

Okay, let’s assume you got it installed, and it runs (just type “ghb” in a Terminal if it doesn’t show up with your applications).

Step 2 – Install the 10/12-bit Libraries

I’ve built the libraries for linux, and you can grab them here:

Extract them, and you should have 5 .so files, somewhat similar to the earlier Mac screenshot. Now you just have to copy them to your library.

  • For Ubuntu, your library location is usually: /usr/lib/x86_64-linux-gnu/
  • For Fedora, your library location is usually: /lib64/
  • For others, you’ll probably have to look around. It could be one of the 2 shown above, but you’re best to check first. Chances are if you run across a location that has “lib” in the directory structure and contains a zillion .so files, you’ve found the right place.

The file managers in Linux have a tendency to refuse access to root folders rather than asking for privilege escalation, so chance are you’ll have to copy from a terminal/shell window. Fire up “Terminal” or something similar, and navigate to the location you unzipped the 5 files. Do a quick “ls” to make sure you’re in the right place. For example:

cd ~/Downloads/handbrake-libs-linux/
ls -l

(should show the 5 .so files if you’re in the right place)

Next, you’ll have to copy them to the library location mentioned above. As an example:

# For Ubuntu:
sudo cp -n libx26* /usr/lib/x86_64-linux-gnu/

# For Fedora:
sudo cp -n libx26* /lib64/

(the “-n” means no-clobber – it won’t overwrite existing files).

Assuming that was successful, try firing up HandBrake. Hopefully you’ll have all the x264 and x265 options available now!

A few notes:

  • Similar to the Mac instructions, you don’t actually need to install all 5 .so files. You only really need the 3 with “10” and “12” in the file names since HandBrake already will have taken care of the standard 8-bit versions.
  • This is a bit of a “dirty” way to put the .so files in the library directory, so remember that you put them there. Usually, the system’s package manager has some idea about which packages are throwing what in there, but since you’re brute-force-copying, that might throw a wrench into things down the line.
  • If you’re comfortable with sym-linking, a slightly cleaner way to do this would be to add version numbers to each of the files (.so.148) and symlink to .so, which is what most packages do to help keep things at least somewhat organized.
  • I didn’t include any pre-built versions (just the libraries) – it just caused too many dependency headaches on fresh systems if HandBrake wasn’t installed at some point anyway. It also depended on the x264 library being installed anyway. If somebody really needs the binary, ask in the comments and if I haven’t wiped the VM yet, I’ll see what I can do.

(jump to the note on HandBrake and 10-bit)


Update: It looks like the Handbrake devs have Windows DLL’s available that you can simply use with the current nightlies for 10-bit support (x264 and x265) and 12-bit support (x265). The page on their forum that carries them is: .

I haven’t tried them myself, but would imagine they just get plopped into your Handbrake directory. You need to use the nightly version of Handbrake though ( ).

In the event that the links end up broken at some point in the future (or you don’t have 7zip installed), I rezipped them (.zip format) and you can grab  local copies from here: (x264 10-bit) (x265 10-bit) (x265 12-bit)

Those DLL’s are probably the best solution for the vast majority of situations. Feel free to leave a comment whether it works seamlessly for you, or if you hit issues.

Note that Lazarus also came across a GUI solution in the comments below which you can jump to here: #comment-22958 .

The remainder of my original write-up is below anyway in case you’re curious, are doing something a little different, or are looking for the CLI bit…

Visual Studio hates me (and now I hate it back), so I was only able to get the CLI version done. I did build the libraries for the GUI version, but we’ll just do the CLI bit now and talk more about the GUI stuff later.

The 10-bit CLI version I built can be grabbed from here:

Extract it, and you should have a HandBrakeCLI-10bit.exe program that can be run from the command prompt.

It supports both 10-bit x264, and 10-bit x265. It also ONLY supports those x264/x265 variants, so if you’re using the standard 8-bit CLI, you’ll still want to keep it around.

It’s critical that when using it, you specify the encoder-profile. For example:

HandBrakeCLI-10bit.exe -i inputVideo.mp4 -o newVideo.mp4 -e x264_10bit --encoder-profile high10
HandBrakeCLI-10bit.exe -i inputVideo.mp4 -o newVideo.mp4 -e x265_10bit --encoder-profile main10

The important bits are:
-e x264-10bit –encoder-profile high10 (for x264 10-bit)
-e x265-10bit –encoder-profile main10 (for x265 10-bit)
…if you don’t include the encoder profile, it will *fail*.

As to the rest, if you’re new to using the CLI, you’re best to browse through the guide at:

Alternately you can type “HandBrakeCLI-10bit.exe –help” to see the options, but it’ll completely fill your screen. You can save all that text to a file instead to read with Notepad later with “HandBrakeCLI-10bit.exe –help > hb-help.txt

The GUI bit on Windows

As I alluded to earlier, I did get libraries made up for the Windows GUI version. Unfortunately, they didn’t seem to work with the current nightly version (it reads them, but doesn’t display the additional x264/x265 options). I’m guessing either:

  • The nightly build from Feb 13th missed the patch (from the same day) that enabled 10/12-bit DLL support in the Windows GUI (hopefully).
  • Something built wrong on my end (hopefully not).

Due to the Visual Studio hatred mentioned previously, I haven’t tried building the GUI myself from the patched source yet.

In any case, if you’re building from source yourself or are quicker at finding the new nightly than I am, the 8/10/12-bit x264/x265 libraries that I built can be downloaded from here:

They go in the same directory as the HandBrake Nightly. Usually this is C:\Program Files\HandBrake Nightly\ .

For reference, the nightly I tried (unsuccessfully) was HandBrake-b7cb7d6_x86_64-Win_GUI.exe . Only try these libraries on a newer version.

Keep in mind that because adding libraries to the Windows version would be remarkably clean compared to linux/mac (they could just be included with the program files on Windows!), it’s within the realm of possibility that the HandBrake devs might just add the libraries to the install itself at some point.

A Note on HandBrake and 10-bit Encodes

At the beginning I mentioned that it might be a good idea to scroll waaaaay down before someone goes off and encodes their entire library at 12-bit HEVC. There are a number of reasons NOT to encode via 10-bit and 12-bit in HandBrake.

It’s worth mentioning that the builds/libraries above should be considered somewhat “experimental”. It’s within the realm of possibility that something won’t work correctly (or at all). Don’t be quick to blame HandBrake or x264/x265 if you’re running into issues – I could have very well missed something when compiling.

If you copied the libs on Mac or Linux, be sure you’ve got some idea as to where you stuck the libraries too, just in case they conflict with something and/or you want to remove them later.

Why NOT to use 10-bit and 12-bit

First of all, HandBrake’s entire toolchain is set up for 8-bit 4:2:0. Basically that means if you have a source that’s 10-bit 4:4:4, by the time HandBrake spits it out at the end, it’s probably going to have been reduced to 8-bit 4:2:0. There’s not a whole lot you can do about that, and there aren’t any simple “switches” that the developers can really flip either. They may be able to migrate over time if they want to go that route, but it’s a *really* large code-base that relies on a lot of external tools they don’t necessarily have a lot of control over.

The next problem is that device support is minimal at best.

  • For x264, you’ll have a hard time finding a phone/tablet/device that’ll play 10-bit video. Often, devices that *try* to decode it in hardware will have the colour palette looking super-saturated. You’re generally limited to computer playback.
  • For x265 (HEVC), it wasn’t until the end of 2015 that devices started trickling out that could handle 10-bit. There’s also a wonky situation going on with some of the latest stuff where you get devices that claim 10-bit HEVC and 4K display, but in actuality can either do 10-bit at lower resolutions (1080p), or 8-bit at 4K.

Really, unless you’ve literally upgraded all the phones, tablets, and media players in your household within the last few months, chances are that moving to 10-bit encodes is going to leave some of your devices out.

There’s also the time issue. 10 and 12-bit encodes tend to take longer (in test encodes while building the stuff above, a 10-bit x264 encode also sucked up a surprising amount of RAM).

Really, you’re “paying” a lot (time, device support, etc), with not a whole lot in return.

That being said…

Pros to 10-bit? Efficiency and Banding?

10-bit x264 has been common in the anime community for quite some time due to a reduction in banding. I haven’t heard whether the same is supposed to hold true for x265 10-bit (I’m not sure why it wouldn’t), so I’ll leave you to do your own research and draw your own conclusions there.

There’s also a notion that 10-bit is more efficient (even with an 8 bit source), probably as a result of the document here: .

There may be good cases for using 10/12-bit, but at the same time, it’s not something that comes “free” and it’s a little tough to quantify. My best advice would be to run your own test encodes back-to-back and decide for yourself.

Hopefully the libraries above will help you do just that :)


62 Comments | Leave a Comment

 Sort by Oldest | Sort by Newest
  1. Xeniolum on February 23, 2016 - click here to reply
    Thanks for the article! Really handy. I was frankly surprised to even find the ‘fixed’ version of Handbrake for Mac. Thanks again!
  2. Toxic on February 24, 2016 - click here to reply
    How did you compile the libs? A guide would be helpful thank you
    • Matt Gadient on February 24, 2016 - click here to reply
      Hey Toxic,

      For x265, there are some brief instructions at . If I remember correctly, the general process (while following the steps in the link) was something like this:

      For Linux, basically once the dependencies are dealt with, it's a matter of running the shell script - build for 8-bit, pull your .so out, make clean, build for 10-bit, pull your .so out, make clean, etc.

      OSX was really similar except that you have to manually download and install yasm & cmake first. CMake comes as a GUI program, but has a drop-down option which shows how to add it to the path.

      Windows was a little more tricky. It's built on Linux via MinGW. I didn't have luck with MinGW from the Ubuntu repo when I was working on the HB binaries, so I manually built that one from source following the one used in the HB guide (the source may be a it on the older side) and just used that one when attempting the libraries. Once everything is in place, to build the libraries, there's a shell script at x265_1.9/build/msys/ which will probably handle that... I actually missed it at the time so I ended up creating a script that dumped all the settings in as cmake options - it's quite possible that if the libraries I built don't work, just running the included script *will*.


      For x264, I don't recall things being drastically unexpected on Linux or OSX - a "./configure" where I manually plugged in configure options (--bit-depth=10 --chroma-format=420 , etc). For the windows build, I just now skimmed through some of the scripts I had thrown together and I believe I used something like:
      export PATH=~/mingw/bin:$PATH
      ./configure --bit-depth=10 --chroma-format=420 --enable-shared --enable-static --disable-cli --host=x86_64-w64-mingw32 --cross-prefix=x86_64-w64-mingw32-


      I know that's not a complete guide by any means, and being done from memory might be even less reliable. Depending on what you're building for, hopefully it's enough to get you started.

      One thing I ran out of time to experiment with (but might be worth exploring) was seeing if the builds would work - the immediate benefit there would be that you'd only have 1 library to deal with if it *did* work. A possible benefit further down the line would be that if it can be statically linked to a HB build (not sure), maybe it could even be embedded into a HB build (though to fire off a script, it may not be as easy as a contrib/x265/module.defs edit).


      Anyway, hope something in there helps!
      • azmal on May 6, 2017 - click here to reply
        hi matt.First, thanks for your work.for me your x264 10-bit is working perfectly.but
        x265 10-bit or 12-bit.not working.can you please help me with x265 10-bit any new zip links
  3. jeff on March 13, 2016 - click here to reply
    I cannot get my handbrake to get to 10bit. the new nightly as of march 13 takes literally 10 minutes to open up and when it finally does, even with your files, will not give me to option of 10 bit. i dont understand.
    • Windows, Mac, or Linux?

      The Mac/Linux variants should hopefully still be working, but when I wrote this up the Windows GUI variant at the time didn't have the code to expose the options so I wasn't able to test the libraries out on it (hence the provided CLI version since it was my only option for Windows at the time).

      Try removing the libraries and see if the 10 minute delay goes away (I suspect it will). Alternately you could try just using 1 library at a time to see if specific one(s) work/don't. Let me know which OS you're working with and if I get some time I'll try to poke around some more.
  4. Anonymous on March 14, 2016 - click here to reply
    WONDERFUL!!!! I was about to install Windows on my MAC just to use StaxRip for 10bit. This saved me a week of misery and pain! You rock!!!!!
  5. James on March 14, 2016 - click here to reply
    This is wonderful, 10bit for Handbrake x265!! Quick (possibly very stupid) question: I know that taking a physical Bluray source and encoding in 10bit is great (b/c the Bluray source is probably 10-12bit already) BUT how about taking previously already-encoded material in x265 8bit and then converting to 10bit? Is there any point? I've got 10bit TV and iMac so, I definitely prefer 10bit color.
  6. Anonymous on March 18, 2016 - click here to reply
    Thanks a lot for this. I've been searching months for a 10 bit x265 encoder for Macs. I'm testing it with different RF values. Very impressed with the output.
  7. Jon on March 25, 2016 - click here to reply
    Hi Matt
    Is there away to get HE-ACC Audio Format working on this
    Many Thanks
    • Hey Jon,

      The FDK codec (which provided HE-AAC for Windows/Linux versions of HandBrake) has been dropped from recent binary versions of HandBrake due to license issues.

      Options if you really need HE-AAC:
      • Compile from source and use "--enable-fdk-aac" (or edit make/ and change the default setting).
      • Use the Mac OS X version of HandBrake (which uses Apple's AAC and HE-AAC encoder and didn't need/use FDK anyway).
      If you don't need to use the 10-bit libraries and just really need HE-AAC, you could search around for an older version of HandBrake, including any nightly builds from before ~Feb 10/2016. Everyone's technically supposed to stop distributing versions < 10.0.5 due to the FDK issue, but with the web being what it is, I'm sure not everyone got that message and there are undoubtedly old copies kicking around out there.

      Admittedly not the greatest/easiest of options, but I think the FDK issue really caught everyone off-guard and I wouldn't be surprised if it takes some time before an HE-AAC solution makes it's way back into HandBrake by default.
  8. Jon on April 8, 2016 - click here to reply
    Thanks Matt,
    if it's ok with you here is a link for the older versions of Handbrake if anyone is looking for them, Please remember if you update the version you will lose HE-AAC

    Thanks Matt
  9. Lazarus Dark on April 30, 2016 - click here to reply
    I figured out a workaround to your Windows GUI problem. Or rather stumbled on it by accident.
    If your release version of Handbrake has main10 as an option, select it and create a user preset called x265 10bit or something. (note, though it shows main10 as an option in my release version of Handbrake, it does not actually encode in 10bit if I select it, it still comes out 8 bit. It seems the option was put there before it was actually functioning). After creating this preset, I opened your from above, renamed it to HandBrakeCLI.exe and just copied that into the Program Files/Handbrake over the existing version. When you open handbrake there is no option to select the profile like you say, UNTIL I click on my x265 10bit user preset then that option appears.
    This is probably not how it is supposed to work, but the final video encode is 10bit according to mediainfo so it seems to work just fine.
    (thank you SO much for sharing this file. I spent two days trying to figure out how to get 10bit x265 encoding using ANY software and this was finally my best option. I just got a Nvidia ShieldTV and its replacing my htpc and it has x265 10bit decoding support so I want to finally get around to archiving all my anime dvd's before they start dying, some are already giving errors, yikes!)
    • Luke on July 30, 2016 - click here to reply
      Awesome! I had been trying to figure out how to get rid of the gradient banding on things like a dark sky due to the 8 bit limited color range and this trick has done the job beyond expectations. No more artifacts even at RF18 in Handbrake 0.10.5 and on the Ultrafast preset! I tried the nightly build with the 10bit dll pack but encoding took twice as long and resulted in much bigger file sizes with no visible improvements. I also tried encoding in 12bit but the resulting file was just a green screen. Many thanks to you for sharing this solution and to Matt for his hard work providing this wonderful resource. Cheers from Osaka, Japan! [ i7 4770 16GB GTX970 Windows 10 64bits]
  10. Jason on May 10, 2016 - click here to reply
    Hello - sorry, can you confirm where you put the library files on Mac running el have /usr/local/lib in the description but there is not a LIB folder in Local in that directory. Then your screen shot has the folder user/share/lib there is not a lib folder in that directory either...sorry for rookie question, just trying to figure out exactly where to place the files correctly
    • Sorry, goofed on the 2nd screenshot. The text (and 1st screenshot) should be accurate: /usr/local/lib . Note that /usr is hidden by default, hence the need to manually head there via "Finder Menu / Go / Go to folder".

      I'm on El Capitan also, but if /usr/local/lib doesn't exist on your machine, you could always try creating it (hopefully /usr/local already exists), toss them in, and see if that works.

      If not, you can try sticking them in /usr/lib and give that a try... it's the system-wide lib folder. Unfortunately, you'll probably run into an SIP (System Integrity Protection) error unless you've disabled SIP... it protects everything in /usr with the only exception being /usr/local. You may also need to change the ownership of the files to root+wheel once they're in /usr/lib/ for this option to work. So this option has the potential to get really messy... quite possibly more messy than you're willing to deal with.

      If even *that* doesn't get you some progress, browse around /usr/local and see if there's another location that's full of .dylib files and you might get lucky by tossing them in there. As a last resort, you could try adding them to a path folder (type "echo $PATH" in terminal to see which directories are included in the system path), but I don't know if the paths are included when searching for library files so unsure whether that'll work.

      I know it's a lot of trial-and-error, but hopefully something there helps. If you trial-and-error something that doesn't work, it's probably worth undoing the change to keep your system from getting all cluttered with files all over the place. Keep in mind I've also got the 10bit-only version of HB linked up there for download which is a couple months dated now, but is always an option if all else fails since the 10-bit libs are built into the binary and it doesn't require the separate .dylib files at all.

      Good luck!
  11. Matt on May 11, 2016 - click here to reply
    Hi Matt,

    First, thanks for your work, I use handbrake 10bit x265 all the time!
    Second, are you planning on releasing an update version of the compiled package?

  12. Anonymous on May 23, 2016 - click here to reply
    Been using for months now without a hitch! Wonderful work!! Thank you. One issue has now arisen with two different rips. Stuck at 99.8 percent, with 2 seconds left. (After 24hr encodes...) Anyone else having similar issue or anyone know what's up. I've got a log file should you need.
  13. Boris on May 26, 2016 - click here to reply
    Hi Matt first thanks for your hard work... I want to reencode my anime collection to 10bit so i can shrink the file size! but the problem is that Handbrake freeze by 40% have you an idea what that can be? my encoder options are faster, high10 and 4.0
  14. Just a heads up - you no longer have to manually grab the 10-bit libraries on ubuntu as both 8 and 10 bit libs are included in ubuntu's libx265-dev package.

    Just apt-get install libx265-dev for the libraries.
  15. Paul Chambers on August 22, 2016 - click here to reply
    As a novice, less than a year at this, I have this question. In August 2016 Windows broke x264 for usb devices in favor of yum so their APPS would be more efficient. There are work arounds. I know it broke my ability to watch live TV on my USB Hauppauge TV tuner until I did the registry hack. However things recorded ok. I think the biggest media reports are emphasizing how Windows broke webcams but it goes farther than that..

    Is x264 dead now that Windows decided to break USB devices and should we start going in a different direction when we transcode/reencode/convert?

    I don't know what the long term implications are. I know your site has helped me save quality and reduce the size of my recorded TS streams using Handbrake. I use HandbrakeCLI and a post processing batch script in NextPVR for my video "jukebox" and watch on Roku and other DLNA's appliances.

    I just got comfortable with Handbrake even have my patch script change the HandbrakeCLI commands based on HD and SD channels to improve quality. I don't use the PC much to watch TV, so this concern may be nothing. I am considering leaving Windows on my PVR box but I am comfortable with NPVR as my backend and frontend.
    • Matt Gadient on August 23, 2016 - click here to reply
      Hey Paul,

      I actually hadn't heard about that Windows issue until you brought it up. The first news article I came up with was (for anyone else following).

      I wouldn't worry about it having long-term implications for x264. It looks as though it's more of an app-breaking change that they made - the app used to access the webcam/etc via H264 would now have to be rewritten to access the decoded stream via the OS instead (and the OS then does the H264 decoding itself). I think trying to *force* the OS to be the middleman here was probably a silly decision on Microsoft's part, but hey, I suppose they can do what they want. It sounds like they've been promising a "fix" for some time so maybe we'll see that come to pass one day.

      All that said, H264 (and by extension, x264) is probably one the most widely used formats today, and really isn't at risk of being killed off by any 1 company. I'm sure it'll be *depreciated* one day (superseeded by HEVC/H265/x265 and/or VP9 and whatever comes after), but forcibly killing it off before it's time would probably take nothing less than an industry-wide effort (along with a compelling reason to actually do so).
      • Paul Chambers on August 23, 2016 - click here to reply
        Thanks Matt.

        I agree forcing the OS to be the middleman of other applications is not a good thing. I like multiple applications sharing the decoding at the same time but I think they should do it across the board, at least most widely used codec.

        I've read many complaints by industry engineers on how this has broken their applications. Interestingly, Microsoft has an alternative application solution to each broken app and it's usually one of theirs.

        I am glad 264 is here to stay for a while.

        Sorry to sideline this post but since it was dealing with the new codecs (x265) I thought it was the best one to bring it up on.

        Thanks again.
      • Paul Chambers on September 6, 2016 - click here to reply
        Hey Matt. I forgot to mention. I got my webcams working, even an old one about 15 years old by going into the device manager and updating the driver, and choosing the generic USB driver instead of the OEM version. You lose some features like tilt and auto zoom but until there is a work around or fix, this at least gets me us up and running. Microsoft only has a list of about 10 new webcams that will work on the Anniversary Upgrade.
  16. Vice Liberty Andreas on August 30, 2016 - click here to reply
    I'm sorry for this noob question but i can't find it elsewhere. How can you encode 10-bit HEVC videos when the hardware support for 10-bit HEVC encode was bound to release for 7th Generation (Kaby Lake) Intel processors? Is it still possible to encode 10-bit HEVC using the 6th Generation (Skylake) Intel processors?
    • Matt Gadient on August 30, 2016 - click here to reply
      The x265 (and x264) encoders in HandBrake are software-based encoders. Thus, they'll run on just about anything from Skylake to the 10-year old Core2Duo processors. They'll also run on ARM based devices, numerous AMD processors, even older Intel processors than I've mentioned, etc. Basically, they'll work on anything that compiles the code.

      So yes, you can certainly encode 10-bit HEVC on a Skylake. Chances are that every computer in your household will do it - older ones might be painfully slow at it, but it'll work just fine.

      The hardware-based encode/decode support that's supposedly coming in Kaby Lake is basically a separate HEVC encoder/decoder integrated on the chip - it's a different encoder, and thus encode results will likely be quite different from the results you'd get using x265. If history is any indication, it'll probably be extremely fast and use very little CPU power, but the tradeoff is that size/quality will probably be worse than with x265.

      Note that even though the 10-bit HEVC encode/decode in Kaby is hardware-based, software will still have to be written/modified to actually *utilize* it - it's not something that you'd just automatically benefit from on Day 1. VLC and other media players will probably add code at some point to utilize the hardware decoding feature. On the encoding end, it'll probably pop up in some of the video editing tools at some point. If the HandBrake devs decide to utilize it, it'll likely be a separate option from x265 and might be OS-specific (similar to how H264 QuickSync is only available as an encoder option in Windows builds).

      Hope that helps!
      • Vice Liberty Andreas on August 30, 2016 - click here to reply
        thanks for shedding this light. I won't be too worried now on buying Skylake today because I don't have time to hold out for Kaby Lake which was pushed back again for 2017.
      • Vice Liberty Andreas on August 31, 2016 - click here to reply
        Thank you for this
  17. David Dietrichstein on September 23, 2016 - click here to reply
    Thanks for the tutorial! Do you know any software for mac that supports hardware encoding via gpu (for h.265 of course)? doesn´t have to be handbrake (i don´t think it´s possible yet). i just found a blog entry where someone tried to compile ffmpeg with h.265 gpu encoding support, but it didn´t work unfortunately. guess the problem was that the hardware encoding only works on linux. if you have any tipps - i would appreciate it!
    • SWIOTI on November 27, 2016 - click here to reply
      Unfortunately, until Apple decides to enable support for h.265/HEVC, I don't believe hardware encoding will be possible. I spent a week trying to find the NVEncodeAPI in the Nvidia drivers, or the MFX dispatch in the Intel drivers - they just aren't there in the Mac OS as far as I could tell, probably because Apple doesn't want them exposed. If you want to use hardware encoding, you'll have to use the VideoToolbox framework, and right now that only supports h.264 in hardware.
  18. unHENTONG on October 7, 2016 - click here to reply
    Hi Matt,

    First, thanks for your work, I use your compiled handbrake 10bit (windows) all the time :v :v

    But, are you planning on add x265-12 bit too? just for ask... hehehe :v :v
  19. Matt on November 11, 2016 - click here to reply
    I've compiled the latest x265 (2.1) library for Mac with 10bit and 12bit. If anyone's interested it can be downloaded here:
  20. Madeline Esposito on December 2, 2016 - click here to reply

    I've run into an interesting issue, on Fedora 25, following the link you provide and the instructions they provide, Handbrake + 10/12 bit x265 work just fine, however on Ubuntu 16.10 10/12 bit x265 fail, even if I manually choose the 10/12 bit profile from the GUI, any idea why this is and how to fix it? Thanks.
    • Matt Gadient on December 2, 2016 - click here to reply
      Not sure. Possible my versions are too old for the latest nightly now. Could be worth removing them and following Stephen Smiths instructions to get the ones available in Ubuntu (apt-get install libx265-dev).
  21. M2m on December 4, 2016 - click here to reply
    Hi Matt!

    First of all thank you for this article and all the effort !
    I played around with your Handbreak 10bit macbuild ( ) and have some interesting results.

    Encodeding a h265, 10bit file with ultrafast preset (Constand Quality - RF 20) yields to a much smaller file then the "twin" with medium preset (still Constant Quality - RF20).

    I used one of my old Babylone 5 DVDs (Voices in the dark) - original size 3.32 GB (anyway the exact filesizes do not realy matter)
    Ultrafast file: 361.6 MB
    Medium: 523.7 MB

    The ultrafast file visually looks much worse then the medium one, even so both use the same Quality setting (in fact all settings except the preset setting are the same).

    Just to let you know. Of course if you have any idea about it feedback is welcome ;)
  22. David Moheban on January 21, 2017 - click here to reply
    What about intel 10 bit qsv encoding? Is there such a thing?
    • Matt Gadient on January 21, 2017 - click here to reply
      I don't believe Intel ever added 10-bit H264 hardware encode to any of their processors, though I could be wrong here. Someone can correct me if so. 10-bit HEVC/H265 encoding *did* make it into the Kaby Lake processors recently released though. No idea if Handbrake or anything else support it yet, mind you (no Kaby Lake processors here - my latest is Skylake).
      • David Moheban on January 21, 2017 - click here to reply
        Just run AVX detector and you'll see wether or not the skylake CPU supports 10 bit. I can say my broadwell laptop certainly does according to the utility but it's a slow cpu so don't know how effective that would be. Not sure about the 6700k though. Read it's hybrid support whatever that means. So I suppose if you want 10 bit qsv via Intel in handbrake your going to have to compile it yourself. Not sure how that works but investigating..
  23. Xon on February 6, 2017 - click here to reply
    I used windows.. I have tried everything that written.. nothing work.. when I copy the libx264_main10.dll.. I'll end up geting an error

    help ples
  24. MrT on March 26, 2017 - click here to reply
    Are there any new handbrake-libs-mac ? or handbrake binary for the mac with x265 v2.3?
    • Unfortunately I've been tied up with a bunch of other stuff for quite a while and haven't been able to do much in the encoding arena. However if you want to give it a go yourself I mentioned a few of the steps I took in one of my previous comments. You'll need XCode and a couple programs I believe I had mentioned (as well as the x265 source). If I'm remembering right, I read through some docs in the x265 source as a starting point and muddled my way through from there.
  25. Anonymous on July 3, 2017 - click here to reply
    is there a way to encode 10 bit video without nightly built?
    • It currently doesn't seem to be officially supported, but whether that means "no client support & won't work", or means "client support - might work but unsupported" I don't know.

      Shouldn't be any harm in giving it a try though... If on Windows, grab the DLL's from the forum link in the write-up - if it works, great. If it doesn't, just delete the DLLs. If on Ubuntu, "sudo apt-get install libx265-dev". If on MacOS I don't know if there's anything currently available besides my (rather old) 10-bit-only build.
  26. Anonymous on July 8, 2017 - click here to reply
    Thanks a lot, it works wonderful. Just in case, do you have also the CLI program. I usually used more the command like that the graphic interface.
  27. Silverfox on August 10, 2017 - click here to reply
    Now if I can only find out how to transcode to 4:2:2 chroma or 4:4:4. if anyone knows please leave a comment.
    • Matt Gadient on August 10, 2017 - click here to reply
      I'm guessing toolchain limitations still exclude doing this via HandBrake (someone can correct me if I'm wrong).

      If you're willing to use ffmpeg CLI and are using x264, I believe it can be done via "-profile:v high422" or "-profile:v high444".

      Unsure if 422/444 are available for x265 in ffmpeg yet, but if you wanted to pump it through the x265 CLI I *think* it would be something like: "--profile main444-10 --input-csp i444" (change the 10 to 8/10/12 depending on bits, and 444 to 422 where applicable).

      There may be easier/better options out there, or someone might have a full encode string or toolchain process they use and know works. Hopefully someone can chime in if so. If not, maybe the above will help you get started.
  28. Anonymous on September 30, 2017 - click here to reply
    Great work. Could you provide a build with HLG HDR support i.e. we need transfer characteristic = 18 including. Trying to add it as a parameter in the params box fails. Rec2020 colour space works.
  29. Anonymous on October 5, 2017 - click here to reply
    Use staxrip?
  30. Anonymous on October 31, 2017 - click here to reply
    Haven't read all comments, but HandBrake does not do real 10bit encodings right now, even not with nightly builds and x265_main10.dll. The resulting file is 10bit, right, but it's only dithered 8bit from 10bit Canopus HQX for example since the internal bottleneck seems 8bit. I found a FFmpeg build that has real x265/main10 inside that does real 10bit I can verify in EDIUS/10bit monitor connected to a BMD IP4K using a synthetic greyramp. FFmpeg has smooth gradient, HandBrake only shows 8bit dither even using the x265_main10.dll. Unluckily that FFmpeg build is quite old (x265 v2.0).
  31. Anonymous on January 13, 2018 - click here to reply
    Is this library still viable now?? Or is this outdated??
    • Matt Gadient on January 13, 2018 - click here to reply
      Yeah, getting a bit outdated. The latest nightlies seem to include x265 10-bit and x265 12-bit. So the only reason to dabble with stuff in the write-up is if you're using x264 10-bit. I'll place another update at the top.
  32. Nikhil N. on February 5, 2018 - click here to reply
    Hi Matt, thank you for writing this. I have h264 10-bit and h265 10-bit working on my hackintosh running 10.13.3. Do you reckon I should recompile the dylibs you have provided to get them up to date?
    • Matt Gadient on February 6, 2018 - click here to reply
      It's up to you. Personally I'd tend to avoid the dylibs at this point since they're more messy. The 10-bit only version should be fine for x264 10-bit. x264 doesn't change really substantially these days since it's really mature now and 10-bit x264 will never be mainstream anyway so older versions don't bug me much. For x265, the latest nightlies have 10 and 12-bit built in.

      Short version: I'd avoid the dylibs and use the other options, but ultimately it's up to you.
  33. Matt's fanboy#1 on July 30, 2018 - click here to reply
    Can you make another build base on latest x265 on OSX, mate? I've been using your build since 2016 and I'm hopeful that you can make another build with hi10 in profile.
    • I'm glad to hear it's been holding up for you!

      The build setup I had is unfortunately long gone.

      However, I just took a look and Handbrake now has support for 10-bit (hi10) in their standard releases both for x264 and x265 (just checked in v1.1.1 on macOS). So I'd strongly suggest grabbing from there ( ). If standard releases give an issue for some reason, it may be worth trying the nightlies ( ).
      • Matt's fanboy#1 on July 31, 2018 - click here to reply
        Thanks, sir! Keep up the best work :-D
      • Matt's Fanboy#1 on September 22, 2018 - click here to reply
        It's been a while, mate. I tried using the official HB build, but it's never as fluid as your build. Some of my x265-10bit encoding keeps on breaking on slow to slower presets, but works on medium and lower presets. If you don't mind, can you teach me how to change the CLI on your build? I want to go back using your 2017 build with an updated x265 CLI and see if the same breaking problem occurs.
        • Matt Gadient on September 22, 2018 - click here to reply
          Unfortunately you can't really swap in different versions of the encoders in most cases. The whole thing gets rebuilt. Or, at least, that was the situation when I originally built these, and hence why I had separate builds depending on the encoder.

          So you're probably looking at building a new version.

          The Handbrake devs have been improving the documentation quite a bit over the past years. Your best starting point on the Mac is probably:

          Start by just getting it to build. Nothing fancy, just get things working to start.

          After that, you can start delving into tweaking. To start clean, if you haven't delved into compiling before the simple way to "start fresh" is to delete the Handbrake source folder and start all over again.

          After the git clone bit in the guide, if you'd like to try using a newer or different version of x264/x265, you'll have to edit the appropriate config file to change it. They can be found in places similar to the following within your cloned Handbrake source:

          ...there are similar locations for x265, x265_12bit, x264, x264_10bit, etc.

          The contents will look like this:

          Glancing at it now, some fields you will need to change to whatever other version of X265 you want to try:

          The url will be based on a link to the source of a newer (or older) x265 version you find. The sha256 will require you to find the SHA256SUM of the version you want: can be done with a command line tool if you've manually downloaded it (search web for instructions), or perhaps found near the link you've found on the web to the version you want. The tarbase will probably just need a version number change to match the above.

          Then build the new version. If it doesn't work this time around (but worked during your original build without changes), either something else in the module.defs has to be changed or there's some inherent incompatibility between the version of HandBrake you're using and the version of x264/x265 you're using.

          If you hit other hiccups along the way like a random error message during the build, a quick web search is usually worth trying, as it can sometimes be a simple fix.

          Good luck!
          • Matt's Fanboy#1 on September 23, 2018
            Sweet! Thanks for the quick response. Gotta read the whole thing and I hope I can pick them up fast XD
    • Thanks for letting me know. The old server had died, so files should now be uploading to a new location and be available within the next few hours.

Leave a Comment

You can use an alias and fake email. However, if you choose to use a real email, "gravatars" are supported. You can check the privacy policy for more details.