- Cin - Cinelerra-GG Mailing Lists

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

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

10 Jan '22

On Monday, January 10, 2022, <mnieuw(a)zap.a2000.nl> wrote: > On Sun, 9 Jan 2022 19:48:40 +0100 > <mnieuw(a)zap.a2000.nl> wrote: > > <snip> > > > still, it seems > > > > > > cmake_config=echo 'cmake "$$$$@" "$(1)"' > ./configure; chmod +x > > > ./configure; > > > > > > a bit above already does this step, not sure why it failed for you.. > > > > > > > Maybe because it does not do it in the root directory of that source. > > but one deeper? > > I was away, just started a complete build after "make clean" without > > my libaom mod to the makefile. We'ĺl see what happens. I left my > > giflib mod in place. > > 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? 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..) > I don't know why it failed earlier when enabling libaom, possibly > because I did not do a full rebuild. I did now, take 5 hours with > libaom included. I will upgrade my CPU. if software can do trick - why upgrade hw? :-) > > 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 === > MatN > >

1 0

Fwd: tried to make giflist, got segfault
by Phyllis Smith 09 Jan '22

09 Jan '22

Attached is the Freelancer patch so if Andrew and Andrea ould test (and Andrew look at the code) to see if it is usable, I would appreciate it. (Andrea, cd to ...cinelerra-5.1/cinelerra and do "patch < location of downloaded patch" should work. On Mon, Dec 13, 2021 at 12:07 AM Andrew Randrianasulu < randrianasulu(a)gmail.com> wrote: > > > On Sunday, December 12, 2021, Phyllis Smith <phylsmith2017(a)gmail.com> > wrote: > >> >> >>> this patch prevent gif segfault problem (but all images become the same >>> for given list!) , but not sure about other, similar crashes you observed? >>> >> Andrew, patch works just like you stated and most importantly prevents >> the crash. Similar mod would have to be put into fileexr.C, filejpeg.C, >> etc. but let me see if I can get the Freelancer to come up with a different >> solution -- he keeps nagging me for something to do. >> > > well, I think real solution should augment those filereaders with > something like report_w, report_h and then caller must check if previous > (cached) info remain the same for current frame.. so at first call we check > those params and load them into var1_w, and var1_h, then set someflag > we_read_first_info, then just copy var1_w/h to var2_w/h, repeat, now when > we have someflag set (thus not first read) compare those two, abort reading > of mismatched frame. > > > after trying to write down it like this I even think we can name vars > first_w, first_h and then check current fetched values against them, not > re-loading pair for next/priv frame at each step. > this is for avoiding quite expensive decoding, if I understand our code > correctly! > > good luck to freelancer, good health to both of you... > >> >> I agree that it needs a safeguard. Let me know if you do not find a >>>> solution because a freelancer wants to work on something and I thought he >>>> might be able to actually do this. Most of the problems are way too >>>> difficult for someone not familiar with Cinelerra to even attempt to work >>>> on. >>>> >>> >> >

2 4

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

08 Jan '22

On Sunday, January 9, 2022, <mnieuw(a)zap.a2000.nl> wrote: > On Sat, 8 Jan 2022 11:57:00 +0300 > Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > I think i made error by uppercasing __LINUX__ in my patch.. > > > > try this edited version on arm/Debian? just put in thirdparty/src and > > rebuild... > > Ah, it finished just in time. Attached is the modified thirdparty > Makefile. > > The thirdparty build process will always call ./configure in the > unpacked source directory. If a source does not use ./configure, but > e.g. cmake, it still needs a configure script that returns true. > That dummy script creation needs to be done in the xxx.cfg_vars > variable. > This was needed for libaom to succeed. it worked for me in its original form... > > > Also, libgif was missing it too, I have seen there the fix before, seems > to have gotten lost. I've added it again. for some reason file has dos/win line endings. dos2unix fixed this and resulting diff much smaller now: $ dos2unix ~/storage/downloads/Browser/Makefile_thirdparty_matN dos2unix: converting file /data/data/com.termux/files/home/storage/downloads/Browser/Makefile_thirdparty_matN to Unix format... $ mcedit ~/storage/downloads/Browser/Makefile_thirdparty_matN $ diff -u thirdparty/Makefile ~/storage/downloads/Browser/Makefile_thirdparty_matN --- thirdparty/Makefile 2022-01-06 19:05:18.735393694 +0300 +++ /data/data/com.termux/files/home/storage/downloads/Browser/Makefile_thirdparty_matN 2022-01-09 02:23:08.606957106 +0300 @@ -197,11 +197,11 @@ audiofile.mak_params?=LIBS="-lm -lstdc++" flac.cfg_params?= --enable-shared=no flac.cflags?="$(call inc_path,libogg) $(call ld_path,libogg,src/.libs)" -giflib.cfg_params=echo "exec true" > ./configure; chmod +x ./configure; +giflib.cfg_vars=echo "exec true" > ./configure; chmod +x ./configure; lame.cfg_vars?= CFLAGS+=" -O" lame.cfg_params?=--enable-shared=no lame.mak_params?= ; cd $(call bld_path,lame,include); ln -sf . lame -libaom.cfg_vars?= mkdir aom.build && cd aom.build && $(call cmake_config,..) +libaom.cfg_vars?= echo "exec true" > ./configure; chmod +x ./configure; mkdir aom.build && cd aom.build && $(call cmake_config,..) libaom.cfg_params?= -DENABLE_TESTS=no -DCMAKE_BUILD_TYPE=Release -DENABLE_DOCS=no -DENABLE_SHARED=no -DCMAKE_INSTALL_LIBDIR=lib \ -DENABLE_EXAMPLES=no -DCMAKE_INSTALL_PREFIX=$(call bld_path,libaom)/usr/local libaom.mak_params?= ; $(MAKE) -C libaom*/aom.build install $ i'll try rebuild with your modifications and report back.. > MatN >

1 1