- Cin - Cinelerra-GG Mailing Lists

I tried to make Appimage out of cinHV!
by Andrew Randrianasulu 28 Jan '25

28 Jan '25

https://cloud.mail.ru/public/mX4A/DSuGSMfUZ sha256sum /dev/shm/cinelerraHV-x86_64.AppImage 7621b7e99734717c4c6847de85f8d8e25c0bf9aa7722d7fc3cf4694cadbd8971 /dev/shm/cinelerraHV-x86_64.AppImage using new static appimage runtime ... and ROSA linux 2016 rootfs (gcc 5.5 and other tools of similar vintage ..roughly Ubuntu 16.04 ?) makeappimage need setting CXXFLAGS=-std=gnu++11, and adding liboost_filesystem for boost 1.61, and minor editing in appdir.C (constexpr t lines 33 and 35 to just const) but it seems to work, after I added desktop entry and (as hack) cingg svg icon ... Is anyone brave enough to test it? :) commit a30bb38bcdb6fe1fabdb534611bc2b9123f70514 (origin/master, origin/HEAD) Author: heroineworshiper <broadcast(a)earthling.net> Date: Thu Oct 10 21:56:45 2024 -0700 + some of my patches (can resend separately)

2 3

In theory there might be some help ....
by Andrew Randrianasulu 17 Jan '25

17 Jan '25

https://www.osnews.com/story/141556/offer-volunteer-labor-for-your-open-sou… ==== OSNews Sponsor OS-SCi <https://os-sci.com> is educating the next generation FOSS engineers, and as part of their coursework, they’re looking for worthy open source projects to which they can contribute their time and effort. In addition to the work they provide during their studies, these volunteers will be encouraged to continue to be involved after they finish their courses and proceed into the workforce. If you are involved in an open source project and would like some help, please register here <https://os-sci.com/partner-organisations>. ==== end of quotation ======

2 1

OT: Switcheroo-Control for Multi-GPU switching
by Terje J. Hanssen 11 Jan '25

11 Jan '25

Extracted info from referenced documents: The Switcheroo-Control is a D-Bus service to check the availability of hybrid GPU configurations and integrate with the desktop environment. This tool is the recommended solution to manage GPU switching on systems with multiple GPUs. Users are encouraged to move away from legacy tools like prime, bbswitch, and bumblebee, as they can cause more harm than good on modern systems. switcherooctl integrates well with Wayland and Xorg, is a lightweight userspace utility and its functionality extends across both Intel + NVIDIA and AMD + NVIDIA setups. By using switcherooctl, users can easily select which GPU to use for specific applications and eliminate the need for complex scripts or environment variables. ------------ https://negativo17.org/prime-optimus-laptops-and-multi-gpu-systems/ https://news.opensuse.org/2024/12/09/gpu-switching-game-changing/ For openSUSE on SkyLake with Nvidia dGPU + integrated Intel iGPU I followed this installation and setup guide SDB:NVIDIA Switcheroo Control https://en.opensuse.org/SDB:NVIDIA_Switcheroo_Control After installing the switcheroo-control package, it had to be enabled as a service and then reboot: systemctl enable switcheroo-control.service ------- According to its online help info switcherooctl version 2.6 switcherooctl help list Usage: switcherooctl list List the known GPUs. switcherooctl help launch Usage: switcherooctl launch [COMMAND…] Launch a command on a specific GPU. Options: -g, --gpu=GPU-ID The GPU to launch on The default GPU to launch on will be the first discrete GPU, or the default GPU if there’s only one. Identifiers can be found using the list command. ------------ Example: switcherooctl list Device: 0 Name: Intel® HD Graphics 530 Default: yes Environment: DRI_PRIME=pci-0000_00_02_0 Device: 1 Name: NVIDIA Corporation GM206 [GeForce GTX 960] Default: no Environment: __GLX_VENDOR_LIBRARY_NAME=nvidia __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only ----------- I have not so far any example command(s) to launch(?)

2 2

QSV render tests 20% faster with RPM vs AppImage
by Terje J. Hanssen 07 Jan '25

07 Jan '25

