- Cin - Cinelerra-GG Mailing Lists

Tested vaapi hwaccel presets
by Terje J. Hanssen 20 Feb '25

20 Feb '25

Attached tested vaapi hwaccel presets as gzip'd tar file av1_vaapi_10b420.mp4 av1_vaapi_10b420.webm av1_vaapi_8b420.mp4 av1_vaapi_8b420.webm h264_vaapi_8b420.mp4 hevc_vaapi_10b420.mp4 hevc_vaapi_10b422.mp4 hevc_vaapi_8b420.mp4 vp9_vaapi_10b420.mp4 vp9_vaapi_10b420.webm vp9_vaapi_8b420.mp4 vp9_vaapi_8b420.webm

4 25

flac 1.5.0 is out
by Andrew Randrianasulu 20 Feb '25

20 Feb '25

https://github.com/xiph/flac/releases/tag/1.5.0 should support multithreaded encode, but you need to call newly added function for that https://xiph.org/flac/api/group__porting__1__4__3__to__1__5__0.html ===== the function FLAC__stream_encoder_set_num_threads and FLAC__stream_encoder_get_num_threads have been added, which can be used to enable multithreading in the encoder =====

2 2

User Defined Blend Algebra
by Georgy Salnikov 16 Feb '25

16 Feb '25

