x265 HEVC Encoder

[-Habanero-]

I couldn't find linux binaries until now so I thought I would have to compile them myself. This is only a test run anyway, I wanna see if I can speed up my x265 encoding plus have the ability to pause and resume anytime since it's a VM.

But anyway, is the RPM the executable or what? How do I get started with this thing?

[LigH.de]

No, an RPM is an "installable package" (more or less comparable to Microsoft Installer packages, *.msi). It has to be installed with the package manager of your Linux distro. Afterwards, a "x265" executable will be available in your system.

[-Habanero-]

I see. Now I hate to ask a question as retarded as this one but, where would the executable be? Because I installed it.

[Selur]

where would the executable be? Because I installed it.

typically under /usr/bin or /usr/share

[LigH.de]

I rarely use Linux; but I believe there are commands like "which" or "locate".

SuSE often prefers /opt over /usr, AFAIR.

In fact, it is not even really important to know where x265 is located, as long as it is executable everywhere via the PATH.

[-Habanero-]

Damn, I forgot about avs2x26x, is this a windows-only app or can it also work on linux?

And x265 was in /usr/bin Thanks for the pointer.

[Selur]

avs2x26x should work when using Wine (you would also need to install Avisynth under Wine)

[-Habanero-]

Yet more emulation? Screw that. I realized Avxsynth is native for Linux and that it comes with a frameserver.
I'll post results later.

[LigH.de]

Reading Y4M and piping (e.g. out of ffmpeg) works in Linux just as well as in Windows.

AviSynth is a Windows-only framerserver; AvxSynth is a Linux pendant. VapourSynth will run in both worlds (based on Python).

[-Habanero-]

I know that but frameserving is a lot more convenient than having to output a huge 50GB file every time. Pfft, what am I even saying I already outputted a 50GB MagicYUV AVI file. >.<

x265 keeps coming to a "encoded 0 frames" end, though. Anyone know what I can use to verify that my AVS script is working? Installing codecs on linux is a mindf*ck. VLC can't play ANYTHING and it wasn't until I specifically installed a MagicYUV plugin that it could play that specific format. And I could only install the CLI version of Avidemux.

[LigH.de]

MagicYUV is closed-source; no application using libavformat can decode it.

You may have used the Ut Codec Suite instead, or FFV1, or Huffyuv as last and quite compatible alternative.

And without a verbose quote of your script source, there is little chance to help.

Apart from that, this is a thread about the x265 encoder, not about how to use frameservers. It would deserve a separate thread to explain such details.

[-Habanero-]

Oh, here we go...
I'm gonna abandon frameserving for now because it doesn't look like it's worth the effort.

Can AVS scripts be turned into Y4M files, is there a generalized method to convert anything to Y4M?
I don't mind creating another 50GB file.

Apart from that, this is a thread about the x265 encoder, not about how to use frameservers. It would deserve a separate thread to explain such details.

My bad, I realize. But the reason I'm asking is so I can get this to work and post the results. I genuinely wanna see if virtualized linux can encode x265 faster.

[poisondeathray]

Can AVS scripts be turned into Y4M files, is there a generalized method to convert anything to Y4M?
I don't mind creating another 50GB file.

Yes, one way is to use ffmpeg to convert to a physical Y4M file instead of piping. But if your magicyuv file was 50GB, the Y4M is going to be much larger . And you should repeat the tests using the Y4M on windows then . There are speed differences between various piping methods,vs frameserving, vs. Y4M (also there are IO transfer considerations)

[-Habanero-]

Hopefully not that much bigger, I'm running out of HDD space. I tried ffmpeg but my script isn't working (but returning no error)

ffmpeg -y -i "M:\ng2.avi" -threads 8 -an -r 601/10 -pix_fmt yuv420p -f y4m -o ng2.y4m

[poisondeathray]

There should be an error message because -o isn't the syntax for "output" in ffmpeg , like it is for x264 or x265

ffmpeg -i input.ext -c:v rawvideo -an output.y4m

[-Habanero-]