I did a few hevc and av1 OSV render tests using the latest RPM w/oneVPL on Leap, to compare it with my own AppImage. To get the AppImage from Slowroll to run om Leap, I had to add-install a newer version libFLAC12. The machine is AlderLake w/Arc A750 gpu The OS root drive is on a std SATA disc, while the video files are read/written to a fast M.2 disc. Results: hevc_qsv_8b420.mp4 ** rendered 5972 frames in 19.255 secs, 310.153 fps (RPM) ** rendered 5972 frames in 23.798 secs, 250.945 fps (AppImage) av1_qsv_8b420.mp4 ** rendered 5972 frames in 18.612 secs, 320.868 fps (RPM) ** rendered 5972 frames in 21.470 secs, 278.156 fps (AppImage) In average rendering is ca. 20% faster with the RPM. I did also additional test with the AppImage on Slowroll and got a bit faster rendering, but not so fast as with RPM on Leap.

2 4

Release for 12/2024 + question for Andrey
by Phyllis Smith 07 Jan '25

07 Jan '25

AppImages available for the December 2024 release at: https://cinelerra-gg.org/download/images/ + https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppI… Packages available for the newer operating systems at: https://github.com/einhander/cin-gg-packages/releases/tag/20241229 See latest release notes below the *****. Question for *Andrey*: Would it be possible to easily add --with-onevpl to the configure line in your build script for Leap 15.5 RPM package? It would require the added package of "oneVPL-devel" to be installed on that O/S (that is the package name for Fedora). If you use the same build script on all of your package builds, they would have to have "oneVPL-devel" installed also. I have tested the build on Fedora 40 after installing that package and had no problem. I have none of the new Intel hardware to test but Terje would like to be able to use these new Intel hardware/software features on his computer. It should not impact normal usage (hopefully). ********* GIT for Cinelerra-GG has the following changes from 11/01/2024-12/31/2024 ********* *SVT_AV1* has been upgraded to 2.3.0 from 2.2.1 with no known problems. *Nvidia encode headers* updated from 10.0.26.0 to 12.2.72.0 which corresponds to Video Codec SDK version 12.0.16. The required driver version for Linux is 550.54.14 or newer. You can check to see if your Nvidia graphics board is supported at this website at the time of this release: https::// developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new There may be user impact since the previous required driver for Linux was 445.87. Minor addition to add non-working ffmpeg filters to plugin.opts; these are blacklisted items. *Andrew-R contributions* The build for *NetBSD* 10.0/amd64 is now working with 3 patches applied and checked in. New *Termux* (Android) encoding render formats have been added: h264_mediacodec.mp4, hevc_mediacodec.mp4, and mpeg2_hdv.mpeg. The 2 mediacodec formats will only work on Android (mediacodec is part of the Android low-level multimedia support infrastructure). A mod to mjpegtools disables compilation of y4mdenoise to prevent compiler errors in *clang*. *Terje testing/building and Andrew-R diagnosing contributions* 12 *new render formats* for qsv, which can be used only if you have that particular Intel hardware and software, have been added as developed/tested by Andrew and Terje. (QSV is Intel’s Quick Sync Video for its dedicated video encoding/decoding hardware core.) 12 *new or replaced vaapi hardware encoding *render formats are now available. Run the vainfo program to determine what formats your hardware/software recognizes. There are some patches to ffmpeg.C and ffmpeg.h to support the above. Additions for building with *oneVPL* (Intel’s oneAPI Video Processing Library) is now an option to be enabled if desired - not enabled by default - on the autogen line by adding “--with-onevpl”. Note in reference to the previous paragraph: There should be no impact to standard usage of CinGG but users need to be especially aware of the fact that using a render encoding format that requires specific hardware/software implementation will give an error. In addition, the standard AppImage releases will not provide the availability to use specific hardware features. This is the same as the inability to use vdpau/vaapi from those same appimages since they are created on a computer without the end users specific hardware. An *AppImage* has been graciously created for users who do have the Intel hardware that supports these newly tested/implemented features *of oneVPL, av1, qsv, and vaapi* for download at: https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppI…

5 8

No rendering - error message
by Terje J. Hanssen 06 Jan '25

06 Jan '25

I guess this may be a stupid error I have not encountered before. Suddenly the AppImages don't render and output the following Cinelerra messages: virtual void Render::handle_close_event(int): Create new file at labels checked, but no labels Any idea how to solve it?

