April 2025 - Cin - Cinelerra-GG Mailing Lists

Fwd: Mentioned in [Cinelerra-GG 0000672]: Crash when using the speed curve
by Andrew Randrianasulu 08 Apr '25

08 Apr '25

so, I looked at this bug and it seems that only taking back change to auto.C "fixes" it But may be I just tested too little (in virtual Arch) full backtrace is big, but I think it crashes here: #6 MWindow::normalize_speed (this=this@entry=0x7ffe5099ab80, old_edl=0x62bf3d52dd40, new_edl=0x7a75402bbd50, edit_speed=edit_speed@entry=0) at mwindowedit.C:2705 old_keyframes = <optimized out> new_keyframes = 0x7a7538311830 old_auto = 0x0 new_plugin = <optimized out> plugin_start = <optimized out> orig_start = <optimized out> plugin_end = <optimized out> orig_end = <optimized out> old_plugin_set = <optimized out> new_plugin_set = 0x7a75382080a0 old_plugin = <optimized out> i = 0 old_size = <optimized out> new_size = <optimized out> n = <optimized out> old_speeds = <optimized out> old_speed = <optimized out> old_edit = <optimized out> new_speeds = <optimized out> new_speed = <optimized out> edit_plugins = 1 edit_autos = 1 edit_labels = 1 result = 1 first_track = 0 old_track = <optimized out> new_track = <optimized out> #7 0x000062befc37112a in MWindow::speed_after (this=0x7ffe5099ab80, done=done@entry=0, edit_speed=edit_speed@entry=0) at mwindowedit.C:2753 so *may be* old_auto being 0x0 causes crash ? Not sure where to put guard in this function yet ... ---------- Forwarded message --------- From: Cinelerra GG Bug Tracker <noreply(a)cinelerra-gg.org> Date: Tue, Apr 8, 2025 at 6:03 AM Subject: Mentioned in [Cinelerra-GG 0000672]: Crash when using the speed curve To: <randrianasulu(a)gmail.com> On 2025-04-08 03:03, PhyllisSmith mentioned you on: https://www.cinelerra-gg.org/bugtracker/view.php?id=672 @Lukas I think I have isolated the crash and reverted 3 files to a previously working version. BUT it does not make any sense why that would solve the problem AND I am not even sure that it solves all cases. However, I will create an older version AppImage with the change in for you to test when I boot that O/S desktop tomorrow. @Andrew-R Here is an exact set of minimum steps to create the problem. Start with a new bcast, i..e. CIN_CONFIG=/tmp/bcast5 bin/cin Just dismiss the note of the day window (x it gone) load media using replace current project turn on generate keyframes while tweaking drag chromakeyhsv to video bring up chromkeyhsv menu play a little and move the slider in the chromkeyhsv menu to get keyframes stop play, then move cursor and play a little to get another set of keyframes use View to turn on speed curve move cursor to between the 2 sets of keyframes in front of cursor, try to move speed curve it gets stuck and crashes THIS COMMIT CRASHES: commit 25e944875e181186eeb59a124c1822e5b55d2248 Author: Good Guy <good1.2guy(a)gmail.com> Date: Fri Sep 4 09:17:01 2020 -0600 fix auto id 'that' blunder, tweak keyfrm popup speed undo THIS COMMIT SEEMS TO WORK: commit 22c6251d37911a11e322bf7518e6a992ea0bb6c7 Author: Good Guy <good1.2guy(a)gmail.com> Date: Wed Sep 2 19:16:24 2020 -0600 add ids to auto/labels, fix awdw gui deadlock, fix fourier bfr bug, fix cache critical section, rework normalize_speed, fix delete_track gang bug So I reverted cinelerra keyframepopup.C, keyframepopup.h, and auto.C to the Sept 2, 2020 version since no further changes were made to those other than a comment.

1 0

Some tests on blending
by Andrea paz 07 Apr '25

07 Apr '25

In reference to the email: https://www.mail-archive.com/[email protected]/msg04905.html and to the whole of the following discussion, which includes a workaround by IgorBeg. I have tried further testing, now that we have Blend Algebra that allows us to customize the various Blends. I do not know whether it is appropriate to reopen an issue that is now closed and has also led to tensions (you can see the article: https://linuxvideoediting.blogspot.com/2022/09/transparent-text-effect-with…. I warn that it contains polemics). So I will only report the result of some of my tests; they are probably not even worth reading.

4 33

Re: [Cin] "Competitors" or do we want to stay alive?
by Andrew Randrianasulu 07 Apr '25

07 Apr '25

пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <pekka.paalanen(a)haloniitty.fi>: > On Fri, 4 Apr 2025 22:14:10 +0300 > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > пт, 4 апр. 2025 г., 21:35 Andrea paz <gamberucci.andrea(a)gmail.com>: > > > > > @Georgy > > > X11 supports CMS more or less well. Even I was able to profile the > > > monitor and install it with colord. It's not full support like Windows > > > or Apple has, but it's doable. > > Hi, > > X11 supports color management by having nothing to do with it. It's a > strictly hands-off design. Each application can choose a different CMS > simultaneously. An application that does not explicitly use a CMS also > does not have any color management with X11. > > The X server can step out of the way and let applications post pixels > as-is to each monitor. This is good for application-side color > management, the pixel values do not get arbitrarily munged. However, > X11 also offers a number of interfaces to force the X server to munge > the pixel values. It allows loading a VCGT, but it also allows any > app to change any of the pixel munging settings, so the display > calibration is fragile. > > On X11 it is the responsibility of each application to make each part > of their windows color-managed for the monitor they happen to overlap. > X11 does nothing to help with that. > > > > For Wayland the big problem, why they didn't want to make a CMS, is > > > its being decentralized, a protocol to which various software could > > > interact by bringing their own version of CMS. The trouble is that a > > > CMS must be centralized by definition, if everyone fakes their own > > > implementation goodbye std. > > In the Wayland model, the color management is centralized in the > Wayland compositor you use. Any application that does not choose to > manage its own colors will get color-managed by the compositor > automatically and unavoidably. > > > > On Wayland, good programmers but bad color scientists, they didn't > > > even know how to start. Then Valve created The Gamescope to be able to > > > play games in HDR, and Wayland started from that to implement its CMS. > > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 > was created 5 years ago. > > https://github.com/ValveSoftware/gamescope/pull/1168 was filed 1 year > ago, after the above had already settled on the fundamental information > to be carried. > > EGL and Vulkan HDR extensions are the real API predecessors here for > both, and ITU-R recommendations and SMPTE specifications have had their > influence as well. > > > > The result is not a real CMS but just something for video games and > > > movies. True, lately they seem to have figured out the problem and one > > > can hope that they will be able to solve it. > > The decision to concentrate first to the HDR aspect was a deliberate > decision due to popular demand. The professional color-managed > workflows were always in my mind from the start. In fact, people were > in a hurry to implement HDR support without any thought to color > management, but I'm really happy to have been able to sell the idea > that color management is a prerequisite to HDR support. Otherwise we > would now have ad hoc HDR support that would quite likely be > fundamentally incompatible with the goals of color management. > > > > For the time being, the main developer said:... > > > The color-management Wayland extension is enough for entertainment > > > purposes like games and movies. However, it is not enough for > > > professional color management needs including photo editing and print > > > preview. The major missing piece is the ability to measure the display > > > response. Every monitor is unique, and measuring is the only way to > > > achieve reliably repeatable and accurate display behavior. > > > ... > > > > > > Introduction to CMS in Wayland by the lead developer: > > > > > > > https://www.collabora.com/news-and-blog/news-and-events/12-years-of-incubat… > > You quoted that part, but conveniently ignored everything else that > goes against your statements. > > My plan for display profiling and calibration was documented 2 years > ago: > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27 > > and this was linked in the text you quoted, and below. > > Note, that it is possible to calibrate and profile a monitor without > anything from issue 27, it's just tedious and error-prone to achieve. > Issue 27 makes that process easier to get right, more robust, and more > user friendly. The one thing that issue 27 does mention is the > programming of a VCGT, but I am unsure whether that has any benefit for > any HDR monitor driven in HDR mode. > > > > > > > A summary by Paalanem of everything that happened in the 12 years of > > > development: > > > https://gitlab.freedesktop.org/pq/color-and-hdr > > > > > > Old discussion on monitor profiling (in the thread, user Graeme Gill > > > is ArgylCMS's developer): > > > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27 > > > > > > Wayland CMS implementation in Gnome: > > > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4291 > > > > > > > > > A theoretical question: can CinGG be adapted to work in Wayland or is > > > it impossible? Has XWayland limitation? > > X11 and Wayland designs for color management are fundamentally > incompatible. > > With X11, applications never tell the display server what kind of > pixels they are producing or which, if any, color profile they used for > the display. With Wayland, applications must describe their pixels to > the display server. Since X11 applications tell nothing to the X server, > Xwayland has no color information to forward to the Wayland compositor. > > There can be case-specific manual solutions, though, that rely on > correctly configuring both the X11 apps and the Wayland compositor. X11 > apps need to be configured to render for a specific display profile, > and the Wayland compositor needs to assume the X11 windows are rendered > for the same specific display profile. How that is actually done is up > for each X11 app and each Wayland compositor. > Is there possibility for X extension for Xwayland allowing relatively simple way to tell Xwayland what to do with each window/region? A bit like https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/X… I looked in libplacebo (for avoiding to deal directly with Vulkan et al) and ... it was not simple for me. > I happened to see there is a Cinelerra.GG ticket open for ICC support. > A native Wayland application would not necessarily need to work with > ICC profiles, the color management protocol has an alternative > (and HDR-capable!) interface for "parametric image descriptions" which > are much closer to video metadata interfaces than ICC. EGL and Vulkan > color related extensions will map to the Wayland color-management > protocol as the support lands and matures in Mesa, so it's possible to > take advantage of Wayland color features without touching the protocol > yourself. > > > > > IF i understand correctly basically screencapture, user input, > > monitor/compositor all tied to X11. There are (or were) different output > > modules (to DV tape, to mjpeg card), so I guess SOME abstraction between > > core and video i/o exist in cinelerras. Right now cingg reported to work > > over Xwayland but I do not know how any (external) color management etc > > work in this case. Under wayland you need EGL not GLX and cingg uses > rather > > obscure Xserver pbuffer mechanism. Not sure how easy/impossible is to > > rewrite it for EGL. > > > > I do not even know where such questions should be asked now! On > xorg-devel? > > in gitlab issues? > > > > cc xorg-devel because I have them in my auto-address book in gmail. > > Wayland-related things can be discussed on wayland-devel@, cc'd, but it > requires subscription to avoid the manual moderation queue when sending > email to it. > > I'm happy to discuss color management topics in > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues as well. I'm > also subscribed to argyllcms and lcms-user lists for topics around ICC. > > > Thanks, > pq >

