March 2019 - Cin - Cinelerra-GG Mailing Lists

Segfault
by Daniel Reurich 13 Mar '19

13 Mar '19

Hi, I had a segfault today while dragging media onto the timeline: ** segv at 0x558b048d17f1 in pid 7715, tid 7816 writing debug data to /tmp/cinelerra_7715.dmp lock_items: 37 lock_frees: 16 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 mov_sphere=0 jpeg_sphere=0 ** dump complete Segmentation fault Dump file attached. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722

2 1

ppc64le incomplete patch #2
by Andrew Randrianasulu 10 Mar '19

10 Mar '19

Ok, disabling fileac3 was bad idea, thankfully libzmpeg3 can be compiled without mmx and x86 assembly IF you disable futex use in it! https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerr… 8 #define USE_FUTEX I commented this out Now at least 'cin' executable builds and links correctly on Alpine linux ppc64le, waiting for plugins and rest of stuff to be build... ---------------------

2 2

Just a test
by Sam 10 Mar '19

10 Mar '19

It's just a test mail. You can ignore it. --

1 0

Translation website into Russian
by Aleksei Ishutin 10 Mar '19

10 Mar '19

Good day. My name is Alexey, I am from Minsk, Belarus. I want to help you translate your website into Russian. How can I help you with this?

2 2

Compile on Arch (only a curiosity)
by Andrea paz 09 Mar '19

09 Mar '19

I can't compile the last 2 release. The configuration and make steps are fine, but I have an error in the "make install" step: [...] cp -a COPYING README models Cinelerra_factory expanders.txt \ shuttlerc ffmpeg msg info tips lv2_blacklist.txt bin/. sed -e 's/\<cin\>/cin/g' < image/cin.desktop \ > "bin/applications/cin.desktop" cp -a image/cin.svg "bin/pixmaps/cin".svg cp -a image/cin.xpm "bin/pixmaps/cin".xpm mkdir -p bin/plugins/picon/cinfinity for d in picon/*; do \ if [ $d = picon/cinfinity ]; then continue; fi; \ cp -a $d bin/plugins/picon/.; \ done cp -a db/utils/new_db "bin/cin_db" cd bin; /home/paz/cinelerra5/cinelerra-5.1/inst.sh "/usr/bin" \ zmpeg3{cat,cc2txt,ifochk,show,toc} cp: impossible to create the regular file '/usr/bin/zmpeg3cat': Permission denied make: *** [Makefile:977: zmp_install] Error 1 If I compile using ./bld.sh instead, there are no errors. (All the installations I did were non-root.)

2 4

Playback Slows Down Immensly Durring Transitions
by ben＠innovationplex.com 09 Mar '19

09 Mar '19

Effects like BlueBanana are fine, but even simple transitions like dissolve cause the framerate to go anywhere from 35-60 all the way down to a slideshow. Not sure why this is, but I'm using the latest build (as of Feb 27th on Arch). My media is mostly h264 FLVs (with one MP4, though this does not seem to make a difference) and I am using the x11 video output. Oddly I have noticed that for single video tracks towards the top of the composting stack x11-OpenGL is the fastest, but for anything else x11 with the direct x11 render option is fastest for normal playback. Neither of these are enough to stand against transitioning however. Funnily enough, everything I've tried from h264 inside an FLV, MP4, and MOV to a ProRes MOV file seem to play back all the same, but when transitioning they all seem to slow down horribly. I'm not sure if this has been fixed in the latest development version, I suppose I'll see tomorrow.

5 14

x265 multidepth info
by Andrew Randrianasulu 03 Mar '19

03 Mar '19