2 2

Testing Cingg RPM built with OneVPL, qsv and vaapi presets
by Terje J. Hanssen 05 Jan '25

05 Jan '25

Installed Andrey's recent cinelerra-5.1-20250104.suse15.x86_64.rpm package on Leap 15.6 on two different Intel based hw, and tested qsv and vaapi presets without issues 1) Intel Arc Alchemist w/ A750 dGPU (2023) av1_qsv_8b420.mp4, qsv_10b420.mp4 hevc_qsv_8b420.mp4, hevc_qsv_10b420.mp4, hevc_qsv_10b422.mp4 av1_vaapi_8b420.mp4, vaapi_10b420.mp4 hevc_vaapi_8b420.mp4, hevc_vaapi_10b420.mp4, hevc_vaapi_10b422.mp4 2) Intel KabyLake w/ UHD 620 iGPU (2017) hevc_qsv_8b420.mp4, hevc_qsv_10b420.mp4 hevc_vaapi_8b420.mp4, hevc_vaapi_10b420.mp4 The last line here is of special interest hevc_vaapi_8b420.mp4, hevc_vaapi_10b420.mp4 because Cingg deb on UB24.04 on this machine didn't render hevc_vaapi. It seems that OneVPL (libvpl) extends the codec capability also for vaapi. This has to be verified by dual-testing once more..

2 4

Issues to prepare a test on UB 24.04
by Terje J. Hanssen 03 Jan '25

03 Jan '25

Well, I admit I have never been a real UB user. But as UB16 initally was fabric installed on my Dell XPS 13-9370 (KBL), I have kept and upgraded UB as part of multiboot with openSUSE Leap and Slowroll on this machine. So I upgraded to the available UB 24.04.1LTS to prepare a new Cingg test on it. Actually my old installed Cinelerra Infinity - built: Jun 30 2020 09:37:43 still startup on UB24.04. 1) I tried first to install the latest cin_5.1.20241009.ubuntu2204_amd64.deb package without success. sudo apt install <package url> didn't work (like corresponding "zypper in" on Leap does) So I downloaded the package and tried sudo apt install cin_5.1.20241009.ubuntu2204_amd64.deb Reading package lists ... Finished Create overview over dependices --- Finished Reading state information ... Finished E: Cannot find the package cin_5.1.20241009.ubuntu2204_amd64.deb What is the issue, when the deb package is in the local directory? 2) So I tried the AppImage ./CinGG-20241120-x86_64-IntelHW.AppImage dlopen(): error loading libfuse.so.2 AppImages require FUSE to run. You might still be able to extract the contents of this AppImage if you run it with the --appimage-extract option. See https://github.com/AppImage/AppImageKit/wiki/FUSE for more information Before this I had installed FUSE according to the wiki sudo add-apt-repository universe sudo apt install libfuse2t64 I had a look back into the AppImage (Fuse) mail thread, and ask here if a Fix was found that can be used here? Terje

3 6

Testing Nvidia Nvenc encoding
by Terje J. Hanssen 29 Dec '24

29 Dec '24

