- Cin - Cinelerra-GG Mailing Lists

Build fails on termux
by Andrew Randrianasulu 06 Sep '24

06 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 25 Aug '24

25 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 11 Aug '24

11 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 07 Aug '24

07 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 06 Aug '24

06 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

8-bit vs 10-bit 420 and 422 pixel formats
by Terje J. Hanssen 28 Jul '24

28 Jul '24

Usually 8-bit color depth is refered to 420 pixel formats and 10-bit to the higher color quality 422 pixel formats, which sub-sampled keeps respectively 25% and 50% color information, compared with a full 444 format. But what about the "opposite" cases, 10-bit 420 and 8-bit 422 pixel formats? What and when are they used and good for (applications)? For example frame grabbers like my HDMI->USB3 mini capture card, looks to support 'YUY2',' a 8-bit 422 pixel format. And among 8-bit and 10-bit depths, there are 'yuv', 'nv', 'y' and 'p' prefixed pixel formats as well. Querying my system ffmpeg, the following list of 8-bit and 10-bit pixel formats are available: ffmpeg -hide_banner -pix_fmts | grep -E 'yuv42.*8-8-8|yuv42.*10-10-10|nv.*8-8-8|nv.*10-10-10|210' | sort -r -k 5 ----- Pixel formats: I.... = Supported Input format for conversion .O... = Supported Output format for conversion ..H.. = Hardware accelerated format ...P. = Paletted format ....B = Bitstream format FLAGS NAME NB_COMPONENTS BITS_PER_PIXEL BIT_DEPTHS ----- IO... yuv422p 3 16 8-8-8 IO... yuv420p 3 12 8-8-8 IO... nv42 3 24 8-8-8 IO... nv24 3 24 8-8-8 IO... nv21 3 12 8-8-8 IO... nv16 3 16 8-8-8 IO... nv12 3 12 8-8-8 ..... y210be 3 20 10-10-10 ..... nv20le 3 20 10-10-10 ..... nv20be 3 20 10-10-10 IO... yuv422p10le 3 20 10-10-10 IO... yuv422p10be 3 20 10-10-10 IO... yuv420p10le 3 15 10-10-10 IO... yuv420p10be 3 15 10-10-10 IO... y210le 3 20 10-10-10 IO... p210le 3 20 10-10-10 IO... p210be 3 20 10-10-10 The ffmpeg h264 encoder supports the following pixel formats (all): ffmpeg -hide_banner -h encoder=h264 | grep Supported Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le gray gray10le Supported pixel formats: bgr0 bgr24 rgb24 Supported pixel formats: yuv420p yuvj420p Supported pixel formats: nv12 yuv420p Supported hardware devices: cuda cuda Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 bgra rgb0 rgba x2rgb10le x2bgr10le gbrp gbrp16le cuda Supported hardware devices: qsv qsv qsv Supported pixel formats: nv12 qsv Supported hardware devices: vaapi Supported pixel formats: vaapi I have run some rendering tests using some h264 8-bit and 10-bit pixel formats as follows: Cinelerra Infinity - built: Jun 30 2024 08:31:40 Libav version: Lavc61.3.100 Input file: 3,3G cfhd01.mkv Video: cfhd (CFHD / 0x44484643), yuv422p10le(tv, bt709, top coded first (swapped)), 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn (default) Rendered to h264 8bit and 10bit pixel formats: 72M h264_8bit_nv12.mp4 ** rendered 1780 frames in 46.067 secs, 38.639 fps Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 8462 kb/s 72M h264_8bit_yuv420p.mp4 ** rendered 1780 frames in 48.250 secs, 36.891 fps Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 8462 kb/s 83M h264_8bit_yuv422p.mp4 ** rendered 1780 frames in 41.807 secs, 42.577 fps Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuvj422p(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 9683 kb/s 70M h264_10bit_yuv420p10le.mp4 ** rendered 1780 frames in 42.414 secs, 41.967 fps Video: h264 (High 10) (avc1 / 0x31637661), yuv420p10le(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 8213 kb/s 80M h264_10bit_yuv422p10le.mp4 ** rendered 1780 frames in 42.920 secs, 41.473 fps Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 9364 kb/s References: Chroma Subsampling in ffmpeg https://trac.ffmpeg.org/wiki/Chroma%20Subsampling#SettingChromaSubsamplingi… Preferred YUV Formats (Microsoft Windows, Learn) https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-…

1 1

Major Problem with AppImage
by Phyllis Smith 23 Jul '24

23 Jul '24

With AppImage being probably the most prevalent method of executing CinGG, a major problem on Debian Trixie (not yet officially released) has cropped up preventing its usage. Supposedly due to appimage stuff depending on old outdated Fuse2 libraries. Is this my fault for using an older version of Fedora + older Ubuntu and Debian to make the AppImages? I hope MatN can help me get a solution! For details, please refer to: https://www.cinelerra-gg.org/forum/everything-else/appimage-wont-start/#pos… Since I "think" most other Operating System distros are based on Debian, this will be a problem for all new releases?

6 15

Trivial feature, saves big problems (offset)
by Stefan de Konink 22 Jul '24

22 Jul '24

I remember that someone mentioned this issue before, after I reported it some while back. I think I would love to have the option to *disable* the per track offset. It is crazy how a single scroll wheel move can completely and invisible break a project. If Settings > Allow track offset change would be available that would save considerable time in the future. Since this hunts me, now multiple times, I might give it a shot. -- Stefan

1 0