- Cin - Cinelerra-GG Mailing Lists

Patch that might fix parallel make install
by Andrew Randrianasulu 04 Feb '26

04 Feb '26

Well, two patches may be fixing parallel make install, because I was confused about what fixed it usual "make install" works ok But if T2's system used "make install -j20" (by default) - our Makefile failed .. I think two attached patches fix that case? I tested them on Termux with system-wide install, and single-user build/install

2 1

February 2 updated release / AppImages
by Phyllis Smith 04 Feb '26

04 Feb '26

Updated AppImages, pdfs, etc. at: https://download.cinelerra-gg.org . By doing a release the TAG gets updated in GIT source so other builders out there and non-thirdparty builds will get the updates. Still no Vulkan or OneVPL included in AppImages, even if possible, but working on that more now. Release notes additions below: GIT for Cinelerra-GG has the following changes from 01/01/2026-02/02/2026 Added *Desktop_icon* folder to website download area for easy access for AppImage users for creating the CinGG desktop on their computer along with a README file for “how to”. Modified versioninfo.h to update year from 2025 to 2026. Updated render formats for h264 which approximate results similar to other NLEs provided by *Glen*: h264.mkv, h264.mov, h264.mp4. *Andrew-R *work: Added ppc64l2 to guicast/Makefile for PowerPC processors on qemu – tested on Arch PowerPC + pa-risc support in a separate patch added. Updated wintv/x10tv C files used to watch and record TV from CinGG as the “time” structure disappeared for some event-related kernel API as first noted building pa-risc Debian 13. Another needed patch for installing non-thirdparty with mods to Makefile.am and configure.ac. *Documentation *updates: CinGG_Quickstart.pdf has been updated and re-formatted by *Andrea* in the website Download area. CinGG_Quickstart_Batch.pdf is now also in the Download area as previously created by *Rafa*. The Manual “Installation” section has some revisions but more are still being worked. Note: to build Debian 9.1 i386, you will need to revert to building with the x264 library version r3106 if you want to load and/or render using h264 or upgrade to nasm 2.15.05. Discovered by Andrew.

2 1

Re: Fwd: Cinelerra FFMPEG Questions
by Andrew Randrianasulu 03 Feb '26

03 Feb '26

