- Cin - Cinelerra-GG Mailing Lists

Unable to start Cinelerra-GG binary built from source using build instructions in manual
by Justin Wayland 10 Sep '24

10 Sep '24

I compiled Cinelerra-GG from source on openSUSE Tumbleweed and succeeded at building it, but when I tried to run it all I got was the opening window and the error log attached to this message. This happened regardless of whether I ran it in XWayland or X. The AppImage provided on the website works. The debug data was empty. Any help would be appreciated. -Justin

2 3

The best strategy to render yuv (mpeg, limited range) from yuvj (jpeg, full range)?
by Tarantas 08 Sep '24

08 Sep '24

So, my sources are in yuvj, and my target (youtube) is yuv. I want to find the best strategy to minimize color banding and maximize dynamic range available. My current settings for this are: - JPEG in "preferences"; - RGBA-float in "format" (color correction in YUV leads to a lot of color banding). The problem is: I couldn't render this RGBA-float into YUV. No matter what render settings I use, it renders in full range. Putting color_range=mpeg doesn't help, because it just flags the file to be in limited range, leading to increased contrast of image. So, I'm a little confused. What I am really supposed to do? Using ColorSpace filter is not convenient with filter like histogram, for example.

5 26

Minor Openjpeg and Tiff library upgrades + fix Giflib patch2
by Phyllis Smith 08 Sep '24

08 Sep '24

Checked into GIT: Openjpeg upgrade from 2.5.0 to 2.5.2. Tiff upgrade from 4.6.0 to 4.6.0t - this just puts back things deleted in 4.6.0 due to security. Fixed Giflib 5.2.2 patch2 that Andrew found had a bug that Termux spotted whereas Fedora and Ubuntu did not care.

1 0

Build fails on termux
by Andrew Randrianasulu 07 Sep '24

07 Sep '24

due to giflib-5.2.2.patch2 I removed patch and build is ok. Not sure where this patch was needed, may be on older distros? I also tried to "set -e" before building cingg and get build breaking error somewhere in x265 dir, as reported already. but for me default (seen with "set -o" ) errexit=off, you can set it off for specific build by executing "set +e" before building cingg.

2 7

offtopic: Quantel boxes
by Andrew Randrianasulu 26 Aug '24

26 Aug '24

Because I monitor mame WIP thread I saw some news about Quantel Paintbox emulation in MAME (0) and then I randomly followed some links to other Quantel systems Like HAL (basically like hardware compositor) http://dexterslab2013.blogspot.com/2018/03/quantel-hal-video-compositing-sy… 99 layers of SD images or video, up to 15 min storage on 20 disk array! https://m.youtube.com/watch?v=4k15hpeGzBA if you have half of hour you can watch this demo from 1997. Biggest thing so far for me? We are free to use old-fashioned optical effects in front of real camera too :) (0) - https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=120292&page…

2 2

h264 vulkan encoding
by Andrea paz 23 Aug '24

23 Aug '24

A patch brings hardware encoding with vulkan into ffmpeg. In the future I will try to make a preset for h264, but if I understand correctly you have to use the ffmpeg from Lynne's repository and then compile it with the --enable-vulkan option. Do you think a simple replacement of our ffmpeg tar.gz with Lynne's tar.gz is enough? https://lynne.ee/vulkan-video-encoding.html

4 18

Stack smashing detected
by Stefan de Konink 16 Aug '24

16 Aug '24

If you are ever hit by "Stack smashing detected". Go to Settings > Performance and set "Use HW Device" to "none". Lets hope that Google indexes the Cinerella mailinglist. -- Stefan

2 1

AV1 yuv422p10le rendering with some output FFStream::seek I/O errors, seek fails
by Terje J. Hanssen 12 Aug '24

12 Aug '24

