January 2022 - Cin - Cinelerra-GG Mailing Lists

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

Re: [Cin] Analog DV Capture
by Terje J. Hanssen 04 Jan '22

04 Jan '22

I read and think I understood 1) Preserving data and timecode 2) But unsure what's new about 2) regarding max quality via usual firewire connection First, this looks to be for Digital Video (DV/HDV, Digital8 not mentioned) recorded on mini (H)DV tape cassettes. And not for Analog Video(?) (VHSC/8mm/S-VHSC/Hi8/S-video) recorded on tape cassettes the generation before that The analog-digital convertersion, i.e Hi8 S-video to DV doesn't usually preserve the analog recorded date and time code or RCTC. Not advanced, but better than nothing I therefore used to manually display (switch on) the time and date at the start of video sequences. Discovered also an old post I have had about TC and RCTC ... http://www.verycomputer.com/311_d1c132d0a14432ec_1.htm#p7 On Sunday, January 2, 2022, Andrea paz via Cin <cin at lists.cinelerra-gg.org> wrote: > @Andrew-R > @Terje > Found this discussion on an Italian NewsGroup; no idea if it can be > useful... > > > 1) How to capture on Hard Disk video-films recorded on magnetic cassette > tapes "Mini Dv" without losing the date and time of the original video > recording on > the magnetic tape? > > 2) And without losing the best quality obtainable by downloading with > cable and DV sockets (with digital signals; e.g. with i.Link, IEEE.1394 > standard) > > > The two things coincide: date/time data and other information > (timecode, aspect-ratio, color/BN, DV type [DV25, DV50, DVCPROHD_1080i, > DVCPROHD_720p], PAL/NTSC, interlaced/progressive, audio locked/ > unlocked, aperture, frame rate, etc. > unlocked, aperture, gain, shutter) are contained in VAUX blocks of each > frame. > VAUX blocks of in each DV frame (to be exact, they could be contained in > each > contained in each DIF block, 12000 bytes, and each frame in PAL is > composed of > composed of 12 DIF blocks, 144000 bytes, but usually they are put only > on the first DIF block of the frame), then downloading on PC the > digital data of the > digital data of the MiniDV cassette you also make a backup of the > information about > date/time information. > > Similarly for HDV (MPEG-2 Transport Stream) data stored on the MiniDV > cassette: all this information is contained in packets. > MiniDV cassette: all this information is contained in Private Stream > A1 packages (commonly called Sony A1). > > > 3) And perhaps by having such data captured in the "detail-properties" > of the video files that are created, as is normally the case with today's > cameras, instead of seeing them > cameras of today, instead of seeing them appear inside the image of the > video > when of the image of the video when you watch it on the monitor? > > This one is a tad more complicated.... While cameras > enter this information once into the EXIF/XMP/ > IPTC sections of the JPG/RAW[TIFF] file, for DV video this information is > relative to each frame (or inserted on each frame of type I > or P for HDV videos, i.e. every 3 frames), and so it is a little bit > difficult to show you all the information. > You could show the information of the first frame, but if, for example, a > for example, a file was composed by more recordings, that information > would be wrong for the recordings > would be wrong for the recordings following the first one, not to mention > that > diaphragm/gain/shutter could change frame by frame. > frame by frame. > > Back in the day (2010, so a bit after 2004...) I had made available a > small program to extract data in text format: > > https://video.liberdomus.org/software/extract_dvaux.zip > > Just run the program from DOS prompt (or shell unix, they are also > compiled for Linux/64bit): > > extract_dvaux.exe filedv > info.txt > > The "filedv" can be any file format (AVI, MOV, RAW DV) that contains > DV packets (also compatible with the Canopus-DV codec): > a line is written every time some parameter changes. > At the end a short report is also written about how many frames/blocks > have been analyzed and if the audio is "locked" or not. > -- > Cin mailing list > Cin at lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin >

1 0

December new AppImage-s now available
by Phyllis Smith 03 Jan '22

03 Jan '22