вт, 3 февр. 2026 г., 20:57 Andrew Wesly <andrewwesly(a)gmail.com>: > Hello, > > Thank you very much for the feedback. Does Cinelerra support dual GPU > rendering such as with Nvidia SLI or AMD Crossfire technology? > No. Moreover, opengl is only used for some realtime preview of filters, not for final rendering. You might want to check if v-sync actually disabled (for cingg application at least) if you use opengl-x11 output mode - it will be faster this way. In theory you can try to DEcode on intel igpu and Encode on nvidia dGPU, but I am not sure if it will be faster or not. (there are two environmental variables for vaapi device selection, not tried vaapi decoding + nvenc encoding due to lack of such setup). Try selecting vaapi for hw device, then nvenc profile for encoding and see if it works at all? You can try to create fifo file with mkfifo, use it as (video-only) output file from Cinelerra-gg, using y4m format, and from another terminal let system's ffmpeg eat frames from this source and drive nvenc outside of cinelerra-gg's use of libav* libraries. Might work better for speed, but you need to add audio separately. You can also check if you can change GPU speed manually to performance, at least some AMD GPUs were seen to be stuck in low-power mode while encoding. You can also try to compile cinelerra-gg from source, in case it was some header/driver mismatch between what was used on machine building Appimage and your. > Many thanks, > Andrew Wesly > > > On Sat, Jan 31, 2026 at 4:57 PM Andrew Randrianasulu < > randrianasulu(a)gmail.com> wrote: > >> >> >> сб, 31 янв. 2026 г., 23:08 Andrew Wesly <andrewwesly(a)gmail.com>: >> >>> Hello Andrew, >>> >>> Thanks for the suggestions so far. How do I enable more CPU usage in >>> software rendering? Is it under "Project SMP CPUs"? >>> >> >> I think right now it (number of threads for decoding specifically) >> hardcoded to max 8 cpu per video track ... Assuming users want more than >> one track of video + some effects + encoding. >> >> >> [image: image.png] >>> >>> It looks like the NVIDIA GPU is used when the following profile is >>> selected with cuda as the HW device: >>> [image: image.png] >>> However from NVTOP it does not look to be optimal. The yellow line shows >>> memory usage during the render. The drop in the line shows the render has >>> finished. It doesn't look like the GPU is used optimally. Here is a >>> screenshot of a render in progress and then it finishes with the yellow >>> line dropping (render done): >>> >> >> yeah. >> >> Be sure to select project format RGB(A)-FLOAT otherwise it will be >> truncated to 8 bits per channel ... >> >> >> >> [image: image.png] >>> >>> Is there a way to tweak these settings? >>> >> >> >> there are Video Options behind this gui button - basically same that >> ffmpeg exposes. You can play with them. >> >> >> >>> Also, alternatively I've tried using VDPAU with the NVENC decoder. >>> Attached is the VDPAUINFO output that shows vdpau is correctly installed on >>> my system and that it recognizes the NVIDIA card. >>> The error that I get from Cinelerra is as follows: >>> >> >> Not sure if hevc with 4:2:2 subsampling and 10bits per color channel is >> supported well via vdpau, I only had nvidia hardware with support for 8bit >> h264 and AMD hardware for hevc 10 bit 4:2:0. (and older Intel hw from 2011, >> so no hw HEVC decoding/encoding there too) >> >> >> >> [image: image.png] >>> >>> >>> >>> I really appreciate all of the support! >>> >> >> I suspect this might be mismatch between headers we use and what driver >> exposes, but then it should error out at rendering? >> >> Does av1 or vp9 (or even h264) hw encoding in cinelerra-gg works for you, >> if your hw support those? Just to see if may be hevc specifically is >> underperforming. You can also drop this Pixels value back to 4:2:0 10 bit, >> and see if it works better? Again, just as test to see if this specific >> setting causes some confusion >> >> >> >> >>> Many thanks, >>> Andrew Wesly >>> >>> >>> >>> >>> On Thu, Jan 29, 2026 at 8:53 PM Andrew Randrianasulu < >>> randrianasulu(a)gmail.com> wrote: >>> >>>> >>>> >>>> пт, 30 янв. 2026 г., 07:04 Andrew Wesly <andrewwesly(a)gmail.com>: >>>> >>>>> Hello,pp >>>>> >>>>> Here is an update. I'm running Fedora 43 natively on an NVIDIA RTX >>>>> 3070 TI Laptop GPU. FFMPEG is able to use the GPU to render the video. We >>>>> see the GPU usage pegs in NVTOP: >>>>> [image: image.png] >>>>> >>>>> Above from FFMPEG Command line >>>>> >>>>> [out#0/mp4 @ 0x5579e3f47f00] video:371916KiB audio:233859KiB >>>>> subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: >>>>> 0.183394% >>>>> >>>>> frame=37380 fps= 73 q=31.0 Lsize= 606885KiB time=00:20:47.14 >>>>> bitrate=3986.4kbits/s speed=2.43x >>>>> >>>>> >>>>> Cinelerra renders the video using only the CPU cores on the machine. >>>>> NVTOP shows that the Nvidia graphics card is not used, yet all of the cores >>>>> are used when hvec_nvennc is selected: >>>>> >>>> >>>> ah, it was gnome component using second gpu, not cingg. >>>> >>>> Be sure to select cuda/nvdec for hardware *decoding* acceleration if >>>> you use that, so it will not try to decode on Xe iGPU and then push over >>>> pcie to nvidia. >>>> >>>> Does situation change if you run purely software hevc encode, as >>>> selected by encoding preset? >>>> >>>> >>>> you have 20 cpu cores and I found it strange it uses only 4? Check >>>> threads= parameter in software hevc encoder? >>>> >>>> if whole thing have some energy-efficient but slow cores try to disable >>>> them temporarily, or launch cingg via taskset -c only on big cores? >>>> >>>> you can try to increase verbosity of encoder by adding something like >>>> >>>> loglevel=debug (or verbose) >>>> >>>> to encoding profile? >>>> >>>> >>>> >>>> >>>> [image: image.png] >>>>> [image: image.png] >>>>> >>>>> >>>>> >>>>> I'm using CinGG-20251231-x86_64.AppImage. Please advise. >>>>> >>>>> >>>>> Many thanks, >>>>> >>>>> Andrew Wesly >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jan 19, 2026 at 7:49 PM Andrew Wesly <andrewwesly(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Hello Andrew, >>>>>> >>>>>> Excellent suggestion to try native execution on Fedora. I'll try that >>>>>> as well as using a Linux distribution that has Cinelerra integrated into >>>>>> it, such as AVLinux or BodhiMedia. >>>>>> >>>>>> Due to my availability I'll probably get back to this email by the >>>>>> end of this week with my findings. >>>>>> >>>>>> I really do appreciate all of the help so far! >>>>>> >>>>>> Many thanks, >>>>>> Andrew Wesly >>>>>> >>>>>> On Sun, Jan 18, 2026 at 8:52 PM Andrew Randrianasulu < >>>>>> randrianasulu(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> пн, 19 янв. 2026 г., 06:42 Andrew Wesly <andrewwesly(a)gmail.com>: >>>>>>> >>>>>>>> Hello Andrew, >>>>>>>> >>>>>>>> In regards to your question, so I used yuv444p10le on the command >>>>>>>> line, however if you look in the screenshot, FFMPEG autocorrected it to >>>>>>>> yuv444p16le therefore the Cinelerra and FFMPEG formats are equivalent >>>>>>>> (yuv444p16le). My mistake for the typo. My raw video footage is in a >>>>>>>> 10bit-wide colorspace. >>>>>>>> >>>>>>>> Thanks very much for your response, Andrew. Based on your >>>>>>>> explanation, it looks like Cinelerra is working as expected, it's just that >>>>>>>> FFMPEG and Cinelerra use a different rendering algorithm if I understand >>>>>>>> correctly. Quick follow-up question for you - I'm currently using an NVIDIA >>>>>>>> RTX3070 Laptop GPU for my rendering. How likely is it that upgrading to a >>>>>>>> later series GPU such as an NVIDIA 5000 series GPU would accelerate the >>>>>>>> rendering speed? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> It really depends on drivers (proprietary in this case), and speed >>>>>>> of bus (pcie?) connecting gpu to rest of the system, and of course how >>>>>>> powerful nvenc block on upgraded GPU ... >>>>>>> >>>>>>> I guess best way to test is to get your software environment as live >>>>>>> image (say Fedora installed on usb flash/external hdd) and try this on >>>>>>> specific computer before upgrading your own .... >>>>>>> >>>>>>> >>>>>>>> Many thanks, >>>>>>>> Andrew Wesly >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Jan 18, 2026 at 6:55 PM Andrew Randrianasulu < >>>>>>>> randrianasulu(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Jan 19, 2026 at 1:55 AM Andrew Wesly via Cin < >>>>>>>>> cin(a)lists.cinelerra-gg.org> wrote: >>>>>>>>> >>>>>>>>>> Hello everyone, >>>>>>>>>> >>>>>>>>>> I really do appreciate the prompt support especially since it's >>>>>>>>>> over the weekend. So, yes this is part of using CUDA to render video on >>>>>>>>>> Fedora in WSL. I've tried compiling Cinelerra on Fedora within WSL on my >>>>>>>>>> NVIDIA GeForce RTX machine and for some reason the LADSPA dependency will >>>>>>>>>> not install. I'm not sure what the issue was. As part of a workaround I >>>>>>>>>> tried using Fedora natively on my machine in case WSL was the issue. >>>>>>>>>> However, there were issues with me compiling Cinelerra on Fedora due to >>>>>>>>>> issues installing dependencies with the configuration script; it, the >>>>>>>>>> script seemed to not want to work with my version of Fedora due to >>>>>>>>>> downloading dependencies. >>>>>>>>>> >>>>>>>>>> Upon digging further, I can see that FFMPEG on WSL is able to >>>>>>>>>> successfully render video on my machine at a 1.5 to 1.75 speed up. The >>>>>>>>>> input video is 4K YUV4:2:2 video with 10-bit color resolution in MP4 >>>>>>>>>> format. Here is the command run in wsl (Fedora): "ffmpeg -y -i >>>>>>>>>> CINELERRA_FFMPEG_DEBUG_DUMMY_FILE.MP4 -c:v hevc_nvenc -pix_fmt yuv444p10le >>>>>>>>>> -profile:v main10 -cq 20 -preset p5 -c:a copy FFMPEG_output_444_10bit.mp4" >>>>>>>>>> [image: image.png] >>>>>>>>>> As we can see the speed up is 1.74x and in Windows Task manager >>>>>>>>>> we see the GPU gets pegged as expected: >>>>>>>>>> [image: image.png] >>>>>>>>>> >>>>>>>>>> However in Cinelerra i select the h265_nvenc mp4 codec in the >>>>>>>>>> render profile: >>>>>>>>>> [image: image.png] >>>>>>>>>> The render rate seems to be <.5 the framerate and the GPU usage >>>>>>>>>> does not look right, it looks choppy: >>>>>>>>>> [image: image.png] >>>>>>>>>> >>>>>>>>>> So here, it seems that Cinelerra may be using the GPU, but not >>>>>>>>>> optimally. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Yeah, we transfer frames into CPU memory (even if they decoded on >>>>>>>>> GPU), then push them back to GPU via PCIe ... >>>>>>>>> >>>>>>>>> ffmpeg probably can do its transcoding without moving frames in >>>>>>>>> and out. >>>>>>>>> >>>>>>>>> Also, why 444p16 in cinelerra case, when ffmpeg does >>>>>>>>> just yuv444p10le ? I think it expanded to 16bit per channel inside >>>>>>>>> cinelerra anyway, but not sure if picking this pixel format will make no >>>>>>>>> difference, or trigger some additional conversion ? >>>>>>>>> >>>>>>>>> >>>>>>>>>> For these reasons, I am under the assumption that: >>>>>>>>>> >>>>>>>>>> - The issue is with the FFMPEG version that Cinelerra 5.1 uses >>>>>>>>>> - WSL is NOT the issue because a version of FFMPEG on the WSL >>>>>>>>>> environment optimally uses the GPU with the same nvenc codec. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thoughts? Comments? >>>>>>>>>> >>>>>>>>>> Many thanks, >>>>>>>>>> Andrew Wesly >>>>>>>>>> >>>>>>>>>> On Sun, Jan 18, 2026 at 11:24 AM Terje J. Hanssen < >>>>>>>>>> terjejhanssen(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> This earlier thread may be of some background interest, where >>>>>>>>>>> Andrew Randrianasulu guided me to build Cingg from git using the system >>>>>>>>>>> FFmpeg and libs on openSUSE Tumbleweed-Slowroll. >>>>>>>>>>> >>>>>>>>>>> https://www.mail-archive.com/[email protected]/msg07928.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 1/18/26 7:04 PM, Phyllis Smith via Cin wrote: >>>>>>>>>>> >>>>>>>>>>> Forwarding to the mailing list instead of just me. >>>>>>>>>>> >>>>>>>>>>> ---------- Forwarded message --------- >>>>>>>>>>> From: Phyllis Smith <phylsmith2017(a)gmail.com> >>>>>>>>>>> Date: Sat, Jan 17, 2026 at 7:47 PM >>>>>>>>>>> Subject: Re: Cinelerra FFMPEG Questions >>>>>>>>>>> To: Andrew Wesly <andrewwesly(a)gmail.com> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1. It is a little hard to say for sure depending on how the >>>>>>>>>>> package you installed did the build. But most likely the ffnpeg routines >>>>>>>>>>> will be in a subdirectory of something like >>>>>>>>>>> cinelerra-5.1/thirdparty/ffmpeg-8.0 >>>>>>>>>>> (edited - if I remember correctly, you used Andrey's Fedora >>>>>>>>>>> build which is the best option for you) >>>>>>>>>>> >>>>>>>>>>> 2. Again most likely the fedora package you are using was built >>>>>>>>>>> using its own ffnpeg routines and not your systems version. >>>>>>>>>>> (edited - 3. You can not point to a different ffmpeg version >>>>>>>>>>> unless you do you own build.) >>>>>>>>>>> >>>>>>>>>>> For what purpose are you looking for the ffnpeg routines? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sat, Jan 17, 2026, 13:38 Andrew Wesly <andrewwesly(a)gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello Phyllis and Cinelerra Team, >>>>>>>>>>>> >>>>>>>>>>>> I'm looking through the CinelerraGG_Manual.pdf document for >>>>>>>>>>>> information about configuring FFMPEG and I have a few basic questions for >>>>>>>>>>>> you. >>>>>>>>>>>> >>>>>>>>>>>> 1) The manual states that Cinelerra has an FFMPEG configuration >>>>>>>>>>>> directory. However, where si that directory located on default Linux >>>>>>>>>>>> installs, Fedora specifically? >>>>>>>>>>>> >>>>>>>>>>>> 2) I installed Cinelerra pre-built from a repository. What >>>>>>>>>>>> FFMPEG does it use? That is to say, if there are two or more versions of >>>>>>>>>>>> FFMPEG installed on a system, does Cinelerra come with its own FFMPEG or >>>>>>>>>>>> does it use an FFMPEG already on the system? >>>>>>>>>>>> >>>>>>>>>>>> 3) How may I point Cinelerra to a custom FFMPEG, i.e. one of a >>>>>>>>>>>> different version? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Many thanks, >>>>>>>>>>>> Andrew Wesly >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Cin mailing list -- cin(a)lists.cinelerra-gg.org >>>>>>>>>>> To unsubscribe send an email to cin-leave(a)lists.cinelerra-gg.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>> Cin mailing list -- cin(a)lists.cinelerra-gg.org >>>>>>>>>> To unsubscribe send an email to cin-leave(a)lists.cinelerra-gg.org >>>>>>>>>> >>>>>>>>>

1 0

Fwd: Cinelerra FFMPEG Questions
by Phyllis Smith 01 Feb '26

01 Feb '26

Forwarding to the mailing list instead of just me. ---------- Forwarded message --------- From: Phyllis Smith <phylsmith2017(a)gmail.com> Date: Sat, Jan 17, 2026 at 7:47 PM Subject: Re: Cinelerra FFMPEG Questions To: Andrew Wesly <andrewwesly(a)gmail.com> 1. It is a little hard to say for sure depending on how the package you installed did the build. But most likely the ffnpeg routines will be in a subdirectory of something like cinelerra-5.1/thirdparty/ffmpeg-8.0 (edited - if I remember correctly, you used Andrey's Fedora build which is the best option for you) 2. Again most likely the fedora package you are using was built using its own ffnpeg routines and not your systems version. (edited - 3. You can not point to a different ffmpeg version unless you do you own build.) For what purpose are you looking for the ffnpeg routines? On Sat, Jan 17, 2026, 13:38 Andrew Wesly <andrewwesly(a)gmail.com> wrote: > Hello Phyllis and Cinelerra Team, > > I'm looking through the CinelerraGG_Manual.pdf document for information > about configuring FFMPEG and I have a few basic questions for you. > > 1) The manual states that Cinelerra has an FFMPEG configuration directory. > However, where si that directory located on default Linux installs, Fedora > specifically? > > 2) I installed Cinelerra pre-built from a repository. What FFMPEG does it > use? That is to say, if there are two or more versions of FFMPEG installed > on a system, does Cinelerra come with its own FFMPEG or does it use an > FFMPEG already on the system? > > 3) How may I point Cinelerra to a custom FFMPEG, i.e. one of a different > version? > > > Many thanks, > Andrew Wesly >