Continued and extracted from [Cin] Video accelerators support, builds and use https://lists.cinelerra-gg.org/pipermail/cin/2024-December/009226.html Den 12.12.2024 00:54, skrev Terje J. Hanssen: > > Den 11.12.2024 23:56, skrev Andrew Randrianasulu: >> >> чт, 12 дек. 2024 г., 00:43 Terje J. Hanssen via Cin >> <cin(a)lists.cinelerra-gg.org>: >> >> To clarify some pieces once again, I put up some basic statements >> or questions: >> ..........snip >> >> >> So what happened when adding oneVPL (qsv) support to the >> build system; dynamic linked to system or static added >> embedded into the build? >> >> >> dynamic >> >> .....snip >> >> Could in principle similar methods be extended to include >> broader video acceleration support for AMD/amf and NVIDIA/nvenc? >> >> >> nvenc already supported, I think? At some point I tried it with >> GF710 on livedvd and it was working for me. try to test it if you >> have proprietary nvidia drivers. >> Apparently Cingg then should supports NVENC via some dynamic linked external Nvidia lib, equivalent to what we did for for QSV via oneVPL support. While h264_nvenc.mp4 rendering works, h265_nvenc.mp4 fails with the following errors, see detail below: [hevc_nvenc @ 0x7ff79c015640] No capable devices found FFMPEG::open_encoder err: Generic error in an external library > > Yes, seemingly: > Cin/bin/ffmpeg/video> ls *nvenc* > h264_nvenc.mp4 h264_nvenc.qt h265_nvenc.mp4 NVENC Presets cat h264_nvenc.mp4 mp4 h264_nvenc # encode for nvidia graphics hw only preset medium profile main cat h265_nvenc.mp4 mp4 hevc_nvenc # encode for nvidia graphics hw only preset medium profile main > > Maybe I can do an attempt later, if I get life in the old GeForce GTX > 960 in my Skylake workstation. > Setup ---------- Booted BIOS and checked that the integrated Intel gpu and multimonitor setup were enabled. Installed the suse-prime package for nvidia/intel gpu selection (for NVIDIA optimus laptops with bbswitch support) and could then run the command prime-select on-demand and verified that both the Intel and Nvidia drivers were available inxi -G Graphics: Device-1: Intel HD Graphics 530 driver: i915 v: kernel Device-2: NVIDIA GM206 [GeForce GTX 960] driver: nvidia v: 550.135 Display: wayland server: X.org v: 1.21.1.14 with: Xwayland v: 24.1.4 compositor: gnome-shell v: 47.2 driver: X: loaded: modesetting,nvidia unloaded: fbdev,vesa dri: iris gpu: i915 resolution: 1920x1080~60Hz API: OpenGL v: 4.6 vendor: intel mesa v: 24.3.1 renderer: Mesa Intel HD Graphics 530 (SKL GT2) API: EGL Message: EGL data requires eglinfo. Check --recommends. ============== Test h264_nvenc.mp4 ------------------- OK ./CinGG-20241120-x86_64.AppImage Cinelerra Infinity - built: Nov 20 2024 22:06:05 Loads hdv09_04.m27 Shift-R mp4 h264_nvenc (video preset) pixels: yuv420p (default) ** rendered 5972 frames in 27.391 secs, 218.028 fps ffprobe -hide_banner hdv09_04_h264_nvenc_yuv420p.mp4 Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuvj420p(pc, smpte170m/unknown/unknown), 1440x1080 [SAR 4:3 DAR 16:9], 2156 kb/s, 25 fps, 25 tbr, 12800 tbn (default) ------- Tried also h264_nvenc with pixels: nv12 which for slowed down to 45% speed !? Render::render_single: Session finished. ** rendered 5972 frames in 60.368 secs, 98.927 fps ffprobe -hide_banner hdv09_04_h264_nvenc_nv12.mp4 Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuvj420p(pc, smpte170m/unknown/unknown), 1440x1080 [SAR 4:3 DAR 16:9], 2154 kb/s, 25 fps, 25 tbr, 12800 tbn (default) =================== Test h265_nvenc.mp4 ------------------- Did not render, neither with pixels yuv420p nor nv12: FFMPEG::open_encoder err: Generic error in an external library [hevc_nvenc @ 0x7ff79c015640] No capable devices found FFMPEG::open_encoder err: Generic error in an external library int FFMPEG::open_encoder(const char*, const char*): open failed hevc_nvenc:/run/media/terje/video/hdv09_04_h265_nvenc_yuv420p.mp4 Render::render_single: Session finished. =================== GeForce GTX 960 (GM206) should be capable to manage NVENC h265/hevc YUV 420 encoding https://en.wikipedia.org/wiki/Nvidia_NVENC#Third_generation,_Maxwell_GM20x https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new Tested hevc_nvenc full transcoding with FFmpeg 7.1 ffmpeg -hide_banner -hwaccel cuda -hwaccel_output_format cuda -i hdv09_04.m2t -c:v hevc_nvenc hdv09_04_ff_hevc_nvenc.mp4 frame= 5963 fps=270 q=34.0 Lsize= 64316KiB time=00:03:58.77 bitrate=2206.6kbits/s speed=10.8x [aac @ 0x55a38d4c4d40] Qavg: 488.890 ------------------ ffprobe -hide_banner hdv09_04_ff_hevc_nvenc.mp4 Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, bt709, top coded first (swapped)), 1440x1080 [SAR 4:3 DAR 16:9], 2074 kb/s, 24.99 fps, 25 tbr, 12800 tbn (default)

