OK, unfortunately things got quite messy now. Since I didn't really know if (after a successful git pull) I should just install "over" the existing version, I just went ahead and made a new repository folder "cinelerra_singleuser_2" in parallel to my existing one ("cinelerra_singleuser_1"). After a new git clone I just installed everything again, However, the resulting bin-directory content was almost empty (compared to my first build), and I got some errors too.
Long story short, I deleted both existing repositories AND did a
sudo aptitude purge cin
since I thought I'll get rid of some (maybe also messed up) libraries too while installing the existing cinelerra from the ubuntu repository. After yet another git clone and make + make install I run into the following error messages:
root@ig0r-ThinkPad-X230:/home/ig0r/cinelerra_singleuser_1/cinelerra5/cinelerra-5.1/bin# ./cin
Cinelerra Infinity - built: Apr 16 2020 10:44:43
git://git.cinelerra-gg.org/goodguy/cinelerra.git
(c) 2006-2019 Heroine Virtual Ltd. by Adam Williams
2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy
Cinelerra is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. There is absolutely no warranty for Cinelerra.
BC_Signals::x_error_handler: error_code=2 opcode=1,0 id=0x0 BadValue (integer parameter out of range for operation)
BC_Signals::x_error_handler: error_code=3 opcode=2,0 id=0x2c001d9 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=61,0 id=0x2c001d9 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=12,0 id=0x2c001d9 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=2 opcode=1,0 id=0x0 BadValue (integer parameter out of range for operation)
BC_Signals::x_error_handler: error_code=3 opcode=2,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=61,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=40,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=2,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=61,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=8,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=2,0 id=0x2c001d9 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=61,0 id=0x2c001d9 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=8,0 id=0x2c001d9 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=8,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=40,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=2,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=61,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=40,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=2,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=61,0 id=0x2c00204 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=2,0 id=0x2c001d9 BadWindow (invalid Window parameter)
BC_Signals::x_error_handler: error_code=3 opcode=61,0 id=0x2c001d9 BadWindow (invalid Window parameter)
On top of that in the resource window the resource list is gone too (check the attached screenshot).
As you say, lets do one step at a time. Could you please give me some info on how to clean up everything, so I'm sure that everything is in order once I download the newest code and build from scratch again?
Sorry for the mess - this is where my limited know-how on how to handle git repositories properly ended. 🙁
BTW I was still able to load the test files, but the choppy preview playback for "my" videos remained, even when it said successful VDPAU init (while your tutorial testpiece works fine).
Take care!
Sorry for the problems. It is probably faster for us to just create a ubuntu 19 static tar with the modifications in. We will let you know when it is ready as we had a computer problem already this morning.
Damn, yeah if it would be too easy it would be boring, right 🙂
FYI I'm on ubuntu 18.04.4 LTS currently.
Thanks for your efforts!
Here is a static tar for Ubuntu 19.10 with the ffmpeg fix in. If you remember, please modify in the {cinelerra_path}/bin/ffmpeg/decode.opts the line "loglevel=fatal" to "loglevel=verbose" so that is it easy to see that the vdpau device is being created and that yuvj420p is not being rejected. Sorry for the delay, we had trouble upgrading ubuntu 19.10 and had to reinstall from original.
https://cinelerra-gg.org/download/testing/cinelerra-5.1-ub19-20200416-x86_64.tar.xz
Oops! Not sure why I thought it was Ubuntu 19. We will build a Ubuntu 18 right now instead. It will take about an hour.
yeah, guys! you did it!
I can confirm that the new build you provided successfully initializes the vdpau device while playing the h.264 yuvl420p testvideo!! Nice!
In the screenshot attached you see the cpu load while playing the compositor and viewer simultaneously and via the nvidia panel you see how heavy the gpu is utilized. Thats really great news!
However, the setup is not quite there yet. Whats weird is that, while the viewer playback seems quite smooth, the compositor preview stutters a lot, even though the measurement in the settings of playback A* says ~47FPS (that can't be).
Whats also notable is that so far it seems that the vaapi mode (when the eGPU is disconnected) both viewer and compositor playback is smooth, and it also seems to outperform the eGPU in terms of CPU loading (while simple playback, though).
It could be that we now reached the inherent bottleneck of the setup is the by far less optimum communication between CPU and eGPU vs the inherent optimization between the intel cpu and the onboard "gpu".
In any case, thank you guys for helping out here! I think the cinelerra software just made a significant leap forward in terms of hardware support, since I think all GoPro users will benefit from that.
Debugging the last bit in my setup would complete my task in this thread. Do you have an idea where this discrepancy between "stuttery playback" in the compositor and the measured rather high FPS can come from? In general I would need to dig into some more performance optimizations here, so any tips would be highly appreciated. For example I noticed that the used Format (settings/format) play a huge role in terms of performance.
Thanks again and have a great weekend!
For completeness, that the output log after loading the h.264 yuvj420p testvideo. At the end, it just keeps on noticing about the "swscaler" (so a endless log with the same message).
ig0r@ig0r-ThinkPad-X230:~/Downloads/cinelerra-5.1-ub18-x86_64-static$ ./cin
Cinelerra Infinity - built: Apr 16 2020 14:05:30
git://git.cinelerra-gg.org/goodguy/cinelerra.git
(c) 2006-2019 Heroine Virtual Ltd. by Adam Williams
2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy
Cinelerra is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. There is absolutely no warranty for Cinelerra.
RenderFarmClient::main_loop: client started
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f78c4169c40] Using non-standard frame rate 59/1
[h264 @ 0x7f78c416bc40] Reinit context to 2704x1520, pix_fmt: yuvj420p
[AVIOContext @ 0x7f78c4172e80] Statistics: 804021 bytes read, 4 seeks
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f78c41887c0] Using non-standard frame rate 59/1
[h264 @ 0x7f78c417ba80] Reinit context to 2704x1520, pix_fmt: yuvj420p
[AVIOContext @ 0x7f78c4188e40] Statistics: 804021 bytes read, 4 seeks
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f78f4007100] Using non-standard frame rate 59/1
[h264 @ 0x7f78f4009300] Reinit context to 2704x1520, pix_fmt: yuvj420p
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f78f4044a80] Using non-standard frame rate 59/1
[h264 @ 0x7f78f4044540] Reinit context to 2704x1520, pix_fmt: yuvj420p
[AVHWDeviceContext @ 0x7f78f4d05400] Successfully created a VDPAU device (NVIDIA VDPAU Driver Shared Library 435.21 Sun Aug 25 08:06:02 CDT 2019) on X11 display :0
[h264 @ 0x7f78f4106cc0] Reinit context to 2704x1520, pix_fmt: vdpau
[swscaler @ 0x7f78f4a66dc0] deprecated pixel format used, make sure you did set range correctly
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f78f4a95e00] Using non-standard frame rate 59/1
[h264 @ 0x7f78f4a97a00] Reinit context to 2704x1520, pix_fmt: yuvj420p
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f78f4ab6600] Using non-standard frame rate 59/1
[h264 @ 0x7f78f4aa47c0] Reinit context to 2704x1520, pix_fmt: yuvj420p
FFStream::decode: Retry limit
[h264 @ 0x7f78f4106cc0] Reinit context to 2704x1520, pix_fmt: vdpau
[swscaler @ 0x7f78ac5abd00] deprecated pixel format used, make sure you did set range correctly
[swscaler @ 0x7f78ac5cb600] deprecated pixel format used, make sure you did set range correctly
[swscaler @ 0x7f78ac5cb600] deprecated pixel format used, make sure you did set range correctly
.
.
.
.
I guess it has something to do with the new implementation. Compared to the pure VAAPI load and play log:
ig0r@ig0r-ThinkPad-X230:~/Downloads/cinelerra-5.1-ub18-x86_64-static$ ./cin
Cinelerra Infinity - built: Apr 16 2020 14:05:30
git://git.cinelerra-gg.org/goodguy/cinelerra.git
(c) 2006-2019 Heroine Virtual Ltd. by Adam Williams
2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy
Cinelerra is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. There is absolutely no warranty for Cinelerra.
RenderFarmClient::main_loop: client started
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb43c1c9900] Using non-standard frame rate 59/1
[h264 @ 0x7fb43c1cb9c0] Reinit context to 2704x1520, pix_fmt: yuvj420p
[AVIOContext @ 0x7fb43c1d2ac0] Statistics: 804021 bytes read, 4 seeks
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb43c1cea00] Using non-standard frame rate 59/1
[h264 @ 0x7fb43c1dce00] Reinit context to 2704x1520, pix_fmt: yuvj420p
[AVIOContext @ 0x7fb43d06b5c0] Statistics: 804021 bytes read, 4 seeks
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb460007000] Using non-standard frame rate 59/1
[h264 @ 0x7fb4600090c0] Reinit context to 2704x1520, pix_fmt: yuvj420p
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb460024940] Using non-standard frame rate 59/1
[h264 @ 0x7fb4600241c0] Reinit context to 2704x1520, pix_fmt: yuvj420p
[AVHWDeviceContext @ 0x7fb460026480] Trying to use DRM render node for device 0.
[AVHWDeviceContext @ 0x7fb460026480] libva: VA-API version 1.1.0
[AVHWDeviceContext @ 0x7fb460026480] libva: va_getDriverName() returns 0
[AVHWDeviceContext @ 0x7fb460026480] libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
[AVHWDeviceContext @ 0x7fb460026480] libva: Found init function __vaDriverInit_1_1
[AVHWDeviceContext @ 0x7fb460026480] libva: va_openDriver() returns 0
[AVHWDeviceContext @ 0x7fb460026480] Initialised VAAPI connection: version 1.1
[AVHWDeviceContext @ 0x7fb460026480] VAAPI driver: Intel i965 driver for Intel(R) Ivybridge Mobile - 2.1.0.
[AVHWDeviceContext @ 0x7fb460026480] Driver not found in known nonstandard list, using standard behaviour.
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb4602f75c0] Using non-standard frame rate 59/1
[h264 @ 0x7fb4602ea400] Reinit context to 2704x1520, pix_fmt: yuvj420p
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb4608111c0] Using non-standard frame rate 59/1
[h264 @ 0x7fb460811c00] Reinit context to 2704x1520, pix_fmt: yuvj420p
FFStream::decode: Retry limit
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb45400e480] Using non-standard frame rate 59/1
[h264 @ 0x7fb454010880] Reinit context to 2704x1520, pix_fmt: yuvj420p
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb45402d4c0] Using non-standard frame rate 59/1
[h264 @ 0x7fb45404c780] Reinit context to 2704x1520, pix_fmt: yuvj420p
[AVHWDeviceContext @ 0x7fb4540507c0] Trying to use DRM render node for device 0.
[AVHWDeviceContext @ 0x7fb4540507c0] libva: VA-API version 1.1.0
[AVHWDeviceContext @ 0x7fb4540507c0] libva: va_getDriverName() returns 0
[AVHWDeviceContext @ 0x7fb4540507c0] libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
[AVHWDeviceContext @ 0x7fb4540507c0] libva: Found init function __vaDriverInit_1_1
[AVHWDeviceContext @ 0x7fb4540507c0] libva: va_openDriver() returns 0
[AVHWDeviceContext @ 0x7fb4540507c0] Initialised VAAPI connection: version 1.1
[AVHWDeviceContext @ 0x7fb4540507c0] VAAPI driver: Intel i965 driver for Intel(R) Ivybridge Mobile - 2.1.0.
[AVHWDeviceContext @ 0x7fb4540507c0] Driver not found in known nonstandard list, using standard behaviour.
[h264 @ 0x7fb454107ec0] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb474006140] Using non-standard frame rate 59/1
[h264 @ 0x7fb454107ec0] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb474008400] Reinit context to 2704x1520, pix_fmt: yuvj420p
[swscaler @ 0x7fb4705d90c0] Warning: data is not aligned! This can lead to a speed loss
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb474023d00] Using non-standard frame rate 59/1
[h264 @ 0x7fb474043280] Reinit context to 2704x1520, pix_fmt: yuvj420p
FFStream::decode: Retry limit
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55b9c0561d40] Using non-standard frame rate 59/1
[h264 @ 0x55b9c03a05c0] Reinit context to 2704x1520, pix_fmt: yuvj420p
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55b9c03a5e80] Using non-standard frame rate 59/1
[h264 @ 0x55b9c0392f80] Reinit context to 2704x1520, pix_fmt: yuvj420p
[AVHWDeviceContext @ 0x55b9c2237140] Trying to use DRM render node for device 0.
[AVHWDeviceContext @ 0x55b9c2237140] libva: VA-API version 1.1.0
[AVHWDeviceContext @ 0x55b9c2237140] libva: va_getDriverName() returns 0
[AVHWDeviceContext @ 0x55b9c2237140] libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
[AVHWDeviceContext @ 0x55b9c2237140] libva: Found init function __vaDriverInit_1_1
[AVHWDeviceContext @ 0x55b9c2237140] libva: va_openDriver() returns 0
[AVHWDeviceContext @ 0x55b9c2237140] Initialised VAAPI connection: version 1.1
[AVHWDeviceContext @ 0x55b9c2237140] VAAPI driver: Intel i965 driver for Intel(R) Ivybridge Mobile - 2.1.0.
[AVHWDeviceContext @ 0x55b9c2237140] Driver not found in known nonstandard list, using standard behaviour.
[h264 @ 0x55b9c2749e80] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x55b9c2749e80] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x55b9c2749e80] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x55b9c2749e80] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb45828edc0] Using non-standard frame rate 59/1
[h264 @ 0x7fb458290900] Reinit context to 2704x1520, pix_fmt: yuvj420p
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb45801b200] Using non-standard frame rate 59/1
[h264 @ 0x7fb45803a0c0] Reinit context to 2704x1520, pix_fmt: yuvj420p
[h264 @ 0x55b9c2749e80] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
[h264 @ 0x7fb4600cad00] Reinit context to 2704x1520, pix_fmt: vaapi_vld
It would be really powerful to work a bit further on this topic, and I'm happy to help. The big goal is to have some major performance advantages while using the eGPU compared to the rather weak vaapi onboard graphics. I think we're already quite close.
Thanks and take care! Cheers!
It is very difficult to debug a problem with slowness, stutteriness, etc. unless we experience the same issue and we just are not yet. I test first on my laptop which has 16 cpus so is reasonably the same as ordinary people (not like gg's desktop overkill).
- You might try to vary the size of the audio buffers (Settings->Preferences,Playback A tab); try the extremes of "1024" and then the biggest one. For instance, we did find a long time ago that when using LV2 plugins, the back and forth of the cursor in the timeline occurred unless the buffer was set to 1024. I can no longer remember the reason.
It is IMPORTANT to know that "audio determines the timing", that is the playback rate and not the video.
- For Ubuntu18, gg is creating a debuggable version because I think that maybe Ig0r might be able to provide some useful debugging information through the use of PROF2. Prof2 usage is described in the Developer's section of the manual but requires a debuggable build (will let you know when/if that becomes available so no need to read up on usage yet). There is a possibility that prof2 will not work on newer laptops because of additional security -- for example my laptop is about 3-4 years old and it will not work for me at this time.
More later.
It is almost the weekend there so if you have time on Monday and want to try to get us more information, that is good. But this is a lot of work for you, and may not be of any help to us in finding the problem and a solution. There is a debuggable Ubuntu 18 static tar at the following. It is very large so if you have a slower network, it may not be worth your time to get it and run it.
https://cinelerra-gg.org/download/testing/cin-ub18-debug.txz
Prof2 is already compiled in this tar file. Here is a list of what you will have to do (do not follow the manual; some things may be missing).
1 - download the file and untar it
2 - cp {your cinelerra path}/prof2 -a smap /usr/local/bin/.
(this is because the smap binary file has to be in a place where prof2 can find it)
3 - install "gdb" if not already installed
4 - install libiberty-dev which is most likely not installed
5 - get into the {cinelerra_path_directory}/prof2
6 - run from a window the following (this may be not quite correct so let me know if error)
./prof -o /tmp/prof_list.txt {your_cinelarra_path}/bin/cin
7 - check /tmp/prof_list.txt to see if there is output and if so, then send to us
Here is a static tar for Ubuntu 19.10 with the ffmpeg fix in. If you remember, please modify in the {cinelerra_path}/bin/ffmpeg/decode.opts the line "loglevel=fatal" to "loglevel=verbose" so that is it easy to see that the vdpau device is being created and that yuvj420p is not being rejected. Sorry for the delay, we had trouble upgrading ubuntu 19.10 and had to reinstall from original.
https://cinelerra-gg.org/download/testing/cinelerra-5.1-ub19-20200416-x86_64.tar.xz
Maybe it helps (or not), but I have tested this version on Pop!_OS 19.10 and ALSA works as it should using the "default" output, as well as PulseAudio from the "special testing build" you linked a while ago. But then I cannot load JPG/PNG files while vaapi is enabled in Settings -> Performance, what works with most files in the PulseAudio testing build (a few JPG files aren't loaded).
Yes, this helps and thanks for checking this out and reporting back. Somehow there has been a side effect that we were not aware of. We will have to figure that out before the monthly builds.
@phyllissmith You are more than welcome. Please feel free to ping me if you want any tests with the ub19 builds.
Sorry for the very late reply, but life, work and a new NAS got in the way.
I tried to work on a video editing project using the static build you provided: While it is definitely usable, the performance is still far from optimum. I played around with several audio settings, without any success. Best guess: When "play every frame", I see that my 60fps footage plays at 40fps and the eGPU (according to the nvidia settings) is utilized 100% (also heavily using the "video engine"), while the "PCI bandwith utilization" is around 80%. It seems to me that there is heavy overhead in the whole processing, since the intel onboard "GPU" (via vaapi) doesn't have big issues there.
But it is worth mentioning, that the whole stuff still already pays off a little, since the encoding using the h264_nvenc.mp4 compression fully loads the eGPU and rendering is a lot faster!
Of course I'm happy to help you debug this further. I tried to follow the steps you listed, but
ig0r@ig0r-ThinkPad-X230:~/Downloads/cin-ub18-debug$ cp /home/ig0r/Downloads/cin-ub18-debug/prof2 -a smap /usr/local/bin/
cp: target '/usr/local/bin/' is not a directory
doesn't work out for me. Please let me know how to proceed, I already installed the missing lib.
One more thing: I'm thinking on upgrading my system to the new 20.04 LTS. This way I would also get rid of all messed up libs and redundant video editors on my system in a clean way. Do you think it makes sense from a cinelerra point of view? Thats the whole point on my efforts in this direction.
Thanks! BR