Support for 8/10/12 bit color depths in HandBrake!

HandBrake is now using a freshly built x265 library that enables full color depth support at 8, 10 and 12 bits. You can now convert videos in these format! This has been enabled in the 64 bit builds of the x265 library; for both Fedora 23 and CentOS/RHEL 7.

Also, NUMA support has been added to the libraries. Just by chance I have an SGI UV 200 (the predecessor of the current SGI UV 300) lying around.

ghb-x265

This goes along with the 10 bit support for x264 that was enabled some time ago; so I’ve made some adjustments to the libraries and now there is more consistency between x264/x265. Both are loaded at runtime by HandBrake:

$ ls -alghs /usr/lib64/libx26*
668K -rwxr-xr-x. 1 root 667K Feb  5 09:55 /usr/lib64/libx264_main10.so
764K -rwxr-xr-x. 1 root 763K Feb  5 09:55 /usr/lib64/libx264.so.148
3.4M -rwxr-xr-x. 1 root 3.4M Feb  5 09:05 /usr/lib64/libx265_main10.so
3.4M -rwxr-xr-x. 1 root 3.4M Feb  5 09:05 /usr/lib64/libx265_main12.so
3.2M -rwxr-xr-x. 1 root 3.2M Feb  5 09:05 /usr/lib64/libx265.so.68

