January 2022 - Cin - Cinelerra-GG Mailing Lists

Re: [Cin] Crash on playback
by Phyllis Smith 21 Jan '22

21 Jan '22

Mark, > If you get vdpau working, could you build a multibit version appimage for > older systems? That would cover all my use cases. > Yes, that would be easy IF I get vdpau working. > > I shared a sample file. You should be able to download the original file > from this link also: > As expected, no crash while playing on Fedora 29 (with same glibc and kernel version level). Maybe I will try installing RHEL8 out of curiosity). Trying to fix something when I can not reproduce it, is impossible. Also, when booting my old Fedora 29, I noticed there is another partition labeled Fedora 29 - Cuda development so that should prove helpful. > >

1 0

Re: [Cin] Crash on playback
by Phyllis Smith 19 Jan '22

19 Jan '22

Mark, Now that you have found a workaround, I do not know if you want to continue to work on resolving this. If so, don't bother reading the rest of this. Or how much more time to test you want to do. Depending on your goal: ?? do you want to build yourself (if so, I have Fedora 29 on a partition and am compiling my latest CinGG tar there right now to see if I can reproduce the error you are getting. It has the same kernel of 4.18 as RHEL8 and glibc of 2.28 as you mentioned - Fedora 28 is earlier than that). I could also try to download RHEL8 as a developer for free but I don't know how far I would get with that and reproducing the error. ?? OR would you prefer to just use AppImage if vdpau worked? (if so, I can work on trying to figure out a solution because others have the same issue). ?? have you tried this easy test of using the default configuration file to make sure indexes are rebuilt and there is nothing strange in your cinelerra_rc file? ,.e. CIN_CONFIG-/tmp/bcast1 ./bin/cin About: > compiled it. It worked for a while but now it crashes with the following > when I hit the play button. There were some system updates installed in the > interim. > ?? is it possible that the system updates included a technology called pre-linking, which supposedly "speed up a start of a binary which uses dynamically loaded libraries by linking these libraries in advance ("prelinking" the executable file) using the 'relocating' technique. This basically means that each time the binary is run, the shared libraries are loaded to a randomly chosen memory addresses, which may sometimes interfere with the addresses at which the program shared memory segments are to be attached." The reason I ask is because when I look up the error message you first reported of "could not attach shared memory" it talks about this error and a solution as follows: Per the internet, you can disable prelink by editing /etc/sysconfig/prelink (set PRELINKING=no), then run /etc/cron.daily/prelink so the prelinking of the libraries in the system will be disabled. Fedora and Red Hat Enterprise Linux (RHEL) supposedly enable pre-linking by default which means I have been using it that way for years without a known problem. But I do not see a file called /etc/sysconfig/prelink on my Fedora 32. RHEL8 uses glibc 2.28, kind of annoying they stayed there as many newer > things want a later version. They have a habit of backporting things > though, including kernel changes, such that the conditional compile based > on versions sometimes fails and a special case for a Redhat kernel needs to > be added. Who knows if they backported something in glibc? > > >> If I set the compiled version to not use any hardware accel, it still >>> crashes. I don't think the vdpau issue and the crash are related. The crash >>> is my big concern obviously, as any work not saved is lost. >>> >> > Why would it not crash if there is another video on the timeline below > what I am playing? At least that is a workaround. It can be another copy of > the same track. > Good question! > > Thanks for taking up the mantle of the open source Cinelerra gg. I was > very peripherally involved with Cinelerra CV in 2011. I provided a patch > for SOWT audio and communicated with Einar at that time. I see that is now > handled by ffmpeg. > We just want to make sure Cinelerra lives on and stays relevant after all of the hard work you and many, many others have done !

1 0

Colors [was: Crash on playback]
by Andrea paz 18 Jan '22

18 Jan '22

