April 2025 - Cin - Cinelerra-GG Mailing Lists

ffmpeg.git test compile fail
by Andrew Randrianasulu 12 Apr '25

12 Apr '25

ffmpeg shallow git copy commit 890b8da1ce27fd365eaffefc7efcbadae9f01f2a our patches 2 and 8 fail, but this is not really my point yet .... ffmpeg.C:313:42: error: 'avcodec_close' was not declared in this scope; did you mean 'avio_close'? ffmpeg.C:476:33: error: 'avcodec_close' was not declared in this scope; did you mean 'avio_close'? ffmpeg.C:1307:37: error: 'AVFrame' {aka 'struct AVFrame'} has no member named 'interlaced_frame' ffmpeg.C:1309:37: error: 'AVFrame' {aka 'struct AVFrame'} has no member named 'interlaced_frame' ffmpeg.C:1309:66: error: 'AVFrame' {aka 'struct AVFrame'} has no member named 'top_field_first' ffmpeg.C:1311:37: error: 'AVFrame' {aka 'struct AVFrame'} has no member named 'interlaced_frame' ffmpeg.C:1311:67: error: 'AVFrame' {aka 'struct AVFrame'} has no member named 'top_field_first' ffmpeg.C:1340:36: error: 'AVFrame' {aka 'struct AVFrame'} has no member named 'key_frame' ffmpeg.C:1512:24: error: 'AVFrame' {aka 'struct AVFrame'} has no member named 'interlaced_frame' ffmpeg.C:1513:24: error: 'AVFrame' {aka 'struct AVFrame'} has no member named 'top_field_first' ffmpeg.C:3847:29: error: 'av_stream_get_side_data' was not declared in this scope; did you mean 'av_frame_get_side_data'? mplayer switched for now to branch 7.1 until it get updates. i see in doc/APIchanges 2023-05-04 - 0fc9c1f6828 - lavu 58.7.100 - frame.h Deprecate AVFrame.interlaced_frame, AVFrame.top_field_first, and AVFrame.key_frame. Add AV_FRAME_FLAG_INTERLACED, AV_FRAME_FLAG_TOP_FIELD_FIRST, and AV_FRAME_FLAG_KEY flags as replacement. but not sure how to use them yet.

4 12

Can you re-add old ffnvcodec archive?
by Andrew Randrianasulu 11 Apr '25

11 Apr '25

but under different name like may be ffnvcodec-old.tar.xz ? I tried my Slackware 15.0 x64 + nvidia 470.xx proprietary drivers and h264-nvenc only works with old headers (at around 100 fps for 720p) Downloading and replacing archive is not big deal, but can be surprizing for user less versed in intimate relation between driver version and ffmpeg/ffnvheaders. ref: (kdenlive and GF630) https://www.linux.org.ru/forum/desktop/17219674

2 4

static hdr metadata generation ....
by Andrew Randrianasulu 11 Apr '25

11 Apr '25

Found this code on github via some comment discussion https://github.com/HDRWCG/HDRStaticMetadata ah, such a mix of opencv/qtgui! but may be it exposes enough to make it into pure c++ pass? Still no idea how dynamic metadata work .. there are standarts but they a bit hard to read for me: https://pub.smpte.org/pub/st2094-10/st2094-10-2021.pdf https://pub.smpte.org/pub/st2094-40/st2094-40-2020.pdf Tonemapping using those already supported by ffmpeg's libplacebo filter, but this one need Vulkan driver/device! And how to *construct* those types of metadata is not clear for me .....

2 1

Update on Blend Algebra / Blend Program plugins
by Phyllis Smith 11 Apr '25

11 Apr '25

*SGE* "no user impact" patch applied in GIT source checkin for increased robustness which you can see if you want at: https://www.cinelerra-gg.org/bugtracker/view.php?id=670 For those who take advantage of *Andrey*'s package releases for automatic updates, they are building and are at: https://github.com/einhander/cin-gg-packages/releases Also, checked into GIT Manual a few minor changes to the wording, punctuation, and removing commentary that I found interesting but would not help the user in usage (for example, "there is proof that any program has infinite number of undetected bugs"!!). Modified the Developer's section to put these plugins' workflow here so that developers can follow this methodology to in the future to add additional effects, because as was stated "one can more quickly test different combinations without spending time to restart Cinelerra, recompile it, reload project, and reattach plugins, etc.". Section is "*Unique Blend plugins workflow*". After I do some more checking, I will at least update the PDF document on the website. *Andrea *had provided some latex fixes for other plugin figures that were out of whack that I checked in too. And if he has time, could he check that I got them right? I spotted another figure that needed fixing but I can not remember where it was. *IgorBeg* - curiosity question -- does the white line on the bottom of the Blend Algebra icon represent the fact that it combines its tracks? or does it represent the fact that there are multiple tracks? or something else?

