- Cin - Cinelerra-GG Mailing Lists

SVT-AV1 library upgraded to v2.2.1
by Phyllis Smith 18 Sep '24

18 Sep '24

The SVT-AV1 library was at version 1.8.0 and finally I got it upgraded and checked into GIT. At first I had to figure out what I was doing wrong in upgrading to 2.1.2, but by the time I figured that out, they released a new version on Aug. 24 (2.2.1). Encoding seems to be somewhat faster. Previously on Aug. 16, GIT checkin was for the latest version of dcraw dated 2018, giflib 5.2.2, and flac 1.4.3 which may not have been recent updates but were the latest available -- might as well use the latest even if no significant changes. I am still checking to make sure we have the latest libraries in use for the other ones so do not plan on creating a release on Aug. 31 -- especially since SVT-AV1 version is so new and I only did a cursory test. Hopefully, Terje can check using the SUSE package at: https://github.com/einhander/cin-gg-packages/releases/ when it has been newly built.

4 23

MTS files; concat demuxer / protocol
by Stefan de Konink 18 Sep '24

18 Sep '24

There are quite some topics online mentioning the when MTS files (exceeding 2GB) are naively added to a timeline. The problem that then appears is that the audio is typically "shorter" than the video, and it does not appear in the interface. Cinelerra will even shift the audio track under the previous track. It is mentioned that Adobe Premiere is able to parse an AVCHD structure, including the ability to use meta information such as timecode, which is not available from MTS files directly. Other workarounds that are mentioned to first join the MTS files. FFmpeg has the option concat demuxer and concat protocol. But it pulls another surprise... ffmpeg -i "concat:00152.MTS|00153.MTS|00154.MTS" -vcodec copy -acodec copy test.ts ffmpeg version n7.0.1 Copyright (c) 2000-2024 the FFmpeg developers built with gcc 14.1.1 (GCC) 20240522 configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-mbedtls --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-vapoursynth --enable-version3 --enable-vulkan libavutil 59. 8.100 / 59. 8.100 libavcodec 61. 3.100 / 61. 3.100 libavformat 61. 1.100 / 61. 1.100 libavdevice 61. 1.100 / 61. 1.100 libavfilter 10. 1.100 / 10. 1.100 libswscale 8. 1.100 / 8. 1.100 libswresample 5. 1.100 / 5. 1.100 libpostproc 58. 1.100 / 58. 1.100 Input #0, mpegts, from 'concat:00152.MTS|00153.MTS|00154.MTS': Duration: 00:25:04.36, start: 1.040000, bitrate: 24022 kb/s Program 1 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn Stream #0:1[0x1100]: Audio: pcm_bluray (HDMV / 0x564D4448), 48000 Hz, stereo, s16, 1536 kb/s Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle (pgssub) ([144][0][0][0] / 0x0090), 1920x1080 File 'test.ts' already exists. Overwrite? [y/N] y Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (copy) Output #0, mpegts, to 'test.ts': Metadata: encoder : Lavf61.1.100 Stream #0:0: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 25 fps, 25 tbr, 90k tbn Stream #0:1: Audio: pcm_bluray (HDMV / 0x564D4448), 48000 Hz, stereo, s16, 1536 kb/s Press [q] to stop, [?] for help [mpegts @ 0x600ed54cf540] Stream 1, codec pcm_bluray, is muxed as a private data stream and may not be recognized upon reading. This results in a video file cinelerra (and others) cannot read. Instead if we would say do it in pcm_sb16le we would be able to show that the MTS file does contain the audio and FFmpeg is able to read it. I have attached a screenshot showing what happens. I wonder: could we in Cinelerra implement something that would not open a file as single file or EDL, but instead a concat set of files? Something in the drop down: "Create a single new resource only". That single resource should be opened via the concat protocol, and then be able as single instance. An EDL, but then at protocol level. I think this would make sense for many recordings that are split due to filesystem limits, but even for image sequences, if they could be directly opened and edited as if they were single files. -- Stefan

3 6

Library x264 updated in GIT
by Phyllis Smith 18 Sep '24

18 Sep '24

X264 was at release r3106 of January 2023 and now is at r3191 of May 2024. Expect Andrey's packages soon with updates at: https://github.com/einhander/cin-gg-packages/releases Andrea, if you have time could you rebuild just to get a little use out of it before the end of the month build?

2 1

patch to show transfer characteristics and primaries in ffmpeg details
by Andrew Randrianasulu 17 Sep '24

17 Sep '24

please test

2 2

Surprizes in YUV->RGB conversion
by Andrew Randrianasulu 15 Sep '24

15 Sep '24