@Andrew > @Andrea, for some reason I can't download attaches from forum (because I have no login there?), can you add CMS.txt as attachment to email (again)? I'm opening a new email because color has nothing to do with the Vdpau/Vaapi issues. It was just an attempt to put together all the information on how CinGG treats color. Lately I found emails from Hermann Vosseler that are very indicative. However, the fact remains that each plugins of CinGG treats the color in its own way, so we should find a way to understand how all the native plugins act, one by one (if I'm not mistaken, the plugins of ffmpeg clip everything to 8-bit and sRGB). Only with this information can we reconstruct a chain of steps that accounts for color transformations and, perhaps, keep them under control. Sorry, I've been pushing too much color lately, it's best to let it go. Hermann already knew in 2012 that it was not possible to treat it in CinCV and that's also why he went for Lumiera.

3 3

nvdec - > va-api wrapper
by Andrew Randrianasulu 18 Jan '22

18 Jan '22

does not support av1 yet, mostly aimed at firefox use (but kodi {mediacenter} also might work) v 0.0.2 https://github.com/elFarto/nvidia-vaapi-driver found via Phoronix

1 0

Crash on playback
by Mark Goldberg 17 Jan '22

17 Jan '22

I have an RHEL8 system and wanted support for vdpau playback. The appimage does not seem to work, dropping back to software playback. I downloaded the Dec 31 2021 tarball and compiled it. It worked for a while but now it crashes with the following when I hit the play button. There were some system updates installed in the interim. VFrame::allocate_data 518 could not attach shared memory, 930x523 (model 6) shmid=0x00000000 shmall = 18446744073692774399 shmmax = 18446744073692774399 shmmni = 4096 shmused = 50173032 (6 items) shmother = 4870728 (8 items) Mutex::lock: Success Mutex::unlock: Invalid argument Regards, Mark

5 10

CFLAGS (was: Re: Crash on playback)
by Andrew Randrianasulu 17 Jan '22

17 Jan '22

cflags I tried some time ago (on 32 bit build but with avx-enabled amd cpu fx-4300, with gcc 5.5.0) https://github.com/Randrianasulu/CinelerraGG-slackbuild/blob/master/cineler… "-O3 -ffast-math -mavx -march=native -mtune=native -fopenmp" not much use for openmp, but if you want some experiments you can try to put some #pragma omp simd" around hot source code blocks and see if it helps... On Monday, January 17, 2022, Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > On Monday, January 17, 2022, Mark Goldberg via Cin < > cin(a)lists.cinelerra-gg.org> wrote: > >> >> On Mon, Jan 17, 2022, 3:32 AM mat <mnieuw(a)zap.a2000.nl> wrote: >> >>> >>> >>> @Mark, can you confirm vdpau works on your system, outside of CinGG? >>> Does vdpauinfo say it is OK? >>> Does "HW device" vdpau work in the compiled version without errors, >>> apart from the crash? >>> >> >> On RHEL8 the appimage for older distros is required as glibc is older. It >> does not work with vdpau, falling back to software. In the locally compiled >> version it does use vdpau, but I have 4k60 f-log videos, and adding the >> lut3d plugin slows things down such that it cannot play in real time. >> > > > you can try to hack makefiles of individual plugins (while lut3d is > ffmpeg's one, so not sure how to influence irs compile flags individually) > with > -march=native, -mavx (if you have avx instructions in your cpu), and > other suitable flags... CinGG for now mostly cpu/memory intensive, not > using OpenCL/cuda (unlike big commercial editors?) so setting correct cpu > flags may give relatively big boost. > > > >> @Andrew, I have compiled multiple times and changed versions of the >> Nvidia driver, same crash. >> > > from forum post I see case when gpu decoder utilization (as seen via > nvidia's utility) still not 0%, so it works, but probably pulling and > pushing frames between vram and ram via pci-e bus takes cpu, too (even if > dma should do it for free?). I remember long time ago open-source radeon > driver developers run into some underutilization of bus so they applied big > expensive logic analyzer (at pcie speeds!) for finding some bottlenecks.... > so I am afraid without much better developers poking graphics stack while > Cingg is running not much can be done.. :( > > @Andrea, for some reason I can't download attaches from forum (because I > have no login there?), can you add CMS.txt as attachment to email (again)? > > I recall older version of Final Cut (before X) has ColorSync plugin > (probably utilizing cpu at early 2000s), so may be making lcms2 plugin will > provide some workaround for lack of core color management? (like, you > switch slow colorcorrection plugin/effect for color work, turn it off for > edits... those transforms using monitor's profile tend to be math heavy if > executed on cpu only, even with simd... ) > >> >> @Andrea, I have seen the forum posting. There are issues with plugins >> slowing things down, but I will start a second thread for that. >> >> Latest compile is the multibit version. It's more complicated. If there >> is another video track on the timeline below what is playing, it does not >> crash and plays successfully. >> > > sorry, I can't test this due to lack of access to my main desktop... and > laptops here only have vaapi (may be I can recompile x86_32 version of > cingg... those are not *my* laptops, but I have live usb stick with > slackware /copy of my home system from ~2020) > >> >> Regards, >> >> Mark >> >>>

1 0

Passing along GOOD feedback on manual
by Phyllis Smith 17 Jan '22

17 Jan '22

Just wanted to make sure Andrey and Georgy see this quote from a forum entry about the CinGG Manual: *It has the best documentation by miles compared to the other FOSS NLEs. > Amazing job on that, by the way; it's unfortunate that most projects don't > have documentation this thorough and in-depth. I learned a lot about video > in general from reading some of it, even.* > (Credit for the Manual goes to Terje - who started it all; Andrea for keeping it updated and adding video information; MatN and Andrew for reviewing for corrections; many others who contributed like me; and especially both Andrey who created the LaTeX version used in the pdf version and Georgy who did the hardest programming work to get the html version going and incorporating it with Alt-h into the source base.)

3 2

FFmpeg 5.0
by Andrea paz 16 Jan '22

16 Jan '22

Ffmpeg 5 is out: https://github.com/FFmpeg/FFmpeg/blob/ce4d459db186a7d8ac842685cd6256c9ac1b7…

4 3

Re: [Cin] libaom 3.2.0 patch1 fixed for arm/linux?
by Andrew Randrianasulu 14 Jan '22

14 Jan '22

On Tuesday, January 11, 2022, <mnieuw(a)zap.a2000.nl> wrote: > On Mon, 10 Jan 2022 22:43:52 +0300 > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > <snip> > > > I am happy to report that the aarch64 version of CinGG builds > > > properly here with libaom enabled. The change in the thirdparty > > > Makefile compared to the git is now only the added creation of a > > > dummy configure script through giflib.cfg_vars . > > > > > > this is still with my fix for libaom patch, right? > > Yep, I can make a diff if you want. > > > Also,.... does resulting cin binary works? (as in, show gui, allow you > > loading vids and images, edit them a bit and encode result? obviously > > on emulated aarch64 machine you want some small video, like > > 320x240... I think..) > > Will test today, audio file loads and plays fine (but still no sound > from the VM). > > > if software can do trick - why upgrade hw? :-) > > The faster CPU (from 8 threads Zen to 16 threads Zen3) will speed up > rendering too. yeah... well, if hw upgrade is possibility fir you.. > > > It might be worth investigating if cross-compile is an option, e.g. > > > build an Linux aarch64 version on Linux 86_64. The tools exists, > > > but I don't know if the configure scripts / cmake can handle that. > > > Cross-compiling would limit the slow arm emulation to the testing of > > > the build products. > > > > > > > > supposedly proot can help here: > > > > https://lists.nongnu.org/archive/html/qemu-devel/2012-03/msg04870.html > > > > === > > PRoot can also mix automatically the execution of host programs and > > the execution of guest programs emulated by QEMU user-mode. It's a > > convenient way to speed up build-time by using a cross-compiler > > instead of emulating the guest compiler. Even when mixing such > > applications, build-systems still believe they are running in a native > > guest environment, as a consequence most cross-compilation issues are > > avoided by design. For instance, with a typical "./configure" script > > (many lines were removed for readability purpose): > > > > <linux-x86>$ proot -Q qemu-arm /path/to/any/arm-rootfs/ > > > > <linux-arm>$ ./configure > > CC=/host-rootfs/opt/devkit/armv7/bin/armv7-linux-gcc > > checking whether build environment is sane... yes > > checking build system type... armv7l-unknown-linux-gnueabi > > checking host system type... armv7l-unknown-linux-gnueabi > > checking for gcc... > > /host-rootfs/opt/devkit/armv7/bin/armv7-linux-gcc checking whether > > the C compiler works... yes checking whether we are cross > > compiling... no > > I will look at your suggestion of using PRroot. However, that msg is 10 > years old, and refers to qemu in user mode. I am just about to move to > system mode, because file sharing will not work in user mode, and maybe > that will fix the audio issue too. I think you already using system mode (full system emulation - so you can run NetBsd or MacOS or windows - they see emulated/virtual machine to run on..) User-mode qemu run Linux binaries on top of same kernel BUT they can belong to another architecture! So overhead can be less.. (no mmu emulation). You can edit files inside proot 'vm' from host - no need for samba/nfs. also, proot still active project (unlike scratchbox2 from same message). Just I thought you might try it as alternative. Bugs might prevent you/us from running it .. > Also, the msg says: > ============== > As you probably know, QEMU user-mode is mainly used with binfmt_misc, > chroot, and sometimes "mount --bind". > ============== > This is not my understanding as it is used now. You just run a full > distro in it, be it Linux or some other OS. well, qemu's own docs not very useful at this moment https://www.qemu.org/docs/master/user/main.html but Debian's documentation looks better https://wiki.debian.org/QemuUserEmulation === This page describes how to setup and use QEMU user emulation in a "transparent" fashion, allowing execution of non-native target executables just like native ones (i.e. ./program). ==== Main feature from proot (aside from running as regular user - useful for me on non-rooted Android!) seems to be this accelerated cross-compiling - cross-compiler still runs from x86_64 host (not emulated at all - > fast!), yet interacts with headers, libraries and source files inside our (arm/aarch64) chroot! But I haven't tested this yet, due to difference in how clang (my host compiler in Termux) handles cross-compilation.. > > MatN >

4 15

incorporated dvd/bluray corrections in manual
by Phyllis Smith 13 Jan '22

13 Jan '22

Terje, FINALLY made the corrections in the manual as you reported in email : "EXPERIMENTAL: blu-ray lpcm profile + gui" which was dated Dec. 21 9:33AM. I have not checked them into GIT yet, but attached is a description of your corrections and how I fixed. They will not show up online until the next monthly release. Thanks to everyone for reporting any needed fixes and please continue to do so. And thank you, Terje, because the Features5 manual upon which the current manual is based was started upon your suggestion !! I never forget that. ... Phyllis

1 0