Newest release now available in the Cinelerra Download area: https://cinelerra-gg.org/download/images/ and includes a Debian 11.0 32-bit version: https://cinelerra-gg.org/download/images/CinGG-20211231-i386-newer_distros.… *********************** Newest Changes **************************** GIT for Cinelerra-GG has the following changes from 12/01/2021-12/31/2021 Anonymous Contribution: - *15 plugins have improved GUIs* to add Tumbler Boxes with current value now visible and ability to type in a specific desired value. Modified plugins are: Alpha (+ Reset button was added), Blur, Brightness, Huesaturation, LinearBlur, Polar, RadialBlur, RgbShift, Sharpen, Unsharp (+ hard to use Dial switched to the more consistent slider bar), Wave, Whirl, Yuv, YuvShift, and ZoomBlur. *Andrew Work* (+ handling many emails to include a lot of related interest areas of CinGG): - Additional minor mods for Android on Termux have been incorporated as provided. - Modified what gets built for openexr, tiff and libavc1394 to reduce size and build time just slightly. - Minor changes to vframe.C, vrender.C, and cinelerra/guicast Makefile-s. - Updated libjpeg-turbo from 2.1.0 to 2.1.2. *MatN Assistance*: - Testing as usual and minor change for “aarch64” build. - Much needed help provided to get Debian 11.0 working with AppImage so able to now create a monthly CinGGdate-newer.AppImage. *Andrea Help*: - Always minor fixes to the Manual; excellent responses to forum questions; building CinGG whenever new mods are added or patches need testing.

5 4

Analog DV Capture
by Andrea paz 02 Jan '22

02 Jan '22

@Andrew-R @Terje Found this discussion on an Italian NewsGroup; no idea if it can be useful... > 1) How to capture on Hard Disk video-films recorded on magnetic cassette tapes "Mini Dv" without losing the date and time of the original video recording on the magnetic tape? > 2) And without losing the best quality obtainable by downloading with cable and DV sockets (with digital signals; e.g. with i.Link, IEEE.1394 standard) The two things coincide: date/time data and other information (timecode, aspect-ratio, color/BN, DV type [DV25, DV50, DVCPROHD_1080i, DVCPROHD_720p], PAL/NTSC, interlaced/progressive, audio locked/ unlocked, aperture, frame rate, etc. unlocked, aperture, gain, shutter) are contained in VAUX blocks of each frame. VAUX blocks of in each DV frame (to be exact, they could be contained in each contained in each DIF block, 12000 bytes, and each frame in PAL is composed of composed of 12 DIF blocks, 144000 bytes, but usually they are put only on the first DIF block of the frame), then downloading on PC the digital data of the digital data of the MiniDV cassette you also make a backup of the information about date/time information. Similarly for HDV (MPEG-2 Transport Stream) data stored on the MiniDV cassette: all this information is contained in packets. MiniDV cassette: all this information is contained in Private Stream A1 packages (commonly called Sony A1). > 3) And perhaps by having such data captured in the "detail-properties" of the video files that are created, as is normally the case with today's cameras, instead of seeing them cameras of today, instead of seeing them appear inside the image of the video when of the image of the video when you watch it on the monitor? This one is a tad more complicated.... While cameras enter this information once into the EXIF/XMP/ IPTC sections of the JPG/RAW[TIFF] file, for DV video this information is relative to each frame (or inserted on each frame of type I or P for HDV videos, i.e. every 3 frames), and so it is a little bit difficult to show you all the information. You could show the information of the first frame, but if, for example, a for example, a file was composed by more recordings, that information would be wrong for the recordings would be wrong for the recordings following the first one, not to mention that diaphragm/gain/shutter could change frame by frame. frame by frame. Back in the day (2010, so a bit after 2004...) I had made available a small program to extract data in text format: https://video.liberdomus.org/software/extract_dvaux.zip Just run the program from DOS prompt (or shell unix, they are also compiled for Linux/64bit): extract_dvaux.exe filedv > info.txt The "filedv" can be any file format (AVI, MOV, RAW DV) that contains DV packets (also compatible with the Canopus-DV codec): a line is written every time some parameter changes. At the end a short report is also written about how many frames/blocks have been analyzed and if the audio is "locked" or not.

2 1

offtop: wine/X under Haiku os
by Andrew Randrianasulu 01 Jan '22

01 Jan '22

Some time ago we wondered if Haiku os will run X applications. At that time answer looked like no, but now some great progress was made, so may be at least basic x11 version of CinGG will be possible. https://discuss.haiku-os.org/t/my-progress-in-porting-wine/11741

1 0