Hello, all! While watching slow Cinelerra-GG build in my emulated PowerPC machine I come to interesting observation: it seems x265 build itself just once, while 'multidepth' script provided in build/linux directory does three-times build (like it already done for x264 for Cinelerra's use, i think) https://bitbucket.org/multicoreware/x265/wiki/Home Multilib build instructions Applications like ffmpeg and the x265 CLI which use our bit-depth introspection API (x265_api_get) instead of the globally exported C interface can select between 8 and 10bit libx265 libraries at runtime. To support this both libraries must be available either as shared libraries or as a pair of static libraries. For shared libraries, just rename your 10bit libx265 as libx265_main10.[so|dll|dylib] and place it into your library load path. For static libraries, you must disable the exported C APIs, since they would conflict with each other. For linux/Mac, you can use or adapt the build/linux/multilib.sh script. For Windows, there are similar vc*-x86_64/multilib.bat files that demonstrate how combined static libraries can be built. See also multilib docs. https://github.com/videolan/x265/blob/ab384cf7b225dda73b7881c95f41e7e141cd8… ---------------- #!/bin/sh mkdir -p 8bit 10bit 12bit cd 12bit cmake ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON make ${MAKEFLAGS} cd ../10bit cmake ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF make ${MAKEFLAGS} cd ../8bit ln -sf ../10bit/libx265.a libx265_main10.a ln -sf ../12bit/libx265.a libx265_main12.a cmake ../../../source -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON make ${MAKEFLAGS} # rename the 8bit library, then combine all three into libx265.a mv libx265.a libx265_main.a uname=`uname` if [ "$uname" = "Linux" ] then # On Linux, we use GNU ar to combine the static libraries together ar -M <<EOF CREATE libx265.a ADDLIB libx265_main.a ADDLIB libx265_main10.a ADDLIB libx265_main12.a SAVE END EOF else # Mac/BSD libtool libtool -static -o libx265.a libx265_main.a libx265_main10.a libx265_main12.a 2>/dev/null fi ------------------ strangely, I can't see script in current x265 github web interface, while it definitely is there in x265-3.0 directory as used by Cinelerra-GG! Anyway, my emulated machine (or more accurately e5500 CPU, as used in this X5000 machine [1]) can't execute altivec instructions, so I force-disabled altivec for ffmpeg, x264, and x265. Waiting for results ... [1] - https://www.amigaos.net/hardware/133/amigaone-x5000

1 0

Compiling Cinelerra-GG for (l)ubuntu 16.04.6 ppc32
by Andrew Randrianasulu 02 Mar '19

02 Mar '19

Hello again, everyone! After spectacular failure about building working Cinelerra-GG on ppc64le I moved to more common ppc platform - emulated powerMac! Well, I only installed ubuntu with qemu's -M mac99, and then moved resulted image as virtual drive to another type of machine, supporting SMP (and thus faster for compiles). install: qemu-system-ppc -display sdl,gl=on -M mac99 -cpu g4 -cdrom /mnt/lubuntu-16.04-desktop-powerpc.iso -drive format=raw,file=/mnt/Ubuntu-16.04-ppc.img,index=0,if=virtio -device qemu-xhci -device intel-hda -device virtio-keyboard-pci -nic user,model=virtio -usb -device virtio-mouse-pci -m 2000 -g 1024x768x32 -boot d run (assumes 64-bit qemu host, so smp will be faster actually, using qemu 3.1.0 in my case): ppc64-softmmu/qemu-system-ppc64 -display sdl,gl=off -smp 4 -M ppce500 -cpu e5500 -drive format=raw,file=/mnt/Ubuntu-16.04-ppc.img,index=0,if=virtio -kernel /mnt/linux-image-4.20.12-X1000_X5000/X5000_and_QEMU_e5500/uImage-4.20 -append "rw root=/dev/vda3" -device virtio-vga,virgl=off -device qemu-xhci -device intel-hda -device virtio-keyboard-pci -nic user,model=virtio -usb -device virtio-mouse-pci -m 2000 -g 1024x768x32 gl=off makes colors normal, but console slower .... intel-hda, qemu-ehci and ES1370 fail with dma alloc errors. lightdm will fail to start, log in and 'systemctl disable lightdm' kernel from http://www.xenosoft.de/linux-image-4.20.12-X1000_X5000.tar.gz http://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4138&sid=72c47… I already run into small failure in libvpx-1.7.0, it will probably exist in libvpx-1.8.0 as well. New libvpx assumes you build for ppc64. Patching configure seems to help: http://openbsd-archive.7691.n7.nabble.com/UPDATE-libvpx-1-8-0-td360246.html --- patches/patch-configure 17 Oct 2018 08:22:29 -0000 1.17 +++ patches/patch-configure 5 Feb 2019 00:18:13 -0000 @@ -2,18 +2,17 @@ $OpenBSD: patch-configure,v 1.17 2018/10 Index: configure --- configure.orig +++ configure -@@ -114,8 +114,10 @@ all_platforms="${all_platforms} armv7s-darwin-gcc" +@@ -115,7 +115,9 @@ all_platforms="${all_platforms} armv7s-darwin-gcc" all_platforms="${all_platforms} armv8-linux-gcc" all_platforms="${all_platforms} mips32-linux-gcc" all_platforms="${all_platforms} mips64-linux-gcc" +all_platforms="${all_platforms} ppc-linux-gcc" - all_platforms="${all_platforms} ppc64-linux-gcc" all_platforms="${all_platforms} ppc64le-linux-gcc" +all_platforms="${all_platforms} sparc-linux-gcc" all_platforms="${all_platforms} sparc-solaris-gcc" all_platforms="${all_platforms} x86-android-gcc" all_platforms="${all_platforms} x86-darwin8-gcc" -@@ -170,7 +172,7 @@ for t in ${all_targets}; do +@@ -166,7 +168,7 @@ for t in ${all_targets}; do [ -f "${source_path}/${t}.mk" ] && enable_feature ${t} done I think you can just add ppc-linux-gcc line without removing ppc64 line.

1 0

Re: [Cin] New monthly builds for Cin-GG are available
by Benrob0329 01 Mar '19

01 Mar '19

Awesome work guys, I owe a big thank you to everyone involved to making such a great project :-)

1 0

New monthly builds for Cin-GG are available
by Phyllis Smith 01 Mar '19