5 14

libsvtav1 2.3.0 patch for cmake 4.0
by Andrew Randrianasulu 09 Apr '25

09 Apr '25

Again, tested only on Arch, but should be safer because we only build libsvtav1 on Linux distros where cmake > 3.16 ? sorry for 2.3.9 typo, must be 2.3.0 (harmaless)

3 5

Alternative patch for x265 and cmake 4.0
by Andrew Randrianasulu 09 Apr '25

09 Apr '25

Use it instead of my previous patch? Tested on updated today Arch linux, it will be nice if it will not break ubuntu 16.04 (i tried to set cmake version to 3.5.1)

2 2

Paste without the remainder moving
by Stefan de Konink 08 Apr '25

08 Apr '25

Is there an option to copy paste everything (track, keyframes, etc.) so it would overwrite, instead of move the remainder of the track to the right? -- Stefan

3 3

Mailing list
by Andrea paz 08 Apr '25

08 Apr '25

I noticed that the mailing-list archive is not showing some of the mails of a new subscriber (Pekka Paalanen). It only reports one. https://lists.cinelerra-gg.org/pipermail/cin/2025-April/thread.html Is this the usual problem with new subscribers or is it my system not updating the archive?

2 1

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

08 Apr '25

вт, 8 апр. 2025 г., 10:59 Pekka Paalanen <pekka.paalanen(a)haloniitty.fi>: > On Mon, 7 Apr 2025 18:31:17 +0300 > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > пн, 7 апр. 2025 г., 17:18 Pekka Paalanen <pekka.paalanen(a)haloniitty.fi>: > > > > > On Mon, 7 Apr 2025 14:44:25 +0300 > > > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > > > > > пн, 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>: > > > > > > > > > > > > ... > > > > > > > > > > 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? > > > > > > Hi, > > > > > > sure, but would it not be more useful to invest that effort in a proper > > > Wayland integration? > > > > > > > Cinelerra-gg like other cinelerra forks uses custom gui library: > > > > > https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=tree;f=cinelerr… > > > > I have no idea how much effort will be needed to add Wayland to it. > > > > We lost our main/only developer nearly 5 years ago, so all I can do is > > fixing minor bugs and trying to catch up with ffmpeg API changes. > > > > So, we are on look out for c++ developer who is not afraid of "legacy" > and > > will not try to 'refactor' it on first sight (efforts to refactor > cinelerra > > proved to be LONG at best and unworkable at worst). > > > > I do not have HDR capable GPU/Monitor, and things most likely will remain > > so in foreseeable future (I am officially invalid, so my income sources > are > > limited, and VERY limited by USA standarts. ) > > > > Even if cinelerra(-gg) might never rise up to prominent position in > > Linux/*bsd world again - I still consider us useful as example of working > > NLE with internal 32fp pipeline, hw decoding, some OpenGL integration. > > > > So, if only more developers were not afraid to experiment with 'legacy > > '..... After all, retrocomputing is a thing now! > > > > Sorry to hear, I wish you and the project all the best. > Thanks .... > > > > X11 is fundamentally limited to max 32-bit pixels so its stuck at 30 > > > bpc max with only 2 bits of alpha. That's probably the only thing that > > > cannot be worked around. > > > > > > > > > I am not sure we need alpha over video region on final output .... right > > now x11/x11 opengl outputs definitely live without. If linux DRM can > > transmit 12bit hdmi/DP - may be this functionality can be implemented as > > separate output module? I looked into how psychtoolbox implement HDR > > rendering .. very funny, a bit like using Vulkan to put output in HDR > mode > > and doing framebuffer blit manually in shaders .... > > Linux DRM KMS is not inherently limiting bit depth, it all depends on > the hardware and the driver. E.g. a driver can support a framebuffer > with half-float RGB (16 bpc) or 16 bpc integer or 32-bit float, > whatever anyone desires. Adding new formats to a list is easy, it's all > about what the hardware and HDMI, DisplayPort etc. can do. > > I'm not aware of how psychtoolbox works, but I guess it needs complete > control over an output for scientific experiments. One way to do that > is to use DRM leasing. > yes, this is how I come to discover that this probably strictly scientific project grow some HDR player ;) http://psychtoolbox.org/docs/PsychHDR also link at the bottom of page to source file. I am not sure radv supported all required extensions last time I looked at it. Andrea does have AMD card but "only" wide-gamut monitor. May be some kind of measurement overlay exist in .. mangohud or something? To see pixel and metadata values even w/o HDR monitor .... > It appears that Xwayland has support for DRM leasing, so X11 apps can > lease a KMS CRTC and a KMS connector from a willing Wayland compositor. > The advantage is that the app gets complete, direct access to the > display device and monitor, unobstructed by the window system. The > disadvantage is that the same monitor disappears from the rest of the > desktop environment, and you have to use the KMS UAPI to drive it - IOW > without a window system to lean on. I'm not sure what EGL nor Vulkan > offers to make that easier. > > The monitor disappearing from the rest of the desktop environment is > absolute, including input delivery. The user cannot move the mouse > pointer to the leased monitor. This means you need either some > input means outside of the desktop environment, or you need a regular > window on another monitor for controls. > > The primary use case for DRM leasing is head-mounted displays for > virtual reality. DRM leasing might be a good way to drive a separate > mastering display. > > > Thanks, > pq > > > > > A bit like > > > > > > > > > > > > https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/X… > > > > > > That's an interesting one, I wasn't aware of this. I have to take some > > > statements back. > > > > > > So this is communicating ICC profiles and associated window regions to > > > an X11 compositing manager. If a profile covers the whole window, this > > > should be relatively easy to hook up in a Wayland compositor's XWM > > > (embedded X11 window manager). > > > > > > Being limited to ICC profiles is a hindrance for HDR, although the CICP > > > extension for ICC does exist. Unfortunately CICP does not carry > > > everything we have in the Wayland color-management protocol extension. > > > Most notably, it misses the reference white level which would be > > > necessary[1]. > > > > > > > > > Somewhere there also was cinepaint fork (unrelated to cinelerra) that > also > > can be used for testing this functionality. > > > > > > I suspect working with std body behind ICC will be ... challenging, if > > anyone decided to add missing info into standart. > > > > > > > > > > Thanks, > > > pq > > > > > > [1]: > > > > https://www.freelists.org/post/argyllcms/Standard-spec-for-ICC-file-that-ca… > > > > >

1 0

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

08 Apr '25

пн, 7 апр. 2025 г., 17:18 Pekka Paalanen <pekka.paalanen(a)haloniitty.fi>: > On Mon, 7 Apr 2025 14:44:25 +0300 > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > пн, 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>: > > > > > > ... > > > > > > 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? > > Hi, > > sure, but would it not be more useful to invest that effort in a proper > Wayland integration? > Cinelerra-gg like other cinelerra forks uses custom gui library: https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=tree;f=cinelerr… I have no idea how much effort will be needed to add Wayland to it. We lost our main/only developer nearly 5 years ago, so all I can do is fixing minor bugs and trying to catch up with ffmpeg API changes. So, we are on look out for c++ developer who is not afraid of "legacy" and will not try to 'refactor' it on first sight (efforts to refactor cinelerra proved to be LONG at best and unworkable at worst). I do not have HDR capable GPU/Monitor, and things most likely will remain so in foreseeable future (I am officially invalid, so my income sources are limited, and VERY limited by USA standarts. ) Even if cinelerra(-gg) might never rise up to prominent position in Linux/*bsd world again - I still consider us useful as example of working NLE with internal 32fp pipeline, hw decoding, some OpenGL integration. So, if only more developers were not afraid to experiment with 'legacy '..... After all, retrocomputing is a thing now! > X11 is fundamentally limited to max 32-bit pixels so its stuck at 30 > bpc max with only 2 bits of alpha. That's probably the only thing that > cannot be worked around. > I am not sure we need alpha over video region on final output .... right now x11/x11 opengl outputs definitely live without. If linux DRM can transmit 12bit hdmi/DP - may be this functionality can be implemented as separate output module? I looked into how psychtoolbox implement HDR rendering .. very funny, a bit like using Vulkan to put output in HDR mode and doing framebuffer blit manually in shaders .... > > A bit like > > > > > https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/X… > > That's an interesting one, I wasn't aware of this. I have to take some > statements back. > > So this is communicating ICC profiles and associated window regions to > an X11 compositing manager. If a profile covers the whole window, this > should be relatively easy to hook up in a Wayland compositor's XWM > (embedded X11 window manager). > > Being limited to ICC profiles is a hindrance for HDR, although the CICP > extension for ICC does exist. Unfortunately CICP does not carry > everything we have in the Wayland color-management protocol extension. > Most notably, it misses the reference white level which would be > necessary[1]. > Somewhere there also was cinepaint fork (unrelated to cinelerra) that also can be used for testing this functionality. I suspect working with std body behind ICC will be ... challenging, if anyone decided to add missing info into standart. > > Thanks, > pq > > [1]: > https://www.freelists.org/post/argyllcms/Standard-spec-for-ICC-file-that-ca… >

2 1