Thank you PDR, that produced a legit y4m file. But I can't seem to do 10-bit encoding. If I add -D 10 x265 warns me it's reverting to the default bit depth.
The version I first downloaded seemed to be an 8-bit one so I tried compiling it myself as per https://bitbucket.org/multicoreware/x265/wiki/Home instructions but now I'm not sure it compiled right. Do I need to change one of the source files so it compiles with 10-bit support?

[LigH.de]

You can either build specialized executables (with only either 8 bit or 10 bit or 12 bit color depth) plus dynamically loadable libraries with support for the additional bit depths (libx265_main, libx265_main10, libx265_main12 -- recognized by their name, extension may be .dll or .a in relation to the OS); or you build a complex "multi library executable" which contains code for all three currently supported bit depths in the same executable file. Check the shell script "build/linux/multilib.sh" which comes in the source repository if you 'clone' this one using Mercurial (hg), as documented on the x265 developers' website.

[LigH.de]

^ P.S.:

Just tried to build x265 in Ubuntu 15 and found some additions: You may want to install NUMA support and YASM 1.3.0 prior to starting the compilation of x265.

sudo apt-get install libnuma-dev

YASM 1.3.0 AMD64 for Ubuntu Trusty (let the Ubuntu Software Center take the installation of yasm_1.3.0_amd64.deb)
__

The compiler will build a shared object with a specific build number and a generic link to it (libx265.so => libx265.so.68); I wonder if such files are "distributable" as easily as *.dll files for Windows. Someone may have to explain to me the rules how this should be prepared and packaged if I wanted to offer such binaries. For now I will refrain from it, I am just curious how to, in case I felt like doing so some day.
__

Apparently, the separate executables are only linked as stubs (<90 KB). Checking later if a multilib executable will contain more... but I believe there was some trouble getting the linker work the same way as for a Windows target.
__

No, the executable is a stub as well (no completely static binary), just the libx265.so contains all three encoder libraries.

[-Habanero-]

I am using openSUSE, not Ubuntu. There was no libnuma package. I'll have to find a different equivalent.

But anyway, I did try to run multilib.sh and this failed to produce anything but an 8-bit x265. I do appear to have a libx265.so.59 in the /usr/lib and /usr/lib64 directory though but I think these are 8-bit only otherwise there'd be more.

[LigH.de]

The multilib compilation will package the 8-bit, 10-bit, and 12-bit encoder library into a common libx265.a and a common libx265.so{.68} inside the "x265/build/linux/8bit" subdirectory, together with an x265 stub binary. Unfortunately, it appears not to link everything into a real static x265 binary. And it does not yet install the result into your system; that requires an additional

sudo make install

inside the "x265/build/linux/8bit" subdirectory after the multilib.sh finished. This will copy libx265.a and libx265.so{.68} into /usr/local/lib, and the x265 stub into /usr/local/bin (at least here under Ubuntu GNOME, OpenSuSE locations may differ?), among several additional package information files.

[-Habanero-]

It indeed copied libx265.a and libx265.so.59 to /usr/local/lib but the x265 stub is in /usr/bin, there is no local/bin folder in openSUSE.
It still seems to be the 8bpp build, though. I tried sudo make install in both the 8bit and 10bit dirs.

[LigH.de]

Why do you have such a very old version (core 59 vs. core 68)? Did you not compile the most recent sources cloned by Mercurial?
__

Running "sudo make install" in a really current build version installed into the local directories, which does not work correctly unless you update the library registration (sudo ldconfig) and possibly do some more things; qyot27 suggested checkinstall to care about packaging as well. That's beyond my knowledge.

[-Habanero-]

I don't know, I followed the instructions on that x265 page

# ubuntu packages:
$ sudo apt-get install mercurial cmake cmake-curses-gui build-essential yasm
# Note: if the packaged yasm is older than 1.2, you must download yasm (1.3 recommended) and build it

$ hg clone https://bitbucket.org/multicoreware/x265
$ cd x265/build/linux
$ ./make-Makefiles.bash
$ make

except instead of "apt-get" I type "zypper" which is the equivalent in opensuse. The timestamp on x265 stub says 7/26/2015 so I assumed it was a modern version. x265 --version won't tell me the exact one, just that it's 1.7 and 8bpp.

[LigH.de]