4 32

Testing Appimage with OneVPL and QSV presets on legacy Intel hardware
by Terje J. Hanssen 20 Dec '24

20 Dec '24

After the successful Appimage build with OneVPL for QSV on Alder Lake (i7-12700/Arc A750), the time has come as proof of contest to test if it also works on legacy Intel iGPU hardware. Extracted from the Fixed-function Quick Sync Video format support for HEVC one should expect https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Hardware_decoding_and_… * The Skylake microarchitecture implementation adds a full fixed-function H.265/HEVC 8-bit 4:2:0 decoding and encoding acceleration, hybrid and partial HEVC 10-bit decoding acceleration, * The Kaby Lake, Coffee Lake, Whiskey Lake and Comet Lake microarchitectures implementation adds full fixed-function H.265/HEVC 10-bit 4:2:0 decoding and encoding acceleration, 1) Sky Lake: ------------ CPU: Info: quad core model: Intel Core i7-6700K bits: 64 type: MT MCP cache: Graphics: Device-1: Intel HD Graphics 530 driver: i915 v: kernel (Device-2: NVIDIA GM206 [GeForce GTX 960] driver: N/A) ~/Application> ./cin-x86_64.AppImage Cinelerra Infinity - built: Nov 20 2024 22:0 Loaded hdv09_04.m2t (tff interlaced) Rendered to hevc_qsv_8b420 --------------------------- libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 66.227 secs, 90.175 fps ffprobe -hide_banner hdv09_04_hevc_qsv_8b420.mp4 Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuvj420p(pc, smpte170m/unknown/unknown, top coded first (swapped)), 1440x1080 [SAR 4:3 DAR 16:9], 4918 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Test hevc_qsv_10b420 failed --------------------------- libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 [hevc_qsv @ 0x7fe508025980] Low power mode is unsupported [hevc_qsv @ 0x7fe508025980] Current pixel format is unsupported [hevc_qsv @ 0x7fe508025980] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. FFMPEG::open_encoder err: Function not implemented int FFMPEG::open_encoder(const char*, const char*): open failed hevc_qsv:/run/media/terje/video/hdv09_04_hevc_qsv_10b420.mp4 Render::render_single: Session finished. 2) Kaby Lake ----------- CPU: Info: quad core model: Intel Core i7-8550U bits: 64 type: MT MCP cache: Graphics: Device-1: Intel UHD Graphics 620 driver: i915 v: kernel ~/Application> ./cin-x86_64.AppImage Cinelerra Infinity - built: Nov 20 2024 22:0 Loaded hdv09_04.m2t (tff interlaced) Rendered to hevc_qsv_8b420 --------------------------- libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 59.564 secs, 100.262 fps ffprobe -hide_banner hdv09_04_hevc_qsv_8b420.mp4 Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuvj420p(pc, smpte170m/unknown/unknown, top coded first (swapped)), 1440x1080 [SAR 4:3 DAR 16:9], 4018 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Rendered to hevc_qsv_10b420 --------------------------- libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 79.061 secs, 75.537 fps ffprobe -hide_banner hdv09_04_hevc_qsv_10b420.mp4 Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(pc, smpte170m/unknown/unknown, top coded first (swapped)), 1440x1080 [SAR 4:3 DAR 16:9], 25630 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Test hevc_qsv_10b422 failed: ---------------------------- libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 [hevc_qsv @ 0x7f8e74000bc0] Low power mode is unsupported [hevc_qsv @ 0x7f8e74000bc0] Current pixel format is unsupported [hevc_qsv @ 0x7f8e74000bc0] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. FFMPEG::open_encoder err: Function not implemented int FFMPEG::open_encoder(const char*, const char*): open failed hevc_qsv:/home/terje/Videos/hdv09_04_hevc_qsv_10b422.mp4 Render::render_single: Session finished. Conclusion: ------------------- The above simple tests show that the QSV enabled Appimage with OneVPL works also on legacy and other Intel hardware.

3 24