MantisBT - Issues

0000674: Crash when using undo in projects with nested EDLs

Wed, 11 Mar 2026 00:19:30 +0100

When using nested EDLs, cinelerra-gg will crash often when undoing operations. These could be keyframe updates (fading etc..) or cutting operations.

0000673: Cinelerra-GG Build Issues on Ubuntu 24 with CUDA 13.1

Fri, 06 Mar 2026 15:52:19 +0100

Inukshuk with his team noted problems building CinGG on Ubuntu 24 with CUDA 13.1. The last time it is known that anyone built with Cuda it was version 10 in 2019 as briefly documented in the manual at:
https://download.cinelerra-gg.org/files/CinelerraGG_Manual/Effects_OpenCL_Cuda.html
The team provided these details on the problems.

-I-
Cinelerra-GG Build Issues on Ubuntu 24 with CUDA 13.1
Environment

OS: Ubuntu (Studio) 24
GPU: NVIDIA GeForce RTX 2070 (compute capability 7.5)
CUDA Version: 13.1
Driver Version: 590.48.01

Issue 1: Unsupported CUDA Architectures

Error:

nvcc fatal : Unsupported gpu architecture 'compute_35'

Cause: The file plugin_cuda specifies GPU architectures that are no longer supported by modern CUDA toolkits:

SMS ?= 35 37 50 52 60 61 70 75

CUDA 13.1 has dropped support for compute capabilities below 7.0 (or possibly 7.5). The build failed even after removing 35/37, then again on compute_50.

Fix: Changed SMS line in plugin_cuda to only include 75 (or other modern architectures).

Recommendation: The build system should detect the installed CUDA version and automatically select only supported architectures, or at minimum document which CUDA versions are compatible.
Issue 2: Missing CUDA Samples Headers

Error:

helper_cuda.h: No such file or directory

Cause: The build expects CUDA samples to be installed at /usr/local/cuda/samples/common/inc/, but CUDA samples are not included with the CUDA toolkit by default and must be cloned separately from GitHub.

Fix: Cloned https://github.com/NVIDIA/cuda-samples.git to /usr/local/cuda/samples/
Issue 3: CUDA Samples Directory Structure Changed

Error (after cloning samples):

helper_cuda.h: No such file or directory

Cause: The newer cuda-samples repository uses Common/ (capital C) instead of common/inc/.

Fix: Created symlink:
bash