except instead of "apt-get" I type "zypper" which is the equivalent in opensuse.

Shouldn't be a problem, as long as all packets are installed.

x265 --version won't tell me the exact one, just that it's 1.7 ...

That's disturbing. Using hg, cmake should detect the exact version+patch values.

... and 8bpp.

That's normal for a simple "./make-Makefiles.bash"; you should have used "./multilib.sh" instead.

[-Habanero-]

Finally got this to work, god damn.

The problem was that I didn't have yasm 1.3 like I thought. When I searched it up, I clicked to install what I thought was yasm 1.3 but it was yasm 1.2 for OpenSUSE 13.1 so I confused it with yasm 1.3 for 13.2 which I should've gotten instead. But looking at it now there's only experimental builds for 13.2. Oh well.

But even after that I had to manually copy libx265.so.68 from usr/local/lib to usr/lib otherwise x265 couldn't find it. And now I'm happy to say that I think it works. It says it's encoding to 10-bit when I tell it, but something's weird.
On my Windows 7, 8-bit processing on this video is 5 fps and 2.73 on this openSUSE VM yet the 10-bit on Windows was 0.77 fps and 2.36 on openSUSE. How can 10-bit processing be only a bit slower? Logically, it should be 4 times slower, no?

Here's the log of my whole adventure:

