Andrea, I appreciate the additional testing and results you provided since it is a key library. Some commentary below.

...

Test renderings, using x265, work fine, except using the 10-bit and 12-bit presets fail indicating that those pixel formats are not supported by x265 encoder. Using the multibit appimage (without the new patch), the 12- and 10-bit renderings work, but the vaapi preset does not.

To get 10-bit and 12-bit you have to apply

./thirdparty/compile_multibit_x265.txt and move the 3 patch files WITH the new names (i.e. instead of 3.5, the 17122023) to subdirectory ./thirdparty/src and then do a build. BUT I have not checked to see if the line numbers are still valid in the patchsets. I will try that late today or else tomorrow. Probably the vaapi preset does not work because I created the appimage on a laptop with an out of date vaapi.

...

I wonder if the separation between multibit and non-multibit versions is still necessary.

well, I thought multilib build was slower, not at rendering but at build itself ? It up to Phyllis to decide ....

I will test this again, but I do some many builds in a single day, it just

slows me down a lot and my laptop sometimes overheats too.

ср, 20 дек. 2023 г., 05:18 Phyllis Smith <[email protected]>:

Test renderings, using x265, work fine, except using the 10-bit and

...

...

...

12-bit presets fail indicating that those pixel formats are not supported by x265 encoder. Using the multibit appimage (without the new patch), the 12- and 10-bit renderings work, but the vaapi preset does not.

To get 10-bit and 12-bit you have to apply ./thirdparty/compile_multibit_x265.txt and move the 3 patch files WITH the new names (i.e. instead of 3.5, the 17122023) to subdirectory ./thirdparty/src and then do a build. BUT I have not checked to see if the line numbers are still valid in the patchsets. I will try that late today or else tomorrow.

Andrea, I tested and if you have any extra time to run some timings to see if faster, that would be great. I only rendered 1 h265-12bit.mp4 and did not comparisons. However, comparing a build with a multibit appimage may not be useful as appimage might be slower overall. The patch set as described above works as is EXCEPT you will have to edit ./thirdparty/Makefile by hand -- around line 268, delete the x265.cfg lines and substitute this line instead: x265.cfg_vars?=chmod +x ./configure; chmod +x ./multilib.sh;

So you will see these lines around that area:

twolame.cfg_params?=--enable-shared=no x264.cfg_params?= --enable-static --enable-pic x265.cfg_vars?=chmod +x ./configure; chmod +x ./multilib.sh; libvpx.cfg_params?= --enable-pic --disable-avx512 --enable-vp9-highbitdepth --disable-examples --disable-unit_tests libdpx.cfg_vars?= libtoolize; aclocal; autoconf; automake -a;

may be I can add some if-conditional based on configure.ac argument ... thanks for testing and reminding me about this.

...

I wonder if the separation between multibit and non-multibit versions

...

...

is still necessary.

well, I thought multilib build was slower, not at rendering but at build itself ? It up to Phyllis to decide ....

I will test this again, but I do some many builds in a single day, it just slows me down a lot and my laptop sometimes overheats too.

I ran 2 test builds. On my "gaming computer" laptop (on which I have never played a game), it takes 10 1/2 minutes to compile multibit and only 7 minutes without it. That does not seem like much, but it fits my Buddy breaks nicely.

We "game" by building software and catching up with sometimes breaking updates! :)

ср, 20 дек. 2023 г., 12:35 Andrea paz <[email protected]>:

I tried compiling the multibit version with Phyllis' instructions (which are also found in the manual:

https://cinelerra-gg.org/download/CinelerraGG_Manual/Multibit_build_x265_8_1... ). With Andrew's new patch "x265-17122023" I have a crash. I attach the cin5_patch.log.

it seems patch failed to apply ... chmod: impossibile accedere a './multilib.sh': File o directory non esistente Without the new patch the build works. I have a Ryzen 5900XT 12c/24t.

I generally compile in just over 3 min. Multibit took a little over 4 min. NOTE: By applying the "compile_multibit_X265.txt" there is no need to manually edit ../thirdparty/Makefile, it is done automatically.

I compared the appimage (without new patch) multibit with the build (without new patch) multibit: I get the same rendering results. The only difference, as Phyllis had explained, is that in my build the hevc.mp4 preset also works while in the appimage it does not.