2 1

"Competitors" or do we want to stay alive?
by Andrew Randrianasulu 07 Apr '25

07 Apr '25

Sorry for being frustrated lately. Realities of all this "modern development" vs me tend to be not in favor of our project. I looked up two "other" projects in video editing. MLT is well-known and going on for nearly two decades. In this year release notes we see: https://github.com/mltframework/mlt/releases ===== https://github.com/mltframework/mlt/releases/tag/v7.30.0 Added support for mlt_image_yuv420p10, mlt_image_yuv444p10, and mlt_image_yuv422p16 in avfilter, swscale, and rescale filters. This facilitates using these pixel formats end-to-end when using only FFmpeg producers, certain avfilters, and avformat consumer. This means it is possible to do 10-bit end-to-end on the CPU when being careful to select compatible components and options to avoid conversions. One can pass-through HDR; however, you must set the color_trc and pix_fmt properties on the avformat consumer (see ffmpeg -h full for these values). The avformat consumer automatically converts MLT colorspace (integer value) to FFmpeg's colorspace and color_primaries (unless explicit) options. ==== I take this as "floating point pipeline still not here". Olive branch is even more depressing: https://github.com/olive-editor/olive/issues Last non-CI commit was in ... september 2023? May be developing moved somewhere, but this mean all exiting new bugs and state of being incomplete for few more years, given that even with most of hard work done by OpenGL, OCIO, ffmpeg etc remaining NLE core is not that simple, as it turned out to be. Natron does not do audio, as far as I know, and also hanging on a thread (single developer). Blender is a Big Shot now, with predictably big requirements both in software (try to build it on Slackware) and in hardware. Driven by higher end! And whole "Oh lol X is deprecated, everyone rewrite themselves to Wayland" push. I bet there might be way to resistance say Intel's or Nvidia "HDR on X" proposals in Xwayland but who will do all this work for single application? It took Valve's money effectively to get anything at all done in this area. https://www.phoronix.com/news/X11-DeepColor-Visual-RFC from 2017 .... https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.h… It took whole 8 years to get into "usable in mpv" state, and producing video usually have higher demands than playing back. I am fairly sure someone will write something in Rust (so it will break in 6 months time because Rust is for Big D Developers who have no problems with such churn) or c++ 25 because c+11 is too archaic and all new courses are about $latest (double meaning of $ here). Again, I do not think this is only individual developers fault, just more complex issue with constant stream of *new* hardware we supposed to fix in field by writing software, somehow (HDR displays are all or nothing, so HD(R), SD and GUI all must be mixed on host side). And general "culture" of individualism (because Silicon Valley, bebe!) and effectively social darwinism (where are XDTV and libquicktime? killed by constant API churn ....). I see no escape from this, at larger scale. And this makes me even more frustrated. cc ffmpeg-user/libav user because otherwise no one from "outside" will ever read this.

4 8

"Unbounded" floating point image manipulation
by Andrew Randrianasulu 04 Apr '25

04 Apr '25

I think this forum post (with still working image inserts) illustrates what Andrea trying to do inside CinGG: https://discuss.pixls.us/t/unbounded-floating-point-pipelines/6483/199 On input image a bit blown out, but after few layers of correction (_as long as you editing software does not clip to 1.0_) you get more details, in final image. Very unavoidable fact that _everything_ (camera, monitor, projector, printer, eyes) all non-linear in their transmission/sensing/emitting lightwaves of different frequencies makes all this quite complex topic!

3 5

possible patch for x265 on cmake 4.0?
by Andrew Randrianasulu 04 Apr '25

04 Apr '25

https://bitbucket.org/multicoreware/x265_git/commits/b354c009a60bcd6d7fc040… not sure libsvtav1 yet ....

4 20

Crash on compile
by Andrea paz 02 Apr '25

02 Apr '25

I tried to do a compile with Andrew's patch but it fails. The patch is not to blame because I tried to do a new compile without the patch and it too fails. The last compilation I did successfully was from the March release. Then I had not attempted any others so I don't know which commit leads to the error. The appimage works, but it is from the same period as my working compile. I attach the cin.log

2 5