- Cin - Cinelerra-GG Mailing Lists

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

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

with-cuda errors
by Stefan de Konink 21 Jul '24

21 Jul '24

Hi, Is there anyone here that is capable of compiling cingg --with-cuda with a recent cuda version? renders.C:1:10: fatal error: 5_Simulations/nbody/render_particles.cpp: No such file or directory 1 | #include "5_Simulations/nbody/render_particles.cpp" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ nbody.h:30:10: fatal error: 5_Simulations/nbody/bodysystemcuda.h: No such file or directory 30 | #include <5_Simulations/nbody/bodysystemcuda.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Stefan

2 1

New release update
by Phyllis Smith 19 Jul '24

19 Jul '24

October 2022 end of month new release AppImages now available. This includes a fix for a minor ffmpeg 5.1 security flaw that Andrew discovered and made us a patch for. Full release notes at: https://cinelerra-gg.org/download/releasenotes.pdf . ************ October Release Notes update ****************** *Security flaw in FFmpeg 5.1* was discovered and Andrew forwarded the patch for us to use. A *Direct Copy speed-up* has been added for EXR and PPM sequences that Andrew found. Tiny corrections and addition to Cinelerra_factory presets and plugin.opts. Newer versions of Ubuntu require an additional package install for *bld_prepare.sh as Goat found*. The Manual has had another section added, *Alternative Views of Overlay Modes*, which presents a more “real world” usage display of the overlay modes using a color/black & white gradient + video.

6 37

opencolorio c++ examples
by Andrew Randrianasulu 18 Jul '24

18 Jul '24

I looked at https://opencolorio.readthedocs.io/en/latest/guides/developing/usage_exampl… and well, few calls for basic colorspace transform in c++ is not very bad, but of course even with this easy way I still not quite understand where we (cinelerra's) should put this call? At (ffmpeg) decode/encode step? At display step? ===== Applying a basic ColorSpace transform, using the CPU This describes what code is used to convert from a specified source ColorSpace to a specified destination ColorSpace. If you are using the OCIO Nuke plugins, the OCIOColorSpace node performs these steps internally. Get the Config. This represents the entirety of the current color “universe”. It can either be initialized by your app at startup or created explicitly. In common usage, you can just query GetCurrentConfig(), which will auto initialize on first use using the OCIO environment variable. Get Processor from the Config. A processor corresponds to a ‘baked’ color transformation. You specify two arguments when querying a processor: the colorspace_section you are coming from, and the colorspace_section you are going to. cfgcolorspaces_section ColorSpaces can be either explicitly named strings (defined by the current configuration) or can be cfgroles_section (essentially colorspace_section aliases) which are consistent across configurations. Constructing a Processor object is likely a blocking operation (thread-wise) so care should be taken to do this as infrequently as is sensible. Once per render ‘setup’ would be appropriate, once per scanline would be inappropriate. Get a CPU or GPU Processor. Building the processor assembles the operators needed to perform the requested transformation, however it is not ready to process pixels. The next step is to create a CPU or GPU processor. This optimizes and finalizes the operators to produce something that may be executed efficiently on the target platform. Convert your image, using the Processor. Once you have a CPU or GPU processor, you can apply the color transformation using the “apply” function. In C++, you may apply the processing in-place, by first wrapping your image in an ImageDesc class. This approach is intended to be used in high performance applications, and can be used on multiple threads (per scanline, per tile, etc). In Python you call “applyRGB” / “applyRGBA” on your sequence of pixels. Note that in both languages, it is far more efficient to call “apply” on batches of pixels at a time. =====

1 0