- Cin - Cinelerra-GG Mailing Lists

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

Blur plugin: Alpha determines radius
by Igor BEGHETTO 31 Dec '21

31 Dec '21

Hi! In Blur plugin there is the "Alpha determines radius" option. I think it doesn't work but I can wrong. Can someone explain to me how it works, please? Thanks! IgorBeg

4 32

our ffv1.mkv profile
by Andrew Randrianasulu 29 Dec '21

29 Dec '21

seems to miss level=3 setting $ cat bin/ffmpeg/video/ffv1.avi avi ffv1 $ cat bin/ffmpeg/video/ffv1.mkv matroska ffv1 threads=8 context=1 slices=30 $ cat bin/ffmpeg/video/ffv1.mov mov ffv1 #coder=0 context=1 g=1 level=3 threads=16 slices=16 slicecrc=1 #pass=2 $ not sure if we should modify our avi/mkv profikes or add new (may be with _v3 name) ones?

3 9

Uncompressed video to lossless compression FFV1/MKV
by Terje J. Hanssen 25 Dec '21

25 Dec '21

Background: Digital video produces vast amounts of data. Take PAL-SD material (only image, no audio), stored as YUV422 with 8-bits per component (=16-bits per pixel) and a resolution of 720x576 pixels, for example. http://download.das-werkstatt.com/pb/mthk/info/video/comparison_video_codec… * Applying no compression at all (=uncompressed <http://download.das-werkstatt.com/pb/mthk/info/video/comparison_video_codec…>) results in: * 720 x 576 x 16 bits x 25 frames ≥ 1.159 GiB/Minute * * For YUV422, 10 bpc (10+5+5 = 20 bits per pixel), this would be: * 720 x 576 x 20 bits x 25 frames ≥ 1.448 GiB/Minute So you would fit no more than 4 minutes of video on a whole 4.7 GiB DVD. Since these values are already uncomfortable (even for 422-subsampled PAL), imagine HD and beyond. Therefore, you will hardly find uncompressed video in the wild, except for temporary editing use cases. ----------- The examples below show the differences in storage space required for uncompressed, lossless and lossy video codecs: https://www.scart.be/?q=en/content/short-guide-choosing-digital-format-vide… * uncompressed (e.g., v210) 10-bit -> approx. 100GB per hour of video; * lossless compression (FFV1 and JPEG 2000) 10-bit -> approx. 45-50 GB per hour of video; * lossy compression; * MPEG 2/DV50/IMX50 (50 Mbps) -> approx. 25 GB per hour of video; * to compare with * DV (DV25) -> approx. 12 GB per hour of video; * MPEG 2 (DVD quality) -> approx. 3.6 GB per hour of video. ------------- That is, if we manage to capture 422 uncompressed video via either an internal capture card or via an external SSD recorder, there is a need for * mathematical lossless compression with typical intraframe FFV1/MKV for preservation (archive masters) * and/or possibly "visually lossless" compression to a lossy intraframe intermediate/mezzanine format I had no uncompressed test file available, but tried this guide to generate a simple video (only) file: Compressing and uncompressing a preservation master video file https://bits.ashleyblewer.com/blog/2018/11/08/compressing-and-uncompressing… ffmpeg -f lavfi -i mandelbrot=size=640x480:rate=25 -c:v v210 -t 5 uncompressed.mov and next to turn it to a FFV1/MKV lossless compressed file ffmpeg -i uncompressed.mov -map 0 -dn -c:v ffv1 -level 3 -g 1 -slicecrc 1 -slices 16 -c:a copy ffv1.mkv and if required a test to uncompress the FFV1/MKV file to uncompressed 10bit file again: ffmpeg -i ffv1.mkv -c:v v210 uncompressed-again.mov du -s * 105004 uncompressed.mov 22844 ffv1.mkv 105004 uncompressed-again.mov In this simple case the lossless compressed ffv1.mkv size is schrinked to 22% of the uncompressed.mov file. In other practical tests I read the FFV1 file size was schrinked to 1/3 to 46% of the uncompressed video. (I tested for fun to transcode a "visual lossless" compressed ProResHQ.mov file to FFV1/MKV, but that extented the file size to 180% ) I loaded the simple generated ffv1.mkv in Cinelerra, but also read about a problem in a previous thread [Cin] Single-frame step fwd/bak in viewer delayed? https://www.mail-archive.com/cin@lists.cinelerra-gg.org/msg01799.html Is this problem solved? And will the lossless compressed (preservation) format FFV1.MKV work as a editing format, or will there be a need beside to have another intermediate format MPEG 2/DV50/IMX50 (50 Mbps) for editing? ---------- Terje J. H

2 2