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.
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
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*):…..
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.
Hi,
I use several of your repositories. They make using Fedora a lot better experience. There’s is though one pain point SimpleScreenRecorder. By any chance you would considering creating a repo for it. SSR is already available in Russian repo but that is a humongous repo.
https://github.com/MaartenBaert/ssr
Thank you.
hi,
can someone explain how to use this on handbreak
i have no idea.
thanks
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles
Just select the video encoder you want to use from the Video tab or learn the command line of x265/x264/ffmpeg.
Yes, everything works fine again! Thank you for fixing the problem so quickly!
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:
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:
Encoding takes about 55-60 minutes with an avg. of 18fps, with the new
x264-libit 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: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!
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 🙁
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.
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?
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).
On a separate note, the x265-libs update causes ldconfig to give an error every time it is run:
Fixed in the latest update.
SONAMEin the x265 variants was stilllibx265.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.
Thank you very much for valuable feedback. The issue with x265 is due to the wrong
SONAMEin 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.
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 🙂