I didn't realize that patch 0010-... brought the Makefile back to the origin, sorry. Now with patches 0010-... and 0013-... the compilation of the multibit version happens successfully; thanks. I didn't understand what the 17122023 patch brings again. The tests I did make the rendering of x265-12bit and the rendering of hevc_vaapi much faster, similar to the values I had found for the non-multibit build (again with the patch). Even the x265-hi preset is as fast as the non-multibit version. You did a great job, thank you. PS1: compile time is still just over 4 min, on my system. PS2: I report the strings I get when I apply the patches, even though they work fine: 0010-... $ patch -p2 < 0010-Update-x265-to-git-snapshot-17122023.patch patching file blds/termux.bld Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file blds/termux.bld.rej patching file configure.ac patching file thirdparty/Makefile Hunk #1 FAILED at 266. 1 out of 1 hunk FAILED -- saving rejects to file thirdparty/Makefile.rej 0013-... $ patch -p2 < 0013-Multibit-x265-patches-updated-for-x265-17122023.patch patching file thirdparty/Makefile Hunk #1 FAILED at 265. 1 out of 1 hunk FAILED -- saving rejects to file thirdparty/Makefile.rej patching file thirdparty/src/x265-17122023.patch1 patching file thirdparty/src/x265-17122023.patch2 patching file thirdparty/src/x265-17122023.patch3

...

I didn't understand what the 17122023 patch brings again. Without the patch you can not render 10 or 12 bit.

I meant whether the 0010 patch only served termux or changed the libraries as well, because I experienced a very high rendering speed increase (about 10/20 fps more). That's a very big jump (and welcome!).

I am trying to get 3 things all ready to test on other systems -- HDR, libaom 3.8, and x265 -- so when I do, I will check to make sure multibit compile works there too and make it a default. Even if it takes longer for me. At one point I thought that if you rendered 8-bit on the multibit x265, it would result in a bigger file than on the build non-multibit system. But I did a render test today and the files were exactly the same.

As you said, for me also the size of the files obtained with the multibit and std versions is identical, as is the quality (to the eye) of the video. The rendering speed is similar (just faster the std version, but by a little). I would be for eliminating the std version and using only the multibit, but on this point I would like to hear everyone's opinion. @Andrew: could you tell me again all the patches to use to test libaom? @Phyllis: the build times depend only on the CPU, why don't you use the more equipped system (the Epyc)? You would do builds in 1 to 2 minutes, versus 7 to 10 minutes on the laptop. You could virtualize the various distros by giving them as much CPU and RAM.

...

I am trying to get 3 things all ready to test on other systems -- HDR, libaom 3.8, and x265 -- so when I do, I will check to make sure multibit compile works there too and make it a default. Even if it takes longer for me. At one point I thought that if you rendered 8-bit on the multibit x265, it would result in a bigger file than on the build non-multibit system. But I did a render test today and the files were exactly the same.

As you said, for me also the size of the files obtained with the multibit and std versions is identical, as is the quality (to the eye) of the video. The rendering speed is similar (just faster the std version, but by a little). I would be for eliminating the std version and using only the multibit, but on this point I would like to hear everyone's opinion.

Compiling with multibit on Ubuntu 16, results in an Error in the log file, although it seems to work anyway. Errors are: ./libx265_main12.a(api.cpp.o): In function `x265_12bit::x265_api_get_208(int)': api.cpp:(.text+0x2004): undefined reference to `dlopen' api.cpp:(.text+0x201c): undefined reference to `dlsym' api.cpp:(.text+0x20ad): undefined reference to `dlopen' ./libx265_main12.a(api.cpp.o): In function `x265_12bit::x265_api_query(int, int, int*)': api.cpp:(.text+0x2167): undefined reference to `dlopen' api.cpp:(.text+0x217f): undefined reference to `dlsym' api.cpp:(.text+0x224d): undefined reference to `dlopen' collect2: error: ld returned 1 exit status make[5]: *** [x265] Error 1 make[4]: *** [CMakeFiles/cli.dir/all] Error 2 make[3]: *** [all] Error 2 Have not tested Debian 9.1 32-bit yet as am getting hung up on cause of error.

пт, 22 дек. 2023 г., 00:58 Phyllis Smith <[email protected]>:

...

...

I am trying to get 3 things all ready to test on other systems -- HDR, libaom 3.8, and x265 -- so when I do, I will check to make sure multibit compile works there too and make it a default. Even if it takes longer for me. At one point I thought that if you rendered 8-bit on the multibit x265, it would result in a bigger file than on the build non-multibit system. But I did a render test today and the files were exactly the same.

As you said, for me also the size of the files obtained with the multibit and std versions is identical, as is the quality (to the eye) of the video. The rendering speed is similar (just faster the std version, but by a little). I would be for eliminating the std version and using only the multibit, but on this point I would like to hear everyone's opinion.