I was using artificial test source from ffmpeg, yuvtestsrc. It sounds very simple ffmpeg -f lavfi -color_range 2 -i yuvtestsrc -color_range 2 -frames 2 /dev/shm/yuv-pc-yuv444.y4m but here lies dragons, at least when roundtrip to RGB is needed. This old BBC article explained to me for the first time that YUV as color space fundamentally bigger than RGB! https://web.archive.org/web/20200719051405/http://downloads.bbc.co.uk/rd/pu… By way stuff defined normal calculations can give you negative RGB values! An normally those are clipped to either min or max allowed channel value. But result is ...unintuitive, at least for me Here is online calculator: https://kdashg.github.io/misc/colors/from-coeffs.html if you enter RGB 601, narrow range Y=16, Cb=100 Cr=100 R=-44.68875 (minus 44!) G=33.73244 B=-56.4825 (minus 56!) so, if both negative channels will be clipped to 0 we will have visually purely green pixel ?! This probably explains some STRANGE results I was seeing in compositor and vectoroscope, because even if timeline set to YUV- for display values converted to RGB, and scope also works in RGB ? There was another patent paper from broadcom aimed at fixing this issue https://patents.google.com/patent/EP1560417A2/en "System and method for clipping values of pixels in one color space so not to exceed the limits of a second color space Abstract A system and method that detects when pixels from one color space would exceed the range of a second color space, and restrict the range of the pixels without distorting their brightness, while preserving their color. The method may provide the ability to restrict the range of pixels in the first color space that may ordinarily transform to "illegal" values with erroneous brightness in the second color space, to a sub-space containing the entire second color space, while preserving the brightness of the pixels. The parameters used to define the sub-space may be programmable. The first color space may be YCrCb and the second color space may be RGB." ===== so, while in theory this problem is combatable in practice I do not think we have any out of the box plugin for dealing with this? So .... back to hunting for relevant test image, may be rgbtestsrc stored as y4m will do?

1 0

Another book on digital video
by Andrew Randrianasulu 15 Sep '24

15 Sep '24

Digital video and HD (2012) https://wangwei1237.github.io/shares/Digital_Video_and_HD_Algorithms_and_In… nearly 40 mb, 753 pp! found via https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=78837 not sure if I'll learn enough for stopping confusing color spaces vs primaries and so on ......

4 6

possible typo in documentation?
by Andrew Randrianasulu 15 Sep '24

15 Sep '24

https://cinelerra-gg.org/download/CinelerraGG_Manual/YUVShift.html === This effect is used for YUV input video from older cameras using 3 sensors. It is possible to have misalignment of the 3 sets of numbers: Y, which represents the luminance or brightness component, and for U and V representing the chrominance (color) components. If they were misaligned in the video, you can use YUVShift to realign. To move a specific component up/down, modify the dy value using the slider bar in the RGBShift window. === I think here specifically it must say YUVShift?

2 1

Hardware acceleration methods
by Terje J. Hanssen 15 Sep '24

15 Sep '24

The CinGG manual mentions VAAPI and VDPAU. https://cinelerra-gg.org/download/CinelerraGG_Manual/Hardware_video_acceler… https://cinelerra-gg.org/download/CinelerraGG_Manual/GPU_hardware_encoding.… My prebuild system FFmpeg lists ffmpeg -hide_banner -hwaccels Hardware acceleration methods: vdpau cuda vaapi qsv drm vulkan Among these, Vulkan has recently been discussed here. Is there something that prevent typical QSV to be prebuilt in the CinGG/FFmpeg rpm? References: Compiling FFmpeg with QSV on Linux Intel Platform: https://www.intel.com/content/www/us/en/content-details/728030/building-ffm… Arc: Intel QuickSync (QSV): https://wiki.archlinux.org/title/FFmpeg#Intel_QuickSync_(QSV) refer

3 6

cingg hevc_vaapi rendering on Arc A750 gpu
by Terje J. Hanssen 15 Sep '24

15 Sep '24

Two simple tests I got working Cinelerra Infinity - built: Sep 8 2024 10:37:25 (rpm installation) on Leap 15.6 on i7-12700KF + Arc A750 gpu As seen below, quite fast rendering: * 207 fps for hdv.m2t (yuv420p) input -> yuvj420p * 125 fps for proreshq.mov (yuv422p10le) -> yuvj420p (10-bit to 8-bit color depth) 1) hdv.m2t Stream #0:0[0x810]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709, top first), 1440x1080 [SAR 4:3 DAR 16:9], 25000 kb/s, 25 fps, 25 tbr, 90k tbn Side data: cpb: bitrate max/min/avg: 25000000/0/0 buffer size: 7340032 vbv_delay: N/A Stream #0:1[0x814]: Audio: mp2 (mp3float) ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 384 kb/s -> hevc_vaapi.mp4 ** rendered 5972 frames in 28.721 secs, 207.931 fps audio0 pad 64 0 (64) tream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuvj420p(pc, bt709/unknown/unknown, top coded first (swapped)), 1440x1080 [SAR 4:3 DAR 16:9], 11716 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 129 kb/s (default) 2) hd.mov Stream #0:0[0x1](eng): Video: prores (HQ) (apch / 0x68637061), yuv422p10le(bt709, top coded first (swapped)), 1920x1080, 182130 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 2500 tbn (default) Metadata: creation_time : 2016-02-23T23:49:21.000000Z handler_name : Apple Video Media Handler vendor_id : appl encoder : Apple ProRes 422 (HQ) Stream #0:1[0x2](eng): Audio: pcm_s24le (lpcm / 0x6D63706C), 48000 Hz, 16 channels, s32 (24 bit), 18432 kb/s (default) -> hevc_vaapi.mp4 ** rendered 1781 frames in 14.188 secs, 125.529 fps audio0 pad 128 0 (128) Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuvj420p(pc, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11427 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 16 channels, fltp, 378 kb/s (default)