Dear CinGG users, Does anybody want to taste something brand new and unusual? Here is the patch attached: cgg-blendalgebra.diff.gz Apply this patch and rebuild CinGG. The only change is the addition of two completely new video effects, Blend Algebra and Blend Program. The main CinGG code is not affected, so applying the patch is harmless and cannot break anything. After applying the patch, and before executing `make', check that the new created scripts plugins/blendalgebra/BlendAlgebraCompile.pl and plugins/blendprogram/BlendProgramCompile.pl possess executable permissions. After successful `make', don't forget to run `make install': without several important files which must be installed, the new plugins cannot work. Motivation ========== Sometimes there appear again questions / complains regarding overlay blending in Cinelerra, that something appears strange, or not exactly that way as in Gimp (or in whatever), or not in that art the user needs. Fighting such windmills does not seem worth while. The idea here is to create a new specific plugin where the user could program sufficiently short and simple blending algorithms according to his requirements. And of course, without demanding from the user too much programming skills. Firstly I'd like to make a short introduction, a small demo what one can do with the new features. The shortest demo projects are attached here, for several longer ones I'll give the links to download them. This development is already posted to CinGG bugtracker as BT670: https://www.cinelerra-gg.org/bugtracker/view.php?id=670 To look on the following example functions, there is 'Edit...' button in the respective plugin dialog, but you may need a text editor. By default, it is `emacs', and nothing has to be done if it is installed. If not, you can set your favorite editor via the corresponding environment variable, like those: export CIN_EDITOR=kate export CIN_EDITOR=nedit export CIN_EDITOR='konsole -e vim' If text editor is a console editor without its own GUI, it must be run from some terminal emulator, like `xterm' or `konsole'. To open editor from the plugin dialog, some function must be active at that timeline position (its name in text field not empty). Currently, pressing the 'Edit...' button on the empty function does nothing. Either select some existing function first, or enter a name to create a new one from scratch. Example 1. ---------- See ovl2.tar.gz in the attachment Let's say, we are going to write our own implementation of the Arithmetic Subtract overlay function, according to the formula from CinelerraGG manual. Such a function, attached to the Blend Algebra plugin, could look as follows. ------------------------------------------------------------------------ BLEND_ALGEBRA_INIT /* this is a required statement */ COLORSPACE_RGB /* our working color space, can be also YUV or HSV */ PARALLEL_SAFE /* can be safely parallelized */ REQUIRE_TRACKS(2) /* refuse to work if only one track is given */ BLEND_ALGEBRA_PROC /* this is a required statement */ #define s 1 /* mnemonics for source and destination */ #define d 0 R_OUT = R(s) - R(d); /* for red, green, blue, alpha: */ G_OUT = G(s) - G(d); /* result = source - destination */ B_OUT = B(s) - B(d); A_OUT = A(s) - A(d); BLEND_ALGEBRA_END /* this marks the end of our program */ ------------------------------------------------------------------------ And here is an Arithmetic Addition variant, working on any number of tracks. ------------------------------------------------------------------------ BLEND_ALGEBRA_INIT COLORSPACE_RGB PARALLEL_SAFE BLEND_ALGEBRA_PROC int i; R_OUT = G_OUT = B_OUT = A_OUT = 0; /* preinitialize results */ for (i=0; i<TOTAL_TRACKS; i++) /* repeat for all tracks */ { R_OUT += R(i); /* accumulate sum for R,G,B,A */ G_OUT += G(i); B_OUT += B(i); A_OUT += A(i); } BLEND_ALGEBRA_END ------------------------------------------------------------------------ Blend Algebra functions are keyframable, i.e. switchable between plugin keyframes. Untar the ovl2.tar.gz archive from the attachment, load the ovl2.xml project and play it. You can see 30 different functions switched one after another. The source files of the functions have the suffix '.ba'. Example 2. ---------- Let's look on the following short Blend Algebra function: ------------------------------------------------------------------------ BLEND_ALGEBRA_INIT COLORSPACE_YUV PARALLEL_SAFE REQUIRE_TRACKS(2) BLEND_ALGEBRA_PROC Y_OUT = (Y(0)-Y(1))/2+0.5; U_OUT = V_OUT = 0; A_OUT = 1; BLEND_ALGEBRA_END ------------------------------------------------------------------------ What do you think this is? It is nothing else as the famous `ydiff' program, written in less than 10 lines of code and working not externally, but directly inside a Cinelerra plugin. Although this is not yet so complete, the standard ydiff program has an argument to enhance or reduce the difference effect, but we can easily add it here, too: ------------------------------------------------------------------------ BLEND_ALGEBRA_INIT COLORSPACE_YUV PARALLEL_SAFE REQUIRE_TRACKS(2) BLEND_ALGEBRA_PROC Y_OUT = (Y(0)-Y(1))/2*exp((KEY_A-0.5)*14*M_LN2)+0.5; U_OUT = V_OUT = 0; A_OUT = 1; BLEND_ALGEBRA_END ------------------------------------------------------------------------ Here we changed only the expression for Y, adding a factor which depends on the KEY_A parameter in logarithmic scale. The KEY_A parameter itself is interactively controlled by the opacity slider in the Blend Algebra plugin dialog. Good, the ydiff program additionally prints some statistics. This printout can also be implemented by us, although the program becomes slightly more complex: ------------------------------------------------------------------------ static int npix=0; /* these variables will accumulate statistics */ static float sum=0, sabs=0; /* parallelizing not possible here */ BLEND_ALGEBRA_INIT COLORSPACE_YUV REQUIRE_TRACKS(2) printf ("sz=%8d err=%10g abs=%10g", npix, sum, sabs); if (npix > 0) printf (" rel=%10g", sabs*256/npix); printf ("\n"); /* here we print statistics in CGG console */ sum = sabs = 0; /* and clear accumulators for the next frame */ npix = 0; BLEND_ALGEBRA_PROC float diff; diff = Y(0)-Y(1); sum += diff; /* update accumulators */ sabs += ABS (diff); npix ++; Y_OUT = (Y(0)-Y(1))/2*exp((KEY_A-0.5)*14*M_LN2)+0.5; U_OUT = V_OUT = 0; /* and make video track output */ A_OUT = 1; BLEND_ALGEBRA_END ------------------------------------------------------------------------ The statistics is printed in the terminal emulator from which Cinelerra was started. You can look in the ydiff.tar.gz archive. In the project ydiff.xml there are two identical tracks displaced by 1 frame. The ydiff.ba function from the archive has the commented out line #define NO_PRINTOUT. It works slowly because of statistics printout. If you uncomment this definition, statistics will be switched off, the function will run parallelized, noticeably faster. The ydiff.tar.gz archive with this demo can be downloaded from CGG bugtracker (2.5 Mb): https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=995&type=… Example 3. ---------- Untar the example archive transitions.tar.gz and load the project transitions.xml. It demonstrates how transition-like effects can be imitated by a Blend Algebra function. Here, depending on the current value of the opacity slider from plugin's dialog, interpolated between keyframes, and the (X,Y) pixel coordinates, the function takes pixels from either track #0 or track #1. The transitions.tar.gz archive with this demo can be downloaded from CGG bugtracker (2.5 Mb): https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=996&type=… Example 4. ---------- Untar the archive swap.tar.gz and load the project swap.xml. Now there is another companion plugin, Blend Program, with its function swap01.bp (ending with the .bp suffix). This example resembles the preceding one which imitated transition. The main difference here is that blend program does not return a function result, but modifies any given tracks directly. The program from this example swaps two tracks, along a transition controlled by keyframable interpolated opacity parameter. To see the effect, the bottom track is up-down reflected, and the top one has a mask applied, through which one can see that the bottom track is also being changed. The swap.tar.gz archive with this demo can be downloaded from CGG bugtracker (2.5 Mb): https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=997&type=… Example 5. ---------- The preceding example was perhaps somehow artificial demo, not too close to reality. Let's now suggest another application which could be really useful. Untar the ck.tar.gz example from the attachment and load firstly the project ck.xml. There is a still picture and a second track with solid white background on bottom. The blend function attached is: ------------------------------------------------------------------------ BLEND_PROGRAM_INIT COLORSPACE_HSV PARALLEL_SAFE BLEND_PROGRAM_PROC if (ABS(H(0)-KEY_H) < KEY_A*100) A(0) *= SQR((H(0)-KEY_H)/KEY_A/100); BLEND_PROGRAM_END ------------------------------------------------------------------------ It is a rather complete chromakey plugin, writable by user in only six lines of code! Isn't it cool! With these two new small plugins one can do really much! I do not know if a similar functionality exists in any other NLE. Here if the 'Hue' component (in HSV color space) differs from that of the key color defined in the plugin dialog less than by the amount scaled by the opacity slider, the aplha component (the transparency) is set proportional to the squared difference (completely transparent where the two Hues are identical). You can open plugin dialog and turn the slider in it to the left and right and see its effect. Now load another project from here, ckbg.xml. Now there is only one track with the same picture. Instead of the second one which contained the background, there is one more Blend Program plugin attached, its function generating the desired background by itlesf. The background color is set via the color selection dialog of that second Blend Program plugin GUI. ======================================================================== Those who have realized that are not interested in the new features at all, can stop reading here. Who has some interest to try, welcome to read the more detailed README.blendalg description from attachment. As a starting tutorial one could, for example, take some of the overlay functions, modify it to calculate according some other formula and look what changes. Or take the 'background' blend program and implement some dependency on PIX_X and/or PIX_Y to convert solid background to a gradient. If some details in the description attached look too difficult to understand, don't bother, skip unclear sections - perhaps everything will work fine also without reading them. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email sge(a)nmr.nioch.nsc.ru _______________________________________________________________________________

3 14

Wayland
by Andrea paz 12 Feb '25

12 Feb '25

My curiosity: I don't use Wayland because I have a widegamut monitor and use a color space greater than sRGB. I was wondering how CinGG works on Wayland, or rather, on XWayland. Has anyone tried it? I am mainly referring to the color part, but also the performance.

4 4

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