On Wednesday, July 21, 2021, Andrea paz <[email protected]> wrote:
I found some references to 10-bit and 12-bit; however, not being sure of their meaning I am attaching the entire x265_3.4 directory (.pdf is a fake!).
The command "git apply -v" hangs without showing neither output nor closing. I have to close it with ctrl+c.
i was assuming you used 'git apply -v dir/*.patch' from cingg's source dir, where dir/ inside cingg src root, with my patches. just 'git apply -v' probably wait for std. input or something...
Reading Phyllis' email I wonder if the 3 patches of x265 that I find in.../cinelerra-5.1/thirdparty have been applied or I have to apply them like the others of randrik10.
they *should* be applied automatically... by buildsystem. just be sure they live in thirdparty/src and named like same_name_as_src_tar.patch[1,2,3]
it seems I need to re-create some of those patches... wait a bit I am in a moving bus... On Thursday, July 22, 2021, Andrea paz <[email protected]> wrote:
i was assuming you used 'git apply -v dir/*.patch' from cingg's source dir, where dir/ inside cingg src root, with my patches. just 'git apply -v' probably wait for std. input or something...
My fault, of course! I append git-apply results.
Better to wait for MatN's tests, so we are more sure than my error-filled attempts. In the meantime I tried the new git that contains libaom 3.1.1. I imported a test video (BeachYoga.webm from https://av1.webmfiles.org/) and the playback is smooth. I tried the rendering and it works well (28 fps, for my PC it's a normal result). This seems like a nice step up from the slowness we had before.
On Thursday, July 22, 2021, Andrea paz <[email protected]> wrote:
Better to wait for MatN's tests, so we are more sure than my error-filled attempts. In the meantime I tried the new git that contains libaom 3.1.1. I imported a test video (BeachYoga.webm from https://av1.webmfiles.org/) and the playback is smooth. I tried the rendering and it works well (28 fps, for my PC it's a normal result).
well, playback should be handled by libdav1d.. (it should be built by default). only encoding *into* av1 handled by libaom (and this was still slow per your earlier tests) anyway, thanks for continuos testing! PS: some strangeness with permissions on hdd may be due to overheating?? because summer.... double check temperatures inside computer case, make backup at evening/night/morning ...
This seems like a nice step up from the slowness we had before.
I installed randrik11 patches with "git am --whitespace=fix ...". It failed only patch 0029 and gave whitespace problems only patch 0038. I gave permissions after applying the patches. Usual compile error after a few seconds. See cin5.log. (I always keep a T monitor in sight when doing tests and rendering. But it could be that the nvme gets too hot - I have a motherboard sensor in general but don't have them for nvme.) Thank you for the great work you do and your patience with me.
On Friday, July 23, 2021, Andrea paz <[email protected]> wrote:
I installed randrik11 patches with "git am --whitespace=fix ...". It failed only patch 0029 and gave whitespace problems only patch 0038. I gave permissions after applying the patches. Usual compile error after a few seconds. See cin5.log.
so it fails configure for opus and also mjpegtool patch #4... something to work on... thanks!
(I always keep a T monitor in sight when doing tests and rendering. But it could be that the nvme gets too hot - I have a motherboard sensor in general but don't have them for nvme.)
Thank you for the great work you do and your patience with me.
apply those two fixes on top of already applied series (attached) On Friday, July 23, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Friday, July 23, 2021, Andrea paz <[email protected]> wrote:
I installed randrik11 patches with "git am --whitespace=fix ...". It failed only patch 0029 and gave whitespace problems only patch 0038. I gave permissions after applying the patches. Usual compile error after a few seconds. See cin5.log.
so it fails configure for opus and also mjpegtool patch #4... something to work on...
thanks!
(I always keep a T monitor in sight when doing tests and rendering. But it could be that the nvme gets too hot - I have a motherboard sensor in general but don't have them for nvme.)
Thank you for the great work you do and your patience with me.
Applying the additional 2 patches on top of the previous ones, shows the following text: git am --whitespace=fix /home/paz/Download/randrik11/rand/*.patch Current Application: fix opus configure Current Application: fix mjpegtools patch4 and patch5 (termux) .git/rebase-apply/patch:20: space before tab in indent. if (nErr != 0) .git/rebase-apply/patch:21: space before tab in indent. mjpeg_error_exit1 ("pthread_attr_init() failed: %s", .git/rebase-apply/patch:22: space before tab in indent. strerror (nErr)); .git/rebase-apply/patch:35: space before tab in indent. // Inherit scheduling parameters from the main thread. .git/rebase-apply/patch:36: space before tab in indent. nErr = pthread_attr_setinheritsched (&sThreadAttributes, warning: 13 Suppressed whitespace errors warning: 18 lines applied after correction of whitespace errors. It looks like opus is fine, but mjpegtools still isn't.
On Friday, July 23, 2021, Andrea paz <[email protected]> wrote:
Applying the additional 2 patches on top of the previous ones, shows the following text:
git am --whitespace=fix /home/paz/Download/randrik11/rand/*.patch Current Application: fix opus configure Current Application: fix mjpegtools patch4 and patch5 (termux) .git/rebase-apply/patch:20: space before tab in indent. if (nErr != 0) .git/rebase-apply/patch:21: space before tab in indent. mjpeg_error_exit1 ("pthread_attr_init() failed: %s", .git/rebase-apply/patch:22: space before tab in indent. strerror (nErr)); .git/rebase-apply/patch:35: space before tab in indent. // Inherit scheduling parameters from the main thread. .git/rebase-apply/patch:36: space before tab in indent. nErr = pthread_attr_setinheritsched (&sThreadAttributes, warning: 13 Suppressed whitespace errors warning: 18 lines applied after correction of whitespace errors.
i hope 'after correction of whitespace errors' means exactly that it looks like saying.. try to build?
It looks like opus is fine, but mjpegtools still isn't.
The build ran for 10 min before giving an error. I attach cin5-single-threads.log Note: the compilation proceeded in single-thread instead of multi-threads. In fact normally I compile in 5 min (16 threads at 100%) Note2: I had done a "make clean" and a "git reset --hard" before applying the patches + 2. Note3: I've deleted cinelerra5 folder and made a new git clone and build without patch: all OK (and multi-threads). I attach cin5-no-patch.log. Then I deleted cinelerra5 folder and made a new git clone, added the patches and the result is the same as the first time: error and single-thread. I enclose cin5-single-threads-2.log
On Friday, July 23, 2021, Andrea paz <[email protected]> wrote:
The build ran for 10 min before giving an error. I attach cin5-single-threads.log Note: the compilation proceeded in single-thread instead of multi-threads. In fact normally I compile in 5 min (16 threads at 100%)
well, single-threaded x265 compilation was expected, but it seems it tries to build libbthread-master even on normal linux, not termux... you run ./autogen.sh after patching and before configure, yes? for some reason my conditional compilation not worked.. ( also may be whitespace fix ruin mjpegtools patches 4 and 5 ...? try to rename them temporary?
Note2: I had done a "make clean" and a "git reset --hard" before applying the patches + 2. Note3: I've deleted cinelerra5 folder and made a new git clone and build without patch: all OK (and multi-threads). I attach cin5-no-patch.log. Then I deleted cinelerra5 folder and made a new git clone, added the patches and the result is the same as the first time: error and single-thread. I enclose cin5-single-threads-2.log
On Friday, July 23, 2021, Andrea paz <[email protected]> wrote:
The build ran for 10 min before giving an error. I attach cin5-single-threads.log Note: the compilation proceeded in single-thread instead of multi-threads. In fact normally I compile in 5 min (16 threads at 100%)
there seems to be very big numbers of warnings from x265 sources, like described here https://bitbucket.org/multicoreware/x265_git/issues/559/warnings-when-assemb... if you have nasm-2.15.x this is "normal" .. I tried to make patch for this, put in thirdparty/src and test? sorry for such long trail of errs...
Note2: I had done a "make clean" and a "git reset --hard" before applying the patches + 2. Note3: I've deleted cinelerra5 folder and made a new git clone and build without patch: all OK (and multi-threads). I attach cin5-no-patch.log. Then I deleted cinelerra5 folder and made a new git clone, added the patches and the result is the same as the first time: error and single-thread. I enclose cin5-single-threads-2.log
you run ./autogen.sh after patching and before configure, yes? Yes, after patching and before ./configure. I copy and paste the following list:
$ git clone --depth 1 "git://git.cinelerra-gg.org/goodguy/cinelerra.git" cinelerra5 $ cd /home/paz/cinelerra5/cinelerra-5.1 [add patch; tar.xz and #chown] $ ./autogen.sh [I add "autoupdate" into autogen.sh] $ ./configure --with-single-user --with-config-dir=/home/paz/.bcast6 --with-booby [.bcast5 is for AppImage] $ make 2>&1 | tee /tmp/cin5.log && make install
if you have nasm-2.15.x this is "normal" .. I tried to make patch for this, put in thirdparty/src and test? I've nasm 2.15.5 If I try to apply your latest patch I get:
patch < x265_3.4.patch4 can't find file to patch at input line 3 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |--- ./source/CMakeLists.txt.orig 2021-07-23 19:16:11.388035683 +0300 |+++ ./source/CMakeLists.txt 2021-07-23 19:17:30.972035687 +0300 -------------------------- File to patch: ... I do not have a CMakeLists.txt in my entire system (# find / CMakeLists.txt). The result is that I can't apply the patch. Arch's wiki mentions it, but obviously I don't understand it: https://wiki.archlinux.org/title/CMake_package_guidelines On Friday, July 23, 2021, Andrea paz <[email protected]> wrote:
The build ran for 10 min before giving an error. I attach cin5-single-threads.log Note: the compilation proceeded in single-thread instead of multi-threads. In fact normally I compile in 5 min (16 threads at 100%)
there seems to be very big numbers of warnings from x265 sources, like described here https://bitbucket.org/multicoreware/x265_git/issues/559/warnings-when-assemb... if you have nasm-2.15.x this is "normal" .. I tried to make patch for this, put in thirdparty/src and test? Andrew Randrianasulu 18:25 (2 ore fa) a me, Cinelerra.GG, Phyllis On Friday, July 23, 2021, Andrea paz <[email protected]> wrote:
The build ran for 10 min before giving an error. I attach cin5-single-threads.log Note: the compilation proceeded in single-thread instead of multi-threads. In fact normally I compile in 5 min (16 threads at 100%)
there seems to be very big numbers of warnings from x265 sources, like described here https://bitbucket.org/multicoreware/x265_git/issues/559/warnings-when-assemb... if you have nasm-2.15.x this is "normal" .. I tried to make patch for this, put in thirdparty/src and test? Andrew Randrianasulu 18:25 (2 ore fa) a me, Cinelerra.GG, Phyllis
On Friday, July 23, 2021, Andrea paz <[email protected]> wrote:
you run ./autogen.sh after patching and before configure, yes? Yes, after patching and before ./configure. I copy and paste the following list:
$ git clone --depth 1 "git://git.cinelerra-gg.org/goodguy/cinelerra.git" cinelerra5
$ cd /home/paz/cinelerra5/cinelerra-5.1
[add patch; tar.xz and #chown]
$ ./autogen.sh [I add "autoupdate" into autogen.sh]
$ ./configure --with-single-user --with-config-dir=/home/paz/.bcast6 --with-booby [.bcast5 is for AppImage]
$ make 2>&1 | tee /tmp/cin5.log && make install
looks correct...
if you have nasm-2.15.x this is "normal" .. I tried to make patch for this, put in thirdparty/src and test? I've nasm 2.15.5
Sorry, just try to put it in thirdparty/src, so build will apply it automatically.. If I try to apply your latest patch I get:
patch < x265_3.4.patch4 can't find file to patch at input line 3 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |--- ./source/CMakeLists.txt.orig 2021-07-23 19:16:11.388035683 +0300 |+++ ./source/CMakeLists.txt 2021-07-23 19:17:30.972035687 +0300 -------------------------- File to patch: ...
I do not have a CMakeLists.txt in my entire system (# find / CMakeLists.txt). The result is that I can't apply the patch. Arch's wiki mentions it, but obviously I don't understand it: https://wiki.archlinux.org/title/CMake_package_guidelines
On Friday, July 23, 2021, Andrea paz <[email protected]> wrote:
The build ran for 10 min before giving an error. I attach cin5-single-threads.log Note: the compilation proceeded in single-thread instead of multi-threads. In fact normally I compile in 5 min (16 threads at 100%)
there seems to be very big numbers of warnings from x265 sources, like described here
https://bitbucket.org/multicoreware/x265_git/issues/ 559/warnings-when-assembling-with-nasm-215
if you have nasm-2.15.x this is "normal" .. I tried to make patch for this, put in thirdparty/src and test?
Andrew Randrianasulu
18:25 (2 ore fa)
a me, Cinelerra.GG, Phyllis
On Friday, July 23, 2021, Andrea paz <[email protected]> wrote:
The build ran for 10 min before giving an error. I attach cin5-single-threads.log Note: the compilation proceeded in single-thread instead of multi-threads. In fact normally I compile in 5 min (16 threads at 100%)
there seems to be very big numbers of warnings from x265 sources, like described here
https://bitbucket.org/multicoreware/x265_git/issues/ 559/warnings-when-assembling-with-nasm-215
if you have nasm-2.15.x this is "normal" .. I tried to make patch for this, put in thirdparty/src and test?
Andrew Randrianasulu
18:25 (2 ore fa)
a me, Cinelerra.GG, Phyllis
This time it seemed to go into multi-threads until the error. I attach cin5.log. Should I try it as root?
On Saturday, July 24, 2021, Andrea paz <[email protected]> wrote:
This time it seemed to go into multi-threads until the error. I attach cin5.log. Should I try it as root?
it seems to fail at libbthread, yet it shouldn't even try to build it on x86/linux... can you try to look at configure.ac and set there libbthread from auto to no, and then re-run autogen.sh + configure + make?
I used https://stackoverflow.com/questions/714100/os-detecting-makefile for crafting attached patch.. still works on Android/termux... Apply (git am) on top of previous patch series (randrik11 + two fixes) ... time for new series... On Saturday, July 24, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Saturday, July 24, 2021, Andrea paz <[email protected]> wrote:
This time it seemed to go into multi-threads until the error. I attach cin5.log. Should I try it as root?
it seems to fail at libbthread, yet it shouldn't even try to build it on x86/linux...
can you try to look at configure.ac and set there libbthread from auto to no, and then re-run autogen.sh + configure + make?
participants (2)
-
Andrea paz -
Andrew Randrianasulu