4 10

Add vulkan detection to configure.ac
by Andrew Randrianasulu 29 Jan '26

29 Jan '26

Should make enabling it easier ? defaults to "no", should be enabled by passing --with-vaulkan to out configure. I plan to add similar blocks for libzimg and libplacebo.

2 4

Updated Quickstart part of Manual, but need other
by Phyllis Smith 19 Jan '26

19 Jan '26

I checked into cin-manual-latex GIT, a few more updates to the Installation.tex file and quite a few corrections in the Quickstart.tex file. Hoping that Andrea can look at the section and provide a fix for the space in A.1.4 between item 5 and 6 caused by location of a png file and also see if the other png are in good locations. In addition, the actual CinelerraGG_Quickstart.pdf on the website needs corrections - it is based on CinelerraGG_Quickstart.odt which I have on my computer and can email to Andrea (hopefully, if he "volunteers" to correct it). And I do not know why another helpful pdf file is not on the website, but I think I must have missed putting it there and it needs minor corrections too -- quickstart_batch_render.pdf / quickstart_batch_render.odt (Batch Render Wizard Quick Start Guide).

2 1

Fwd: Living the dreamm~ PowerMac G5 - New reply to watched thread
by Andrew Randrianasulu 19 Jan '26

19 Jan '26

Looks like we need this one more patch for installing non-thirdparty built cingg ... ---------- Forwarded message --------- From: 68kMLA <noreply(a)68kmla.org> Date: Tue, Jan 13, 2026 at 10:33 PM Subject: Living the dreamm~ PowerMac G5 - New reply to watched thread To: Andrew-R <randrianasulu(a)gmail.com> 68kMLA <https://68kmla.org/bb/> Link4Electronics <https://68kmla.org/bb/members/link4electronics.36733/> replied to a thread you are watching at 68kMLA <https://68kmla.org/bb/>. Living the dreamm~ PowerMac G5 <https://68kmla.org/bb/posts/580302/> Hi, Thanks a lot for the attached patch, it helped [image: Screenshot_2026-01-13_16-28-50.png] <https://68kmla.org/bb/attachments/screenshot_2026-01-13_16-28-50-png.94325/> Regards, Link. View this thread <https://68kmla.org/bb/threads/living-the-dreamm-powermac-g5.50893/unread?ne…> Watched threads <https://68kmla.org/bb/watched/threads> Please do not reply to this message. You must visit the forum to reply. This message was sent to you because you opted to watch the thread Living the dreamm~ PowerMac G5 <https://68kmla.org/bb/threads/living-the-dreamm-powermac-g5.50893/> at 68kMLA with email notification of new replies. You will not receive any further emails about this thread until you have read the new messages. If you no longer wish to receive these emails, you may disable emails from this thread <https://68kmla.org/bb/email-stop/28936/content?t=thread&id=50893&c=913b80f6…> or disable all emails <https://68kmla.org/bb/email-stop/28936/all?c=913b80f6d225a99651f684ac5df96e…> . Visit 68kMLA <https://68kmla.org/bb/>