Compiling with multibit on Ubuntu 16, results in an Error in the log file, although it seems to work anyway. Errors are: ./libx265_main12.a(api.cpp.o): In function `x265_12bit::x265_api_get_208(int)': api.cpp:(.text+0x2004): undefined reference to `dlopen' api.cpp:(.text+0x201c): undefined reference to `dlsym' api.cpp:(.text+0x20ad): undefined reference to `dlopen' ./libx265_main12.a(api.cpp.o): In function `x265_12bit::x265_api_query(int, int, int*)': api.cpp:(.text+0x2167): undefined reference to `dlopen' api.cpp:(.text+0x217f): undefined reference to `dlsym' api.cpp:(.text+0x224d): undefined reference to `dlopen' collect2: error: ld returned 1 exit status make[5]: *** [x265] Error 1 make[4]: *** [CMakeFiles/cli.dir/all] Error 2 make[3]: *** [all] Error 2

sounds like at least one shared lib was missing from final linking stage,like "-ldl". For me on termux another android-specific files was missed, so I added this file to ffmpeg-specific env. variable before configure in termux.bld and disabled cli x265 encoder (because ffmpeg need just *.a library). I guess you can change x265 multibit patch3 , last cmake line +cd ../8bit +ln -sf ../10bit/libx265.a libx265_main10.a +ln -sf ../12bit/libx265.a libx265_main12.a +cmake ../source -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DENABLE_SHARED=OFF -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON by adding also DENABLE_CLI=OFF like in previous entry.

Have not tested Debian 9.1 32-bit yet as am getting hung up on cause of error.

чт, 28 дек. 2023 г., 04:27 Phyllis Smith <[email protected]>:

Checked into GIT x265 updated snapshot of 17122023, along with modified 0013-Multibit...patch as Andrew provided WITH NEW NAME of x265_3.517122023 because until x265_3.5 is deleted in thirdparty/src, the configure file requires a bigger number so that tar file is used.

Modified patch3 as recommended below for the Multibit patchset.

As Andrea has recommended, I am OK with making multibit automatically the default rather than separate IF CAN FIX THE "syntax error" that I found out is not only in ubuntu 16 but is in what I use as the Fedora baseline build. Partial log below:

cmake version 3.17.4 -- The C compiler identification is GNU 10.3.1 -- The CXX compiler identification is GNU 10.3.1 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc - works -- ...

/bin/sh: -c: line 0: syntax error near unexpected token `(' /bin/sh: -c: line 0: `cmake version 3.17.4 -- The C compiler identification is GNU 10.3.1 -- The CXX compiler identification is GNU 10.3 ...

...

make[3]: [Makefile:4: all] Error 1 (ignored)

make[3]: Leaving directory '/mnt0/build5/cinelerra-5.1/thirdparty/x265_3.517122023'

Will send full log file to see if Andrew knows what it is.

I guess I should study bash a bit more :) because I think this is error I created unintentionally and ignored so far. Thanks, and I hope you are not jumping over yourself for doing this for us especially now. According to weather prognosis we will have like "-20 C" right at 1st January, so I think buying a bit more storable food will be good idea, even if usually 10-15 min walk to food store (separate from dog walks) is not a problem. Be careful!

...

...

Compiling with multibit on Ubuntu 16, results in an Error in the log file, although it seems to work anyway. Errors are: ./libx265_main12.a(api.cpp.o): In function `x265_12bit::x265_api_get_208(int)': api.cpp:(.text+0x2004): undefined reference to `dlopen' api.cpp:(.text+0x201c): undefined reference to `dlsym' api.cpp:(.text+0x20ad): undefined reference to `dlopen' ./libx265_main12.a(api.cpp.o): In function `x265_12bit::x265_api_query(int, int, int*)': api.cpp:(.text+0x2167): undefined reference to `dlopen' api.cpp:(.text+0x217f): undefined reference to `dlsym' api.cpp:(.text+0x224d): undefined reference to `dlopen' collect2: error: ld returned 1 exit status make[5]: *** [x265] Error 1 make[4]: *** [CMakeFiles/cli.dir/all] Error 2 make[3]: *** [all] Error 2

sounds like at least one shared lib was missing from final linking stage,like "-ldl". For me on termux another android-specific files was missed, so I added this file to ffmpeg-specific env. variable before configure in termux.bld and disabled cli x265 encoder (because ffmpeg need just *.a library).

I guess you can change x265 multibit patch3 , last cmake line

+cd ../8bit +ln -sf ../10bit/libx265.a libx265_main10.a

+ln -sf ../12bit/libx265.a libx265_main12.a +cmake ../source -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DENABLE_SHARED=OFF -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON

by adding also DENABLE_CLI=OFF like in previous entry.