linux-hvhv:~/x265/build/linux # ./multilib.sh                                   
-- cmake version 3.0.2                                                          
-- Detected x86 target processor                                                
-- Could NOT find NUMA (missing:  NUMA_ROOT_DIR NUMA_INCLUDE_DIR NUMA_LIBRARY)  
-- Found yasm: /usr/bin/yasm (found version "1.3.0") 
-- Found Yasm 1.3.0 to build assembly primitives
-- hg found at /usr/bin/hg
-- x265 version 1.7+390-3fa7f6838098
-- Configuring done
-- Generating done
-- Build files have been written to: /root/x265/build/linux/12bit
[ 72%] Built target common
[100%] Built target encoder
[100%] Built target x265-static
-- cmake version 3.0.2
-- Detected x86 target processor
-- Could NOT find NUMA (missing:  NUMA_ROOT_DIR NUMA_INCLUDE_DIR NUMA_LIBRARY) 
-- Found yasm: /usr/bin/yasm (found version "1.3.0") 
-- Found Yasm 1.3.0 to build assembly primitives
-- hg found at /usr/bin/hg
-- x265 version 1.7+390-3fa7f6838098
-- Configuring done
-- Generating done
-- Build files have been written to: /root/x265/build/linux/10bit
[ 72%] Built target common
[100%] Built target encoder
[100%] Built target x265-static
-- cmake version 3.0.2
-- Detected x86 target processor
-- Could NOT find NUMA (missing:  NUMA_ROOT_DIR NUMA_INCLUDE_DIR NUMA_LIBRARY) 
-- Found yasm: /usr/bin/yasm (found version "1.3.0") 
-- Found Yasm 1.3.0 to build assembly primitives
-- hg found at /usr/bin/hg
-- x265 version 1.7+390-3fa7f6838098
-- Configuring done
-- Generating done
-- Build files have been written to: /root/x265/build/linux/8bit
[ 63%] Built target common
[ 87%] Built target encoder
[ 87%] Built target x265-shared
[100%] Built target cli
[100%] Built target x265-static
linux-hvhv:~/x265/build/linux # sudo make install
make: *** No rule to make target 'install'.  Stop.
linux-hvhv:~/x265/build/linux # cd 8bit
linux-hvhv:~/x265/build/linux/8bit # sudo make install
[ 63%] Built target common
[ 87%] Built target encoder
[ 87%] Built target x265-shared
[100%] Built target cli
[100%] Built target x265-static
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/lib/libx265.a
-- Installing: /usr/local/include/x265.h
-- Installing: /usr/local/include/x265_config.h
-- Installing: /usr/local/lib/libx265.so.68
-- Installing: /usr/local/lib/libx265.so
-- Installing: /usr/local/lib/pkgconfig/x265.pc
-- Installing: /usr/local/bin/x265
-- Removed runtime path from "/usr/local/bin/x265"
linux-hvhv:~/x265/build/linux/8bit # x265 --version
x265: error while loading shared libraries: libx265.so.68: cannot open shared object file: No such file or directory
linux-hvhv:~/x265/build/linux/8bit # cd
linux-hvhv:~ # x265 --version
x265: error while loading shared libraries: libx265.so.68: cannot open shared object file: No such file or directory
linux-hvhv:~ # 
linux-hvhv:~ # cp /usr/local/lib/libx265.so.68 /usr/lib/
linux-hvhv:~ # cp /usr/local/lib/libx265.so.68 /usr/lib64/
linux-hvhv:~ # x265 --version
x265 [info]: HEVC encoder version 1.7+390-3fa7f6838098
x265 [info]: build info [Linux][GCC 4.8.3][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64

And here are the tests:

Windows 7 8-bit:

M:\>x265 --y4m "ng2.y4m" --crf 26 --preset veryslow --ref 16 --bframes 16 --keyint 600 --no-psy-rd -
-no-psy-rdoq --rc-lookahead 250 --qcomp 0.7 --allow-non-conformance -o "ng2.hevc"
y4m  [info]: 256x224 fps 601/10 i420p8 frames 0 - 2333 of 2334
raw  [info]: output file: ng2.hevc
x265 [info]: HEVC encoder version 1.7+371-24c1ee516d13
x265 [info]: build info [Windows][GCC 4.9.2][32 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x265 [warning]: level 2.1 detected, but NumPocTotalCurr (total references) is non-compliant
x265 [info]: NONE profile, Level-NONE (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features       : 3 / wpp(4 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut       : 60 / 600 / 40
x265 [info]: Lookahead / bframes / badapt        : 250 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 16 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 64 / 1
x265 [info]: Rate Control / qCompress            : CRF-26.0 / 0.70
x265 [info]: tools: rect amp rd=6 rdoq=2 signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao
x265 [info]: frame I:      4, Avg QP:27.25  kb/s: 6580.83
x265 [info]: frame P:    307, Avg QP:29.12  kb/s: 487.85
x265 [info]: frame B:   2023, Avg QP:35.82  kb/s: 144.79
x265 [info]: Weighted P-Frames: Y:0.7% UV:0.3%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.3%
x265 [info]: consecutive B-frames: 2.9% 2.9% 0.6% 7.1% 8.7% 32.5% 6.1% 3.2% 5.8% 18.0% 1.9% 0.6% 1.3
% 4.8% 0.3% 0.0% 3.2%

encoded 2334 frames in 465.00s (5.02 fps), 200.94 kb/s, Avg QP:34.93

Windows 7 10-bit:

M:\>x265 --y4m "ng2.y4m" -D 10 --crf 26 --preset veryslow --ref 16 --bframes 16 --keyint 600 --no-ps
y-rd --no-psy-rdoq --rc-lookahead 250 --qcomp 0.7 --allow-non-conformance -o "ng210.hevc"
y4m  [info]: 256x224 fps 601/10 i420p8 frames 0 - 2333 of 2334
raw  [info]: output file: ng210.hevc
x265 [info]: HEVC encoder version 1.7+371-24c1ee516d13
x265 [info]: build info [Windows][GCC 4.9.2][32 bit][noasm] 10bit
x265 [info]: using cpu capabilities: none!
x265 [warning]: level 2.1 detected, but NumPocTotalCurr (total references) is non-compliant
x265 [info]: NONE profile, Level-NONE (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features       : 3 / wpp(4 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut       : 60 / 600 / 40
x265 [info]: Lookahead / bframes / badapt        : 250 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 16 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 64 / 1
x265 [info]: Rate Control / qCompress            : CRF-26.0 / 0.70
x265 [info]: tools: rect amp rd=6 rdoq=2 signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao
x265 [info]: frame I:      4, Avg QP:27.65  kb/s: 6033.20
x265 [info]: frame P:    308, Avg QP:29.57  kb/s: 466.46
x265 [info]: frame B:   2022, Avg QP:35.68  kb/s: 146.89
x265 [info]: Weighted P-Frames: Y:0.6% UV:0.3%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.3%
x265 [info]: consecutive B-frames: 1.9% 3.2% 1.0% 6.4% 9.6% 33.3% 8.0% 2.6% 5.1% 17.0% 1.0% 0.6% 1.3
% 5.4% 0.3% 0.0% 3.2%

encoded 2334 frames in 3022.88s (0.77 fps), 199.15 kb/s, Avg QP:34.86

Linux VM 8-bit:

linux-hvhv:~ # x265 --y4m /home/admin/Desktop/M/ng2.y4m --crf 26 --preset veryslow --ref 16 --bframes 16 --keyint 600 --no-psy-rd --no-psy-rdoq --rc-lookahead 250 --qcomp 0.7 --allow-non-conformance -o /home/admin/Desktop/M/ng2L8.hevc
y4m  [info]: 256x224 fps 601/10 i420p8 frames 0 - 2333 of 2334
raw  [info]: output file: /home/admin/Desktop/M/ng2L8.hevc
x265 [info]: HEVC encoder version 1.7+390-3fa7f6838098
x265 [info]: build info [Linux][GCC 4.8.3][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x265 [warning]: level 2.1 detected, but NumPocTotalCurr (total references) is non-compliant
x265 [info]: NONE profile, Level-NONE (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features       : 2 / wpp(4 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut       : 60 / 600 / 40
x265 [info]: Lookahead / bframes / badapt        : 250 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 16 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-26.0 / 0.70
x265 [info]: tools: rect amp rd=6 rdoq=2 signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao
x265 [info]: frame I:      4, Avg QP:27.51  kb/s: 6599.10                       
x265 [info]: frame P:    307, Avg QP:29.68  kb/s: 495.26  
x265 [info]: frame B:   2023, Avg QP:36.24  kb/s: 143.85  
x265 [info]: Weighted P-Frames: Y:0.7% UV:0.3%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.3%
x265 [info]: consecutive B-frames: 2.9% 2.9% 0.6% 7.1% 8.7% 32.5% 6.1% 3.2% 5.8% 18.0% 1.9% 0.6% 1.3% 4.8% 0.3% 0.0% 3.2% 

encoded 2334 frames in 853.92s (2.73 fps), 201.13 kb/s, Avg QP:35.37

Linux VM 10-bit:

linux-hvhv:~ # x265 --y4m /home/admin/Desktop/M/ng2.y4m -D10 --crf 26 --preset veryslow --ref 16 --bframes 16 --keyint 600 --no-psy-rd --no-psy-rdoq --rc-lookahead 250 --qcomp 0.7 --allow-non-conformance -o /home/admin/Desktop/M/ng2L10.hevc
y4m  [info]: 256x224 fps 601/10 i420p8 frames 0 - 2333 of 2334
raw  [info]: output file: /home/admin/Desktop/M/ng2L10.hevc
x265 [info]: HEVC encoder version 1.7+390-3fa7f6838098
x265 [info]: build info [Linux][GCC 4.8.3][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x265 [warning]: level 2.1 detected, but NumPocTotalCurr (total references) is non-compliant
x265 [info]: NONE profile, Level-NONE (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features       : 2 / wpp(4 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut       : 60 / 600 / 40
x265 [info]: Lookahead / bframes / badapt        : 250 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 16 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-26.0 / 0.70
x265 [info]: tools: rect amp rd=6 rdoq=2 signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao
x265 [info]: frame I:      4, Avg QP:27.44  kb/s: 6270.47                       
x265 [info]: frame P:    308, Avg QP:29.94  kb/s: 515.54  
x265 [info]: frame B:   2022, Avg QP:36.07  kb/s: 151.58  
x265 [info]: Weighted P-Frames: Y:0.6% UV:0.3%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.3%
x265 [info]: consecutive B-frames: 1.9% 3.2% 1.0% 6.4% 9.6% 33.3% 8.0% 2.6% 5.1% 17.0% 1.0% 0.6% 1.3% 5.4% 0.3% 0.0% 3.2% 

encoded 2334 frames in 990.23s (2.36 fps), 210.10 kb/s, Avg QP:35.25

So the 8-bit is twice as slower in the VM likely due to virtualization overhead.
But interestingly the 10-bit is three times faster despite being a 64-bit VM in a 32-bit host.

[LigH.de]

-- Build files have been written to: /root/x265/build/linux/12bit

You never fail to surprise.

Finally got this to work, god damn.

The problem was that I didn't have yasm 1.3 like I thought. When I searched it up, I clicked to install what I thought was yasm 1.3 but it was yasm 1.2 ...

Should not be the worst problem. YASM 1.2 is the required minimum, just a fair bit slower. YASM 1.3 got some enlarged hash tables.

But even after that I had to manually copy libx265.so.68 from usr/local/lib to usr/lib otherwise x265 couldn't find it.

It is possible to register libraries in local directories; this may require a:

sudo ldconfig

How can 10-bit processing be only a bit slower? Logically, it should be 4 times slower, no?

No.

32-bit 10-bit does not use Assembler optimized routines, therefore it is a lot slower than Assembler optimized 8-bit routines.

64-bit 10-bit is just as Assembler optimized as 64-bit 8-bit.

[-Habanero-]

You never fail to surprise.

Lol, did I do something wrong? I followed instructions exactly as it said on the page (except for getting the wrong version of YASM).

Should not be the worst problem. YASM 1.2 is the required minimum, just a fair bit slower. YASM 1.3 got some enlarged hash tables.

I don't know then. I didn't do anything different the second time except the fact that I had YASM 1.3.

It is possible to register libraries in local directories; this may require a:

sudo ldconfig

I did try that command before the yasm problem came to light but now I forget which order I did it in.

No.

32-bit 10-bit does not use Assembler optimized routines, therefore it is a lot slower than Assembler optimized 8-bit routines.

64-bit 10-bit is just as Assembler optimized as 64-bit 8-bit.

Nonono, I'm talking about the 64-bit 8-bit vs. 64-bit 10-bit. One was 2.73 fps one was 2.36 fps. That's unusual.

[LigH.de]

I wondered why your build path is located in /root/... – that should be very unusual; it should be located below your home (~) too.
__

The very similar speed is not that unusual.

32-bit 10-bit is a lot slower than 32-bit 8-bit because it lacks of SSE instructions.

64-bit 10-bit is just as optimized with SSE and even AVX2 as 64-bit 8-bit; there should not be any surprise that it is almost as fast, except for the larger amount of data to be processed.

[-Habanero-]

I wondered why your build path is located in /root/... – that should be very unusual; it should be located below your home (~) too.
__

The very similar speed is not that unusual.

32-bit 10-bit is a lot slower than 32-bit 8-bit because it lacks of SSE instructions.

64-bit 10-bit is just as optimized with SSE and even AVX2 as 64-bit 8-bit; there should not be any surprise that it is almost as fast, except for the larger amount of data to be processed.

What would be the correct path? Maybe it's an exclusive opensuse thing.

And that larger amount of data to be processed should be exactly 4 times more cuz 10-bit has 4 times more calculations to do, no?

Many thanks for the heads up about multilib.sh and the windows binaries though.

[LigH.de]

The "hg clone ..." should have happened in your "/home/login" directory (or brief: '~'), so the build path should have been

/home/login/x265/build/linux (verbosely)

or

~/x265/build/linux (abbreviated)

but certainly not

/root/x265/build/linux (as /root/ is a protected directory).
__

I don't know why you believe there are 4 times as many calculations for 10-bit-depth code compared to 8-bit-depth code. This is certainly not true, as practice prooves. For 10 bit depth, you will need instructions working with 16 bit values instead of 8 bit values, and additionally a few reductions to at most 10 significant bits out of 16.

The reason why 32-bit code for 10 bit depth takes 4 times as long as 32-bit code for 8 bit depth is simply:

32-bit code for 8 bit depth uses assembler optimization with MMX / SSE instructions.

32-bit code for 10 bit depth uses C code only.

64-bit code for 8 bit depth uses assembler optimization with MMX / SSE instructions too, and also more and wider registers.

64-bit code for 10 bit depth uses assembler optimization with MMX / SSE instructions too, and also more and wider registers.