So far it seems like 10-bit color depth yuv422p10le is only available for AV1 via FFmpeg encoders libaom-av1 and librav1e. That is not yet with the from experience faster libsvtav1, which currently support pixel formats yuv420p and yuv420p10le. My AV1 (video only) test run procedure using CinGG loading a 10-bit input file, resulted in 12% smaller file size than with h265. Visually the AV1 output file seemingly is ok, but there are some CinGG output "FFStream::seek I/O errors, seek fails" I don't know what are !? CinGG (built: Jul 29 2024 01:18:06, rpm on Leap) Render: File Format: FFMPEG | webm Video wrench: Compression: av1.webm (libaom?) | pixels: yuv422p10le Defaults: # this codec codes less than one frame per sec # and so even a few seconds of video can take # a very long time to encode cpu-used 5 row-mt 1 tiles 2x2 strict -2 threads 8 15M av1_yuv422p10le_LP.webm ** rendered 1780 frames in 184.787 secs, 9.633 fps FFMPEG::open_decoder: some stream times estimated: /run/media/terje/Videoklipp/Cineform/av1_yuv422p10le_LP.webm FFMPEG::open_decoder: some stream times estimated: /run/media/terje/Videoklipp/Cineform/av1_yuv422p10le_LP.webm FFStream::seek: /run/media/terje/Videoklipp/Cineform/av1_yuv422p10le_LP.webm retry limit, pos=207 tstmp=8280, err: Input/output error ** seek fail 207, 8280 .....snip FFStream::seek: /run/media/terje/Videoklipp/Cineform/av1_yuv422p10le_LP.webm retry limit, pos=87 tstmp=3480, err: Input/output error ** seek fail 87, 3480 Verificated the output file with FFprobe: ffprobe -hide_banner av1_yuv422p10le_LP.webm Input #0, matroska,webm, from 'av1_yuv422p10le_LP.webm': Metadata: ENCODER : Lavf61.1.100 Duration: 00:01:11.16, start: 0.000000, bitrate: 1709 kb/s Stream #0:0: Video: av1 (libdav1d) (Professional), yuv422p10le(pc, bt709/unknown/unknown), 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn Metadata: DURATION : 00:01:11.160000000

3 10

Re: [Cin] Multitrack performance issues
by Stefan de Konink 08 Aug '24

08 Aug '24

Op 7/28/24 om 18:58 schreef Georgy Salnikov: > On Sun, 28 Jul 2024, Stefan de Konink via Cin wrote: > >> In my opinion, Cinelerra must be able to guess this itself. > > Not sure that a software should always pretend to be smarter than the user. > Such a software could become dangerous in some cases... The point remains. Cinerella does composition. In order to do so, it must know which content to place where. Something that is masked by a top layer cannot be seen. This is the basic of composition. So technically; - for every property change compute if the layer fully overlaps the layers below it - this should basically prevent decoding of any further tracks Now the second problem was that the video effect was still executing while it was disabled. I don't know what you think about that, that is just a bug for me. I am aware that not many of you are into multitrack work, and it may never have been a priority upstream. -- Stefan

6 8

New release AppImages with all having x265 10/12 bit encode
by Phyllis Smith 07 Aug '24

07 Aug '24

There are new AppImages at: https://cinelerra-gg.org/download/images/ All of the important changes are incorporated for fc38, suse15, debian11/12, and ubuntu22 at: https://github.com/einhander/cin-gg-packages/releases/tag/20240718 *Andrey*.could you check 20240728 / 20240729 for the ubuntu22 build? Just FYI, because of the time difference 2 of the last GIT change (trivial changes) were done on the 28 of July and the other 2 on the 29 of July (after midnight). ************* Release Notes ***************** *GIT for Cinelerra-GG has the following changes from 07/01/2024-07/31/2024* *Picons for Chromakey Avid and Color Swatch* plugins added to be seen in the Resources window under Video Effects provided by *IgorBeg*. *Chromakey Avid help* with Alt-h when running CinGG has been corrected by *SGE*. Since this affects doc/Context_Manual.pl, anyone who has customized this will have to refer to ~HOME/.bcast5 .bak file to reincorporate their specific changes. *Multibit x265* is now the default build for all appimages which only affects encode for x265 so that now the 10-bit and 12-bit x265 render formats will work. The 8-bit render format (h265.mp4) and other h265 formats that exist should continue to work as before. So there will no longer be a separate AppImage, CinGG_yymmdd-x86_64-multibit.AppImage. If doing your own build and for some reason you prefer not to build with 10 and 12 bit x265, delete thirdparty/src/x265*.patch* before compiling and modify thirdparty/Makefile as described in the Manual. As a side note, you may have to rebuild your video index the first time you use the 10/12 bit render formats, but only if you encounter an error message. Much information and testing was provided by *Terje and Andrea*. *Performance tips from Stefan* have been added to the manual: - when working with multiple tracks containing video at opacity 100%, if you just want to play one track, disable "Play track" in the patchbay for the other tracks. This uses a lot less CPU. - for playing a track that has attached Video Effects you can decrease CPU usage considerably if you temporarily disable the Video Effects. *Manual updates by Andrea* include a number of improvements, additions, and changes.

3 5