2 2

Need some H.264 tweaking advice..
by info＠bandshed.net 15 Jan '26

15 Jan '26

Hi Cinners (lol) Recently at my request you added H.264 Video codec options for MOV and MKV containers and things are working well in general, I certainly don't think further changes need to be made to Cin but for my own use and workflow I'm thinking some further H.264 tweaks might be useful..? I don't generally don't assemble long projects in Cin itself, I prefer to make individual clips and put them together losslessly later with some ffmpeg concatenation File Actions in AV Linux, or using the 'append' feature in Avidemux or even using TMPGEnc SmartRender 6 (in Windows). As you know when you assemble clips this way they need to have the same codecs and settings in order to assemble without re-encoding and I would like to ensure that I'm able to use the H.264 Video from Cin Rendering all the way to assembling. If I look at the H.264 options in Cin the new H.264 options for MOV and MKV don't match the MP4 settings. For example MKV and MOV have 'profile=high' and H.264 in MP4 doesn't use the high profile and it has some keyint settings so when assembling I get some reported errors because the H.264 Video clips I created with MKV differ from clips I have made with MP4. I am not an H.264 guru or expert so is there any reason that I can't combine the profile=high and keyint settings and use the same H.264 settings across MP4, MKV and MOV? Lastly, I am now hosting my Videos for streaming on my own website due to numerous factors but mostly the proliferation of AI scraping by the large tech companies, is there an extra setting I should be using in the H.264 options to enhance streaming? Is this what the 'faststart' option is for? Advice appreciated! Thanks for the continued work on Cin, having also used both Davinci Resolve (on Windows) and Kdenlive over the past few years I still have the best productivity with Cin! Best, Glen --