2 4

xvYCC
by Andrew Randrianasulu 15 Sep '24

15 Sep '24

https://en.m.wikipedia.org/wiki/XvYCC there is another interesting standartized hack for wider-gamut color space ==== The BT.709 YCbCr signal has unused code space, a limitation imposed for broadcasting purposes. In particular only 16-240 is used for the color Cb/Cr channels out of the 0-255 digital values available for 8 bit data encoding. xvYCC makes use of this portion of the signal to store extended gamut color data by using code values 1-15 and 241-254 in the Cb/Cr channels for gamut-extension. ==== not sure how (if at all) ffmpeg supports this, let alone players under Linux ..... https://fanrestore.com/thread-1961-post-85235.html#pid85235 some convolved way via avisynth and x264 (windows by default, but vapoursynth/zscale-enabled ffmpeg exist under linux) === copypasta ===== deleted user Wrote: <https://fanrestore.com/post-70888.html#pid70888>Ok for anyone who's wondering how to encode xvYCC, I might have found out. First, you need to start out with some color space that has a big gamut to begin with. Let's say Rec 2020. It doesn't have to be HDR, you can just do a normal Rec2020 Gamma 2.4. This ensures that your source has all the colors you want to preserve. So work in and/or render out in Rec2020. If you are working in After Effects for example, in 32 bit floating point mode, then your working color space can be Rec709, you just have to set Rec2020 for the output, since the gamut gets preserved thanks to the ability of the 32 bit floating point data to hold negative values. Otherwise you likely have to work immediately in Rec2020. Load your source in AVISynth and perform the following command: Code: z_ConvertFormat(colorspace_op="2020:709:2020:l=>709:xvycc:709:l",pixel_type="YUV444P16") Note that you have to adapt the part before "=>" to your own input. The above example would be for a YUV Rec2020 Gamma 2.4 file with Limited range. The reason I put "709" there is because that's the transfer characteristic for Gamma 2.4. It doesn't look elegant but it works. Now let's say you're encoding straight from a HDR source, then you'd do: Code: z_ConvertFormat(colorspace_op="2020ncl:st2084:2020:l=>709:xvycc:709:l",pixel_type="YUV444P16") This probably isn't a great idea though because converting straight from HDR without any tonemapping will lead to clipped highlights. An alternate approach that would allow for tonemapping: Code: z_ConvertFormat(colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:f",pixel_type="RGBPS") // First convert to linear floating point Rec2020 // Do tonemapping here with whatever method you like. It needs to accept the "RGBPS" color space, which is a 32 bit floating point planar RGB color space. I believe the DGHable functions and such accept that. z_ConvertFormat(colorspace_op="rgb:linear:2020:f=>709:xvycc:709:l",pixel_type="YUV444P16") // Now finally to xvYCC, while preserving as wide of a gamut as possible For these commands to work, you need this plugin: http://avisynth.nl/index.php/Avsresize Now finally, I did a test loading such a script in VirtualDub and encoding to x264 with the internal x264 encoder. I loaded that back into AVISynth and I'm happy to say that the data was preserved. I tested it with some very saturated scenes. So now the data gets preserved, but the player still won't know that it's dealing with xvYCC data. I can't say with 100% certainty that the following will work, but it does produce the proper metadata in the MediaInfo. Simply use the following x264 parameters instead of the usual: Code: --transfer="iec61966-2-4" --colormatrix="bt709" --colorprim="bt709" To my knowledge, colorprim and colormatrix stay the same, but the transfer characteristic is different. When you encode it like this, the resulting file will show "xvYCC" as the Transfer characteristic. I think that should do the trick, but it would take someone with a compatible TV to try. I can definitely see a difference in MPC-HC, however I haven't attempted to verify that it looks "correct". If anyone wants a sample encode with 2 frames (one in xvycc and one in rec709), PM me. It's just 100KB. Note: This will also work with DCI-P3 as the source for example. The only requirement really is that z_ConvertFormat supports the source color space you are feeding into it and you give it the correct info about it. With that said .... now you have no more excuses for not having wide gamut colors in your projects. [image: Wink] These files are compatible with normal Rec709 as far as I know. ==== end of copypaste ====

2 5