01 Mar '19

There are new monthly builds on the website - follow the links to download from: https://www.cinelerra-gg.org/downloads/ We had some trouble with the newest additions of AV1 and WebP but were finally able to work around them EXCEPT the older operating systems of ubuntu14 (32 and 64 bit) and debian 8 do not have them included because of too old cmake utilities. ------------------------------- Copy of Release Notes (on the webserver too) ------------------------------- Cinelerra-GG (Version Infinity) Release Notes for 02/01/2019-02/28/2019 for builds 1. *AV1 and WebP* decode and encode are now available in Cin-GG if using the standard builds. This involved adding these 2 thirdparty libraries: libwebp-1.0.2 and libaom-v1.0.0 . There are new ffmpeg opts files to allow users to render to these 2 formats: webp.webp and av1.webm . The webp format requires that users have libtool installed. Ubuntu14 and Debian 8 do not have these included. 2. Many *thirdparty packages have been upgraded* to include the latest versions for: x265 version 3.0, fftw-3.3.8, libogg-1.3.3, libvorbis-1.3.6, openjpeg-2.3.0, opus-1.3, tiff-4.0.10, and libgif 5.1.6. A new format choice of jp2 is available for openjpeg 3. *Gif native capability *has been completely upgraded to allow for reading and writing the gif format in singles, sequences or lists. As a side effect of this effort all of the other sequences have had the letter “s” added at the end of the extension filename automatically generated on a render. 4. Deleted code for native ogg/vorbis because too many errors/not working and ffmpeg version better. 5. Because *this affects most everything*, be advised the the transport queue and playback engine were reworked, initially for shuttle speed control, but then it was determined that if a user keeps pressing keys really fast so that there are many queued up commands some may be thrown away. Although with much help from the users, it is possible that there may still be issues with locks. 6. All of the O/S distros on the build machines here were updated in order to add the libusb library as needed for USB Direct usage of the Shuttle. If doing your own builds, you will need to rerun bld_prepare.sh to get the included libusb requirements. README.arch on the server has this added. 7. Usability Improvements Two new shortcuts added to create identity keyframes for camera and projector, Shift-F11/F12. Ripple method for drag handles has been reworked to be the old method; Edge switched for new. DVB channel / tuner api has been upgraded / improved to replace deprecated code. Load menu has had some informational fields added to make it more understandable for new users. Added fps calculation when using Batch Render from the command line with the render farm. There is a colored box representing the currently chosen auto on the zoombar at the bottom of the main program window, as well as to the left of the message, of the same color as the line to make it easy to see which line type is being manipulated. Transitions now can use frames/hhmmss:frm/hhmmss:xxx instead of just seconds for the length. In addition you can use the mouse wheel to change the length in real time. Changes to the *Shuttle code from testing and feedback of Pierre includes *the following: Addition of ShuttlePRO to the PROv2 and Xpress has been added as another device name. Composer/viewer fullscreen modes now work with the shuttles. The rules file is now available as it had been inadvertently left out of last month’s builds. Instead of only 3 forward and reverse speeds, there are now 6 of each and they can be defined in decimal numbers as well as integers up to and including 64x. S0 position on the wheel was not generating a signal so the S1 and S-1 have to be used for Stop. The default shuttlerc file has been tuned by Pierre and Phyllis to reflect the more useful settings. Shudmp file is included in Cin’s distribution for use in checking your Shuttle hardware. Removed regex from usage with the shuttle as of little use for Cinelerra. There is an alternative usb_direct usage instead of going through the hid generic driver; this required new 99rules and shuttlerc files. It is recommended for usage to ensure K14/K15 work. Added Alt, Ctrl, and Shift with character options to allow for more assignment key options. 8. Bugs/Issues Fixed Makefile clean tweak, ydiff ffmpeg tweak, delete old CHANGELOGS, fix downloads.txt. Fix editpanel window lock issues. Use undo bracketing to avoid stop playback deadlocks. In Drag and Drop edit mode, a silent selection between 2 edits would crash while dragging. The usual ongoing cleanup was done while modifying code. R-usage has been added to print out the CPU time used when Quit if running from a terminal. Size of Font box in the Titler has been increased so no need to scroll to see the full name. Fix single step jitter. A jpeg file of odd dimension instead of divisible by 2 was causing a segv but fixed now. Added another booby trap to catch potential problems. Camera drag tweaks incorporated. Viewer selection criteria was incorrectly set so that frame forward was going to the end instead. Sync parameter fix put in. Shortcuts.html updated for missing or new shortcuts. Ripple and Slip had some problems with “follow edits” and “keyframes follow” but now fixed. At least 3 batch render boobies were caught and fixed as well as a C41 plugin booby + track resize. The Rotate plugin crash was fixed + some other rotate with 0 problem + fixed for some translations. Build scripts now allow for any Python level rather than restricting to Python3. Another change for builds is to check for x86 or x64 before compiling any assembly code. The fps for still images has been set to 10 fps.

2 1