sudo mkdir -p /usr/local/cuda/samples/common/inc
sudo ln -s /usr/local/cuda/samples/Common/*.h /usr/local/cuda/samples/common/inc/
```

---

### Issue 4: nbodycuda Plugin - Changed Sample Paths

**Error:**
```
5_Simulations/nbody/bodysystemcuda.h: No such file or directory

Cause: The nbodycuda plugin expects N-body simulation files at 5_Simulations/nbody/, but the current cuda-samples repository places them at Samples/5_Domain_Specific/nbody/.

Fix: Created symlink:
bash

sudo mkdir -p /usr/local/cuda/samples/5_Simulations
sudo ln -s /usr/local/cuda/samples/Samples/5_Domain_Specific/nbody /usr/local/cuda/samples/5_Simulations/nbody

0000647: Audio segfaults on termux

Thu, 08 Jan 2026 19:21:49 +0100

I was unable to dig WHY it fails afternearly 3 years.

So, just gdb output for now.

0000216: Support for PowerPC (BE and LE variants)

Thu, 08 Jan 2026 19:20:10 +0100

Back in February Daniel Reurich started thread about compiling Cinelerra-GG on ppc64le (power8/power9 platform).
https://lists.cinelerra-gg.org/pipermail/cin/2019-February/000351.html

I only have emulated machines of this type, via qemu (3.1+, 4.0+). I did few hacks back in time, but none of my builds resulted in working Cin - on ppc64le it was lack of ALL icons and crashes, on ppc32 BE (without altivec) Cin just failed to start GUI at all - crashes again ....

BCSignals _compilation_ issue was fixed in https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=commit;h=3932d2c16e903573db3cacdb3102dea9639c6ca4, but other issues probably not ....

0000672: Crash when using the speed curve

Tue, 08 Apr 2025 22:13:38 +0200

Version:
CinGG-20250228-x86_64-older-distros.AppImage
Linux Mint 19.3
8 GB memory
ulimit -n 4096

I made a film with 30 minutes, 4 video tracks 1280x720 with 250 clips, 6 audio tracks. Everything works without problems, but when I try to move the speed curve to create a new keyframe or to change its value, Cinelerra always crashes:

** segv at 0xb1b5e5 in pid 12179, tid 12179
writing debug data to /tmp/cinelerra_12179.dmp
lock_items: 39
lock_frees: 5
** dump complete
Segmentation fault (core dumped)

I also tried it on another similar film and it also always crashes. If I make a new test project with 1 video track with 30 clips and 2 audio tracks, I can move the speed curve without problems. If I manually add speed keyframes in the big project's XML file ( ), the change works without problems, but I must not move the speed curve using a mouse.

0000670: User Defined Blend Algebra

Tue, 11 Mar 2025 22:02:51 +0100

Sometimes there appear again questions / complains regarding overlay blending in Cinelerra, that something appears strange, or not exactly that as in Gimp (or in whatever), or not in that art the user needs. Fighting such windmills seems not worth while.

The idea came to provide 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.

The presented patch cgg-blendalgebra.diff.gz provides two similar plugins which try to realize this goal. The only modification to Cinelerra is the addition of these completely new plugins. Applying the patch to Cinelerra cannot break anything.

After applying the patch to Cinelerra sources, and before executing `make', make sure 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.

0000667: Random audio pops make using Cinelerra-GG for mastering a maddening task

Thu, 30 Jan 2025 00:55:29 +0100

Version: CinGG-20241031-x86_64.AppImage (Fedora 41)

Certain things - mainly filters - and in particular the freeverb and graphical equalizer filters (two of the most important when mixing audio) can add subtle (or sometimes not so subtle) pops into the audio. They're incredibly difficult to track down, and it's so much work to isolate them that before now I've not spent the many hours to try to narrow down a fill project into a simple test case. It's to the point where I'm seriously thinking about just giving up on Cinelerra-GG for music; I can't keep having the program ruin my tracks by introducing random pops :(

I also do not believe that they represent a single problem, but rather multiple problems. In the process of submitting this, due to your incredibly low file size limit (come on, this is a bug report page for a media tool!), I tried converting my samples to m4a encoded with ffmpeg, and the problem *didn't* occur, whereas on FLAC it did (then again, these things are so random, who knows?). But the behavior is different for different types of bugs - for example, with freeverb, the pops seem most common when it's shifting parameters from one keyframe to the next (for example, amping up the wetness).

In none of these cases is there any clipping.

0000668: Random audio pops make using Cinelerra-GG for mastering a maddening task (#2)

Sat, 25 Jan 2025 18:19:19 +0100

Probably relates to: https://www.cinelerra-gg.org/bugtracker/view.php?id=667
Version: CinGG-20241031-x86_64.AppImage (Fedora 41)

This is possibly the same bug as the last one, only more egregious (though as it's more egregious, it was thankfully easier to track down and isolate). One track (no_vocals.flac) plays. It has two neutral equalizers. The second track (vocals_new.wav) *is muted* and should have zero impact; it shares one equalizer with the first track. Yet when the second (muted) track begins, there is a pop. If you do anything - shut off either or both equalizers, or disable play for the muted track, or outright delete it - the pop goes away.

Two rendered examples are also included in the .xml file, one with the bug and one without the bug.

Note that unlike the last bug, this one doesn't need to be rendered to appear - it occurs even when just playing the track in Cinelerra.

Like with the last bug, since your maximum upload size is a mere 4,77MB, tracks are split and need to be catted back together to be recombined.

0000666: Labels get positioned at about twice the time from when they were created after save/exit/reload/

Fri, 06 Dec 2024 22:23:14 +0100

CinGG built from git 2024-11-24 , not the AppImage version.

Allocation multiple labels and naming them, then saving, and exiting CinGG. Then reload CinGG, via File->Load recent open the saved settings in the .xml file. Jumping back and forth between labels and checking their names, shows they are positioned on about twice the time distance from the beginning.

No errors are shown in the terminal CinGG was started from.

0000665: JPEG color range rendering (to x264 file) is broken while using YUV 8-bit color model

Fri, 27 Sep 2024 01:19:48 +0200

The result of rendering always has an increased contrast when using JPEG color range + YUV 8-bit color model.
The rendered colors differ both from composite window and source video.
Color mismatch appears no matter if the source video was in full or limited color ranged (tested both). So the issue should be reproducible on any video (if I'm not wrong).
There are no way to compensate the issue using ColorSpace or F_colorspace (I've tried).
The setting in File -> Render -> Video -> Pixels doesn't help either.

0000650: Syntax error : "(" unexpected when patch for Multibit in x265

Fri, 06 Sep 2024 21:08:49 +0200

To compile x265 for addition 10 and 12 bit by patching with ./thirdparty/compile_multibit.txt, a bash shell, multibit.sh is executed. This shell (at least I think it comes from the shell) has the error "/bin/sh: 1: Syntax error : "(" unexpected" which does not prevent compilation but is distracting when looking for errors in the build log file.

Ran the program "shellcheck" on Fedora on multibit.sh and all it found was warnings and style issues but no unexpected (. Maybe the error is from ./thirdparty/Makefile line "x265.cfg_vars?=chmod +x ./configure; chmod +x ./multilib.sh;" but I could not determine if that is so.

0000663: The Around operation in a filter has no effect

Sat, 29 Jun 2024 14:36:19 +0200

According to the User Manual, the Around operation should set a search range: [target-radius... target+radius]. Any media files outside this range shouldn't be in the user folder. However, the Around operation doesn't affect file filtering.

0000662: New Chroma Key (Avid) and Color Swatch plugins ported from Cinelerra-HV

Fri, 21 Jun 2024 04:06:46 +0200

Some time ago Andrea asked me if I could try to port the new Adam's implementation of ChromaKeyHSV plugin based on the Avid SpectraMatte algorithm from Cin-HV to Cin-GG. Here it is.

The patch attached contains two plugins completely new to CinGG, plus supplementaries like expanders.txt and Makefiles. After applying the patch nothing in the existing code will change, all changes are located in these two new plugins. So, the patch cannot break anything in the existing code.

The new ChromaKey plugin executable is called chromakeyavid.plugin, and its name in the CGG Resources window is "Chroma key (Avid)", to differentiate it from the former unchanged version, which is called "Chroma key (HSV)" as always. If, after testing and evaluation, we conclude renaming the new plugin and removing the old one, such renaming itself will be not difficult. But then, the old projects which used the old version of "Chroma key (HSV)" will not work, because "Chroma key (Avid)" has different parameter set and different behavior.

As Adam recommends to do ChromaKey adjustments in connection with another utility plugin, named "Color Swatch" (its executable is swatch.plugin), I ported this second plugin too.

Please try to apply patch and test the new plugins "Chroma key (Avid)" and "Color Swatch", if they are useful. Some description of the parameters is given in Cin-HV's bin/doc/cinelerra.html, more detailed description with examples by Igor Vladimirsky is here: https://linuxvideoediting.blogspot.com/2024/04/chroma-key-hsv-cinelerra.html (it is in Russian but perhaps your browser can translate it).

Remember, any manipulations with alpha masks, including chromakeying, in CinGG require a bottom track with some opaque background, otherwise the transparent holes are displayed as if the same track without transparency be located under it. Although this behavior is sometimes confusing, I am not sure if it is a bug, and not done so by design.

0000661: New latex2html option '-unicase_titles' checks duplication of filenames for HTML pages in case insensitive manner

Wed, 12 Jun 2024 15:33:48 +0200

To produce CGG HTML manual, we execute latex2html with the option -long_titles 5. Latex2html, up to now, examines generated filenames for HTML pages on duplication and, if necessary, adds an incremented number to each detected duplicated name. However, latex2html compares filenames in case sensitive manner. If several files appear whose names differ in letter case only, latex2html will treat them as different, and if that files later will be copied to some case insensitive filesystem, such as NTFS or FAT, that files will conflict. Moreover, usually latex2html creates the auto-linked file 'index.html' which under case insensitive filesystems can conflict with the Index page, 'Index.html' which exist in many big document, including CGG manual.

To overcome this, I have added the new option to latex2html: -unicase_titles. With this option latex2html will check filenames for duplication in case insensitive manner (and add incremented digit to the name when necessary). To get this option, either apply the patch latex2html-2024-unicasetitles.diff.gz to some recent latex2html sources and then reinstall them, or perform build of latex2html from its git master tree (Dan Gildea already committed my unicasetitles patch to the git tree).

When having applied this unicasetitles patch, one can translate HTML manual using this new option in addition to all the others, like in the attached 'translate_manual' script (residing under 'manual' git tree). Then, when using the new option, the file 'Index.html' with the Index will be renamed to 'Index2.html' but otherwise work as before.

When the -unicase_titles option will be used, we will need also updated ContextManual.pl script (residing under 'cinelerra5' git tree), because ContextManual.pl used Index.html to search for some keyphrases. The new ContextManual.pl script finds the actual filename for the Index (Index.html, Index2.html, or whatever) automatically from the 'Contents.html' file.

To easily check for existence of filenames which differ only in case, the following shell command can be used:
ls | sort -f | uniq -di

0000659: Long record with splitted MTS files

Sun, 09 Jun 2024 23:02:41 +0200

Due to FAT16/FAT32 limitation, camera using MTS files split it into chunks during long record.

MTS files use frames for audio and video. On some camera, a frame can be divided between the two files. Cinelerra cannot recover this lost frame even if it have all data.

A function to virtually join those chunks from a long record will be helpful.

0000559: Fade In/Fade out flash bug

Fri, 31 May 2024 18:16:06 +0200

"Fade black flash" bug reported in the Mailing List around March 7/8, 2021. More information follows from IgorB:

I confirm the bug reported by Camille.
Here two videos about Title effect and Image with Dissolve Transition:
https://streamable.com/86y59m
https://streamable.com/ywcaee

This is my trick to solve it:
https://streamable.com/vkp9ou

0000657: ChromaKeyHSV "Min Saturation" not working correctly

Thu, 30 May 2024 21:10:10 +0200

This was reported in the Mailing List, but putting here in case someone comes along that only looks at the Bug Tracker.
Andrea summed up the problem this way:
"In practice, "Min Saturation" behaves like "Saturation Offset" when invfact it should behave as in the following figure:
https://postimg.cc/HjZDcvr2" (this may no longer be visible).
"(Min Sat should form a new smaller wedge [dotted line], instead it creates an arc without more spike, which is the right behavior of Sat Offset)."

0000654: AgingTV plugin allows for picking type of aging, but slider amount seems to be ignored.

Thu, 16 May 2024 17:25:02 +0200

If everything is unchecked and then one of the 3 items of Scratch, Pits, or Dust is checked BUT set to zero, you can still see that item in the compositor. So it looks like the slider number value is ignored. However, it looks like my interpretation of the slider is wrong -- instead of the number of items display, maybe it is the interval between when the item appears but it does not really look like it; in which case the documentation is wrong. Grain is either on or off and works as expected.

The good news is that at least you can designate which type of aging you want, be it grain, scratch, pits, dust, or all or none.

0000655: SIGSEGV AV1 AOM encode

Wed, 15 May 2024 18:09:22 +0200

When I encode to AV1 I often get SIGSEGV:
99% ETA: 0:00:10 ** segv at 0x7fe323058ce0 in pid 1482, tid 8658

dump attached

0000653: At least 1 LV2 plugin works until click on UI button

Sun, 18 Feb 2024 20:42:46 +0100

This is for doing you own builds, not AppImage.
LV2 plugin works fine as long as you do not click on the UI button (not sure if this particular L2 plugin has a graphical interface or not but it seems to). I think this is from the Guitarix GX plugins set.
L2_GxFlanger has this problem but L2_Dj flanger does not. There is a workaround so you can continue using it -- click on the "turn off" button and take down the "show controls" window. Then you can just turn it back on and do NOT hit the UI button any more!

It seems like this is a fixable bug. Error message is:
void PluginLV2Client::process_buffer(int);
timeout: L2_GxFlanger
which comes from cinelerra/pluginv2client.C

0000652: If using AppImage, using Calf Plugins give error

Thu, 08 Feb 2024 20:48:32 +0100

When running CinGG from an AppImage, the graphics ard on the computer that created the AppImage is very likely different from what the user has therefore the UI portion of Calf Plugins can not work. (A different LV2 plugin, drowaudio-flanger.lv2, does seem to work and it has a graphical UI.)
It does not crash but the playhead just jiggles back and forth and there is the error message in a popup window something like:
void PluginLV2Client::process_buffer(int);
timeout: L2_Calf Reverb
Other LV2 plugins that specifically do NOT have a potential UI interface work OK. Error message comes from the following code in pluginlv2client.C

void PluginLV2Client::process_buffer(int size)
{
PluginLV2ParentUI *ui = get_ui();
if( !ui ) return;
shm_bfr->done = 0;
ui->send_child(LV2_SHMID, &shmid, sizeof(shmid));
// timeout 10*duration, min 2sec, max 10sec
double sample_rate = get_project_samplerate();
double t = !sample_rate ? 2. : 10. * size / sample_rate;
bclamp(t, 2., 10.);
ui->output_bfr->timed_lock(t*1e6, "PluginLV2Client::process_buffer");
if( !shm_bfr->done )
eprintf("timeout: %s",server->title);

According to what I found on the internet, you can determine if you are running from an AppImage via:
"If the app is an AppImage, process.env.APPIMAGE contains the path to the .AppImage file, otherwise it is undefined." And then you need to find a programmatic way to determine if running from an AppImage, and somehow skip running code to bring up a UI so that you will be at least able to use the Calf plugin without the UI interface.

0000651: Getting error messages using SVT render with svt_av1.webm or svt_av1.mkv

Sat, 06 Jan 2024 19:28:00 +0100

The output to the terminal window (even though the render seems to succeed) when using svt_av1.webm or svt_av1.mkv is:

Svt[info]: -------------------------------------------
Svt[info]: SVT [version]: SVT-AV1 Encoder Lib v1.8.0
Svt[info]: SVT [build] : GCC 10.3.1 20210422 (Red Hat 10.3.1-1) 64 bit
Svt[info]: LIB Build date: Jan 5 2024 13:17:05
Svt[info]: -------------------------------------------
Svt[info]: Number of logical cores available: 16
Svt[info]: Number of PPCS 140
Svt[info]: [asm level on system : up to avx2]
Svt[info]: [asm level selected : up to avx2]
Svt[info]: -------------------------------------------
Svt[info]: SVT [config]: main profile tier (auto) level (auto)
Svt[info]: SVT [config]: width / height / fps numerator / fps denominator : 352 / 240 / 30000 / 1001
Svt[info]: SVT [config]: bit-depth / color format : 8 / YUV420
Svt[info]: SVT [config]: preset / tune / pred struct : 10 / PSNR / random access
Svt[info]: SVT [config]: gop size / mini-gop size / key-frame type : 161 / 32 / key frame
Svt[info]: SVT [config]: BRC mode / rate factor : CRF / 35
Svt[info]: -------------------------------------------
Svt[warn]: Failed to set thread priority: Invalid argument
FFStream::encode_frame: encode failed.
file: /tmp/aspectno.webm
err: Resource temporarily unavailable
FFMPEG::mux_video err: Operation not permitted
FFStream::encode_frame: encode failed.
file: /tmp/aspectno.webm
err: Resource temporarily unavailable
FFMPEG::mux_video err: Operation not permitted
Render::render_single: Session finished.
** rendered 2713 frames in 13.612 secs, 199.309 fps

As you can see from the above, there are these 3 concerning error messages:
FFStream::encode_frame: encode failed.
FFMPEG::mux_video err: Operation not permitted
err: Resource temporarily unavailable

0000649: lv2 modified configure in the build does not work in Fedora 39

Sat, 06 Jan 2024 17:52:19 +0100

Because it seems that Python 3.12 will not build the lv2 plugins, Andrew used the following successfully on termux and slackware:
./configure --with-lv2 --disable-lv2 --disable-sord --disable-serd --disable-suil --disable-sratom --disable-lilv
However, this does not work as a workaound on Fedora 39, which uses Python 3.12. Errors of can't find headers:

checking for lv2 availability... checking for lilv/lilv.h... no
checking lilv headers... no
checking for serd/serd.h... no
checking serd headers... no
checking for sord/sord.h... no
checking sord headers... no
checking for sratom/sratom.h... no
checking sratom headers... no
checking for suil/suil.h... no
checking suil headers... no

even though lilv-devel is installed as shown below:
Fedora 39
***
root@fedora:/tmp# grep lilv a
lilv-libs.x86_64 0.24.20-1.fc39
lilv.x86_64 0.24.20-1.fc39
lilv-devel.i686 0.24.20-1.fc39
lilv-devel.x86_64 0.24.20-1.fc39
lilv-libs.i686 0.24.20-1.fc39
python3-lilv.x86_64 0.24.20-1.fc39

0000646: Compositing routines in RGB(A) float clamp to 1.0f

Sun, 26 Nov 2023 22:09:18 +0100

A bit unexpected for users?

Cinelerra-CV at least does not do this.

Mail list discussion: https://lists.cinelerra-gg.org/pipermail/cin/2023-November/007186.html

Cin HV issue/question: https://github.com/heroineworshiper/hvirtual/issues/8

0000596: Crash when uploading files-video cin gg 32bits

Sun, 26 Nov 2023 02:58:25 +0100

error while loading shared libraries: libva.so.1
Rename:
libva.so.2 to libva.so.1
libva-x11.so.2 to libva-x11.so.1
libva-drm.so.2 to libva-drm.so.1

I got into the interface but I can't upload files.
I can render video, upload images and upload audio.

I can't upload video.
codecs tried:

H264
VP8
MPEG2video

I use the November and October version appimage i386.