14 thoughts to “Support for 8/10/12 bit color depths in HandBrake!”

  1. Love this repo for Handbrake. Just curious if the latest Fedora 24 build, HandBrake-gui-1.0-28.20160929gitd398531.fc24.x86_64. has some compile dependency error? Every time I’ve tried running it, the encode has crashed whether CLI or GUI. CLI error example:

    Encoding: task 1 of 1, 0.21 %HandBrakeCLI: libFDK/src/fixpoint_math.cpp:439: FIXP_DBL invSqrtNorm2(FIXP_DBL,INT*):…..

    1. Fedora 24 is my daily driver and I’m using HandBrake almost daily. I never had this crash. Can you tell me some details? Encoders used, source file, etc.

  2. Hello and first of all a thousand thanks for your time and all your efforts!

    Today I upgraded to the following two packages, provided by your repo:

    x264-libs     x86_64     1:0.148-2.5c65704.fc23     fedora-HandBrake     473 k
    x265-libs     x86_64     1.8-3.fc23                 fedora-HandBrake     1.5 M

    What I noticed almost immediately is that the encoding speed of Handbrake and FFmpeg suffered enormously after the update. For example: Using HandBrakeCLI to encode a TV-recording of 42 minutes in Standard defintion with the following settings:

    HandBrakeCLI -i inputfile.mpg --format av_mkv --encoder x264 --x264-preset slower --x264-tune film --h264-profile high --h264-level 3.1 --quality 18 --custom-anamorphic --keep-display-aspect --width 720 --height 404 --decomb 14:2:0:4:30 --encopts merange=32 --aencoder fdk_aac --ab 160 -o outputfile.mkv

    Encoding takes about 55-60 minutes with an avg. of 18fps, with the new x264-lib it takes more than 4 hours and the encoding speed keeps falling and falling till it is down to 1,2fps (!!!). It’s the same when I’m using FFmpeg with similar settings:

    ffmpeg -i inputfile.mpg -vcodec libx264 -vf "pp7=2,yadif=1:0,mcdeint=1:0:10,scale=720x404:flags=spline,setdar=16:9, hqdn3d=2:1:1:2" -profile:v high -pix_fmt yuv420p -level 3.1 -preset slower -crf 19 -x264opts merange=32 -psy-rd 1.0:0.25 -acodec libfdk_aac  -b:a 128k outputfile.mkv

    It’s happens with the GUI-Version of Handbrake too and the same happens with x265. Encoding-speed is about ten times slower than before. I downgraded both packages (using the rpmfusion-packages at the moment) and the encoding speed is fine and at the usual level again. I haven’t used 10 or even 12 bit, both encodings and the testing were only at 8bit.

    Anybody experiencing the same issues and any idea what could be the cause why the encoding speed is sooo much slower with the “new” x264/x265 libs with exactly the same settings?

    Thank you!

    1. I suffer from the same problem. The fps speed for x264 (8bit, 10bit) dropped from ~135fps to ~35fps and after a few minutes always freeze. . Never happened before while encoding.

      For now, I’ll just use the old packages 🙁

      1. I’ve enabled Assembler optimizations in the build, can you check that performance is better now? Judging from my tests it seems so; I’ve got a frame rate processing increase. No freeze here.

        1. Hi, x264 and x265 performance are perfect (8 bit | 10bit.
          Unfortunately the pc still freeze after a few minutes using x264 10bit (x265 works fine).

          Just to be sure I tried linking the old library libx26410bit.so.148 to libx264_main10.so (to make it load on HandBrake) and I have the same problem with 10bit encoding.
          Strangly, the conversion goes fine in the terminal using ffmpeg high10 profile with both new and old x264.

          I even tried forcing all the default ffmpeg encode settings (not all are parsed correctly) in the advanced video tab of handbrake but the pc freeze as usual .
          At this point I’m not sure if the problem lies within HandBrake or not. Is there a way to use all the default ffmpeg encode settings in handbrake?

    2. My thanks too for all your efforts!

      I have the same performance problem as Gerhard. I am using x264 via the HandBrake-gui using the iPad preset to take 45 minute episodes from DVD. Encoding has jumped from 8 minutes to 48 minutes. Downgrading x264-libs restored the performance. (FC23, X86_64, Haswell i7).

      # dnf list x264-libs
      Last metadata expiration check performed 1:03:17 ago on Sun Feb  7 15:40:22 2016.
      Installed Packages
      x264-libs.x86_64           0.148-5.20160118git5c65704.fc23           @rpmfusion-free-updates-testing
      Available Packages
      x264-libs.i686             1:0.148-2.5c65704.fc23                    fedora-HandBrake               
      x264-libs.x86_64           1:0.148-2.5c65704.fc23                    fedora-HandBrake

      On a separate note, the x265-libs update causes ldconfig to give an error every time it is run:

      Running transaction
        Upgrading   : x265-libs-1.8-3.fc23.x86_64                                 1/2 
      /sbin/ldconfig: /lib64/libx265.so.68 is not a symbolic link
      
        Cleanup     : x265-libs-1.8-1.fc23.x86_64                                 2/2 
      /sbin/ldconfig: /lib64/libx265.so.68 is not a symbolic link
      
        Verifying   : x265-libs-1.8-3.fc23.x86_64                                 1/2 
        Verifying   : x265-libs-1.8-1.fc23.x86_64                                 2/2 
      
      Upgraded:
        x265-libs.x86_64 1.8-3.fc23                                                   
      
      Complete!
      1. Fixed in the latest update. SONAME in the x265 variants was still libx265.so.68.

        Regarding x264, there were no compilation differences with the previous build, just a rename of the library. So the culprit is probably in the new x264 snapshot that I used. I’ve enabled Assembler optimizations in the build, can you check that performance is better now? Judging from my tests it seems so. If not, I might switch to the master branch of x264 as soon as I have more feedback.

    3. Thank you very much for valuable feedback. The issue with x265 is due to the wrong SONAME in the 10/12 bit variants that wer causing some issues; but this should be fixed in the latest update.
      Regarding x264, there were no compilation differences with the previous build, just a rename of the library. So the culprit is probably in the new x264 snapshot that I used. I’ve enabled Assembler optimizations in the build, can you check that performance is better now? Judging from my tests it seems so. If not, I might switch to the master branch of x264 as soon as I have more feedback.

      1. x264-libs-0.148.3 seems to have restored performance – I am getting 170-190 fps (peaking at about 220) again, just as I was with the rpmfusion library. (With 0.148.2 it was about 20 fps).

        x265-libs-1.8.4 has fixed the SONAME problem.

        So all good again now 🙂

Leave a Reply