July 2024 - Cin - Cinelerra-GG Mailing Lists

FranceBB's LUT collection
by Andrew Randrianasulu 16 May '25

16 May '25

forum https://forum.doom9.org/showthread.php?t=176091 it says those LUTs should be usable for ffmpeg's lut3d and therefore for CinGG? github (each *.cube can be several mb's big) https://github.com/FranceBB/LinearTransformation author says they were verified on professional equipment... list includes PAL and NTSC variants for rec. 601....

3 6

I tried to add AVC-Intra 100 output profiles
by Andrew Randrianasulu 08 May '25

08 May '25

But not sure if I did this correctly. https://en.wikipedia.org/wiki/AVC-Intra says for AVC-Intra 100: AVC-Intra 100: nominally 100 Mbit/s, size of each frame is fixed CAVLC entropy coding only. All formats are High 4:2:2 Intra Profile, Level 4.1 4:2:2 chrominance sampling frames are not scaled and yeah, this French-language pdf actually says the same: https://web.archive.org/web/20110720215759/http://www.ficam.fr/upload/docum… 50M 100M Standard MPEG-4 part10 AVC/H.264 Profile High 10 Intra High 4:2:2 Intra Level Level 3.2/4.0 Level 4.1 Resolution 1440x1080 / 960x720 1920x1080 / 1280x720 Sampling 4:2:0 4:2:2 Bit rate 54Mbps 111Mbps Block size Y: 8x8, C: 4x4 Intra Prediction Y: 9mode, C: 4mode MBAFF Yes De-block filter No Slice/frame 10 Entropy coding CABAC CAVLC so, I looked up ffmpeg cmd line https://trac.ffmpeg.org/ticket/3597 ffmpeg -v info -i /mnt-data/backup4/vol0/export/CUHK\ 2014-1/V017b.mov -vcodec libx264 -intra -pix_fmt yuv422p10le -vb 100M -x264opts avcintra-class=100 -x264opts colorprim=bt709 -x264opts transfer=bt709 -x264opts colormatrix=bt709 -threads 4 -acodec copy V017b-ffmpeg-git-avcintra100.mov Huh, said I and entered those params in opts file, actually in two files (mp4 and mov containers) mov libx264 cin_pix_fmt=yuv422p10le flags -global_header keyint_min=0 x264-params=keyint=0:colorprim=bt709:transfer=bt709:colormatrix=bt709 avcintra-class=100 bufsize=100000000 level=4.1 mp4 libx264 cin_pix_fmt=yuv422p10le flags -global_header keyint_min=0 x264-params=keyint=0:colorprim=bt709:transfer=bt709:colormatrix=bt709 avcintra-class=100 bufsize=100000000 level=4.1 both for progressive content, for interlace you must add some more flags: https://lists.ffmpeg.org/pipermail/ffmpeg-user/2017-January/035049.html -flags +ildct+ilme -x264opts interlaced=1 Also, there is still lack of (GUI) user notification if file writing failed due to NO SPACE on device :} FFStream::write_packet: write packet failed. file:/dev/shm/avci_new.mp4 err: На устройстве не осталось свободного места FFStream::encode_frame: encode failed. file: /dev/shm/avci_new.mp4 err: На устройстве не осталось свободного места FFStream::flush failed :file:/dev/shm/avci_new.mp4 err: Операция не позволена Render::render_single: Session finished. ** rendered 273 frames in 85.585 secs, 3.190 fps Render::render_single: Session finished. ** rendered 273 frames in 85.485 secs, 3.194 fps Render::render_single: Session finished. ** rendered 273 frames in 82.176 secs, 3.322 fps Profile sort of assumes you set project to some supported resolution, framerate, etc, otherwise libx264 will fail with console error message..... I found some talk about AVC-Ultra, there even was patch for x264, but it was not merged: https://mailman.videolan.org/pipermail/x264-devel/2015-September/011412.html Also, I think sound must be uncompressed, but I'm not sure.

2 5

Multitrack performance issues
by Stefan de Konink 26 Sep '24

26 Sep '24

I think have a significant opportunity to improve the Cinerella performance, under normal editing conditions, by n_videotracks-fold. At this point in time I notice that the CPU usage (decoding) for a section where multiple tracks are stacked, but only the top one is actually on screen (read opacity 100%) could be improved. I observe the following: - for a disabled video effect, the CPU still runs - for stacked video, the CPU still runs for both videos - the effect must be detached and the video below must have play track disabled to prevent the CPU to go from 20% to 150% - this is independent of colourspace (RGB, RGBA, YUV or YUVA) -- Stefan

3 6

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

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

How to identify if a running CinGG is the Regular or Multibit version?
by Terje J. Hanssen 22 Jul '24

22 Jul '24

Previously package installations used /usr/bin/cin to start the Regular version vs /usr/bin/cinx for the 10-bit version (rpm on openSUSE). Now the Appimage name itself contains Multibit for the latter. But for a running CinGG system, "Settings > Preferences | About contains" Built date and time and libav version It seems as nothing here tells if it is the regular or multibit version running, or? Will it be possible to add the version info here? Terje

5 46