- Cin - Cinelerra-GG Mailing Lists

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

qemu user mode
by Andrew Randrianasulu 08 Jan '22

08 Jan '22

should be faster than full VM for compiling, but might not work for testing /proc/self pointing at wrong image? also ALSA still not work if called under qemu-user, last I checked) https://wiki.debian.org/QemuUserEmulation Installing packages The binfmt-support package contains a helper script to easily register/unregister binary formats with the kernel using the binfmt_misc module. Install qemu, binfmt-support, and qemu-user-static: # apt install qemu binfmt-support qemu-user-static Check whether the binfmt entries were successfully registered: # update-binfmts --display This command should print entries for each supported target user emulator, except for the host system. === see appendix if you already have chroot folder with arm system or try to use Raspbian's one from https://wiki.debian.org/RaspberryPi/qemu-user-static a bit involved when it comes to image resizing... === Note: If the host system is Debian Buster and the chroot will be Debian Bullseye, it is good to make sure the host has the version 5.2 of qemu-user-static, available from buster-backports. Otherwise some binaries may cause qemu-user-static to Seg Fault, see 987497. For example setting locale(s) in chroot fails without the upgrade of qemu-user-static. {..} sudo losetup -f -P --show 2020-08-20-raspios-buster-arm64.img Mounting the image Mount the image with root permissions: sudo mount /dev/loop0p2 -o rw /mnt Optional: If you want to mount the RaspiOS /boot sudo mount /dev/loop0p1 -o rw /mnt/boot Also mount necessary host directories. cd /mnt sudo mount --bind /dev dev/ sudo mount --bind /sys sys/ sudo mount --bind /proc proc/ sudo mount --bind /dev/pts dev/pts (not necessary/advised if you use systemd-nspawn) To get everything work (e.g., network) you need to comment out everything in /mnt/etc/ld.so.preload before you chroot in. Take care of that now! (not sure if copying qemu binary into chroot still needed on latest Debian?) cp /usr/bin/qemu-aarch64-static /mnt/usr/bin or qemu-arm-static for armhf Now chroot in! cd /mnt (not needed if we already in mnt?) sudo chroot . bin/bash now you can try to get git sources and install usual deps for Cin-gg compilation from inside arm/aarch64 chroot and see how far it comes! ===

1 2

libaom 3.2.0 patch1 fixed for arm/linux?
by Andrew Randrianasulu 08 Jan '22

08 Jan '22

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...

1 0

Fwd: libdv patch (was: Re: another patch series)
by Phyllis Smith 08 Jan '22

08 Jan '22

Checked into GIT, thirdparty/Makefile which includes the modifications from Andrew of autoconf/autoreconf needed for aarches64 and the lidv-1.0.0.patch0 (also needed because libdv would not compile without it on Fedora 32 or Debian 11.0 32-bit). Attached is its log file when it would not compile. Before adding the patch, I had installed what I could find on a Fedora system for "libsdl1(-dev)" but it did not fix the error -- I did a "yum install libsdl*" and it installed stuff but I only saw version 2 and not 1 and did not see any libsdl at all. Also checked another Fedora system to see what it would have installed and I just get: [root@keystone Downloads]# yum install libsdl1* Last metadata expiration check: 1:05:20 ago on Wed 05 Jan 2022 01:55:05 PM MST. No match for argument: libsdl1* Error: Unable to find a match: libsdl1* Part of the patch contained these lines which I thought were HILARIOUS ! +# Configure paths for SDL +# Sam Lantinga 9/21/99 +# *stolen from Manish Singh* +# s*tolen back from Frank Belew* +# s*tolen from Manish Singh* +# *Shamelessly stolen from Owen Taylor* On Tue, Jan 4, 2022 at 5:54 AM Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > just put in thirdparty/src as libdv-1.0.0.patch0 and see if it helps ? > > I build with clang, also (default for x86 linux usually gcc) > > On Tuesday, January 4, 2022, Andrew Randrianasulu <randrianasulu(a)gmail.com> > wrote: > >> >> >> On Tuesday, January 4, 2022, Phyllis Smith <phylsmith2017(a)gmail.com> >> wrote: >> >>> Andrew, attached is the thirdparty Makefile that I would like to check >>> into GIT tomorrow. I hope it includes all of the patches you provided in >>> respect to autoconf. It builds and runs correctly on Fedora 32 and Debian >>> 32-bit 11.0 Bullseye. The only thing that I know is still missing is the >>> line: libdv.cfg_vars?= autoreconf -ifv -I m4 && automake -caf; which I >>> have commented out. It fails on both Fedora and Debian (I will have to >>> attach another config.log file but forgot to move it over yet). I will >>> look at it again tomorrow but may have to wait until MatN looks at it to >>> figure out what is wrong. >>> >> >> >> you tried to install libsdl1(-dev) on build host? >> >> I have it onstalled as dependency of some other package... >> >> sorry, not yet extracted patch supposed to fix 'autoreconf in libdv in >> adsense of libsdl' from previous mail... >> >> >> but thanks anyway.... >> >>> >>> Even STRANGER than you think! When I compare "exit 2" (the non-working >>>>> config.log) to "exit 0" (the working config.log), it shows the bad one >>>>> using Autoconf 2.6*9 *but the one that works uses Autoconf 2.6*0.* >>>>> This does not make sense. And so 2.6*9* may be causing the problem >>>>> identified on line 52 but I do not know why. There must be a >>>>> parameter on the ling >>>>> Line 52: configure:2661: WARNING: 'missing' script is too old or >>>>> missing >>>>> >>>>> There must be a parameter on the line: libdv.cfg_vars?= autoreconf >>>>> -ifv -I m4 && automake -caf; >>>>> that makes it use a different autoconf? >>>>> >>>> >>>> yeah, it was part of change required for for auto-updating config. >>>> guess (for aarch64) >>>> >>>>

4 11