3 6

Work on 3 different issues - i386 build, desktop icons for appimage, and fix audiofile patch
by Phyllis Smith 14 Jan '26

14 Jan '26

One bad problem - segmentation fault when rendering on older debian i386 32-bit. Was testing the new h264.mov render format when I got this error and it took a really long time to figure out when this happened. Embarrassed to find out it seems to be due to X264 upgrade in Sept. 2024! > commit 2ce09466ce02b9180d6d7ba30af02e99fca0bdc5 > Author: Good Guy <good1.2guy(a)gmail.com> > Date: Tue Sep 17 12:05:34 2024 -0600 > > <snip, snip> transfers/primaries, + update x264 from r3106 to r3191 > As far as I tested, all rendering of ffmpeg h264 failed but only 1 of the 10 loads of x264 files created on another computer failed (reindeerr.mkv). There are probably other things that might fail when editing an h264 type file but I do not know for sure. The 64-bit version of debian 11 does not fail. I guess it is safe to say, no one is using the 32-bit debian 9.1 version. Maybe Andrew can put his search moxie in play and find a patch. 2. Created a Desktop_icon folder in the download area of the website to make it easy for users of AppImage to make a desktop icon for CinGG. It is documented in the manual but no easy access to the 3 needed files. 3. Put the audiofile patch in the correct subdirectory in GIT source as Andrew pointed out and then just today deleted the one in the wrong place (so I hope it is automatic and not extra work for Andrey's builds).

2 7

pa-risc support for guicast/Makefile
by Andrew Randrianasulu 13 Jan '26

13 Jan '26

There still some reported unaligned access but in general cingg on emulated hppa shows her four windows with correct icons and fonts on remote Xephyr.

2 1