- Cin - Cinelerra-GG Mailing Lists

10bit VAAPI encoding preset
by Terje J. Hanssen 13 Nov '24

13 Nov '24

After finishing the three hevc_qsv presets for _8b420, _10b420 and _10b422 mp4 https://lists.cinelerra-gg.org/pipermail/cin/2024-November/009039.html I thought to do the corresponding for hevc_vaapi However I am struggling to get 10bit 422 output rendered from Cingg, which so far falls back to 10bit 420 chroma subsampling fprobe -hide_banner hd01_hevc_vaapi_10b422.mp4 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) In a previous thread I proved that ffmpeg hevc_vaapi encoding has this 10bit-422 capability 3) 10-bit yuv422p10le hevc_vaapi encoding using -vf 'format=y210,hwupload' https://lists.cinelerra-gg.org/pipermail/cin/2024-November/008982.html And yes, there was also issues before hevc_qsv_10b422.mp4 combinations Pixel format/profile finally succeeded. But here are some differences, yet. While hevc_qsv provided a Pixels drop down menu with pixel formats, hevc_vaapi just has a single "vaapi" pixel format. Any idea why, and what can fulfill the vaapi 10bit 422 encoding here?

3 8

10bit VAAPI encoding test thread continued
by Terje J. Hanssen 13 Nov '24

13 Nov '24

Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html Den 27.10.2024 21:11, skrev Terje J. Hanssen: > ........snip > > For me it looks like nothing has changed: > > localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch > fatal: previous rebase directory .git/rebase-apply still exists but > mbox given. > > > remove it again? > > > By the way,testing > > bin/cin > compression: hevc_vaapi.mp4 > Pixels: vaapi (no other options) > cin_hw_dev=vaapi > > Renders > > Color space : YUV > Chroma subsampling : 4:2:0 > Bit depth : 8 bits > > > The same with > CIN_10BIT_ENC=1 bin/cin > > > > yeah, it does not exist in normal cin, only after you add patch. > > > may be just take a break from all this, I do not think we will solve > this problem in few remaining days until end of October. So ... do > not rush > > Ok for me. > Den 04.11.2024 21:49, skrev Andrew Randrianasulu: > > Terje, I think if you are ok with this idea we can return to testing > 10bit-vaapi patch ... > Hopefully in its final form it will just allow same format= string in > encoding profiles as supported by per-file decoding opts files now ,,, > I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow. ==================== Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?

3 35

FFmpeg supported QSV pixel formats and profiles
by Terje J. Hanssen 11 Nov '24

11 Nov '24

An overview over the system FFmpeg 7.1 supported QSV pixel formats and profiles: ffmpeg -hide_banner -encoders | grep qsv V..... av1_qsv AV1 (Intel Quick Sync Video acceleration) (codec av1) V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264) V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc) V..... mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration) (codec mjpeg) V..... mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video) V..... vp9_qsv VP9 video (Intel Quick Sync Video acceleration) (codec vp9) ffmpeg -hide_banner -h encoder=av1_qsv | egrep 'Supported|profile|main|high|professional' Supported hardware devices: qsv qsv qsv Supported pixel formats: nv12 p010le qsv -profile <int> E..V....... (from 0 to INT_MAX) (default unknown) main 1 E..V....... ffmpeg -hide_banner -h encoder=hevc_qsv | egrep 'Supported|profile|main|high|professional' Supported hardware devices: qsv qsv qsv Supported pixel formats: nv12 p010le p012le yuyv422 y210le qsv bgra x2rgb10le vuyx xv30le -profile <int> E..V....... (from 0 to INT_MAX) (default unknown) main 1 E..V....... main10 2 E..V....... mainsp 3 E..V....... -tier <int> E..V....... Set the encoding tier (only level >= 4 can support high tier) (from 0 to 256) (default high) main 0 E..V....... high 256 E..V....... ffmpeg -hide_banner -h encoder=h264_qsv | egrep 'Supported|profile|main|high|professional' Supported hardware devices: qsv qsv qsv Supported pixel formats: nv12 qsv -profile <int> E..V....... (from 0 to INT_MAX) (default unknown) main 77 E..V....... high 100 E..V.......

2 7

Where are Cingg's ffmpeg compression files located?
by Terje J. Hanssen 08 Nov '24

08 Nov '24

During render testing to and fro, I have had a suspect that now and then the content of ffmpeg compression type has changed or could not be picked up again. But I have thought it was me that had confused or forgot something. Or may this occur by other reasons? Seemingly this happened recently during render switching between hevc_vaapi,mp4 and hevc_qsv.mp4 . hevc_qsv.mp4 has several more pixel options than hevc_vaapi.mp4 which has only the single "vaapi" option. And in one occasion I got more pixel options for hevc_vaapi.mp4(?) - or was it still on hevc_qsv,mp4? So to find out, I have tried to edit the hevc_vaapi.mp4 file, but have not got the edited content loaded in the video wrench compression window. So I wonder where is the preset file used by Cingg located? I have # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1 and the hevc_vaapi.mp4 preset file with the same content located in both /Cin/bin/ffmpeg/video /Cin/ffmpeg/video But the edited content isn't visible in Cingg?

2 7

Enable Cingg single-user build to use system libSvtAv1Enc upgraded to v. 2.3.0
by Terje J. Hanssen 07 Nov '24

07 Nov '24

I upgraded my system Slowroll to S | Name | Type | Version | Arch | Repository ---+---------------------+---------+--------------------------------+--------+---------------------- i+ | libSvtAv1Enc2 | package | 2.3.0-1.5 | x86_64 | obs:multimedia:libs i+ | SVT-AV1 | package | 2.3.0-1.5 | x86_64 | obs:multimedia:libs Version test: # SvtAv1EncApp Svt[info]: ------------------------------------------- Svt[info]: SVT [version]: SVT-AV1 Encoder Lib v2.3.0 Svt[info]: SVT [build] : GCC 14.2.1 20241007 [revision 4af44f2cf7d281f3e4f3957efce10e8b2ccb2ad3] 64 bit Svt[info]: LIB Build date: Oct 29 2024 22:11:44 Svt[info]: ------------------------------------------- File list for rpm -ql libSvtAv1Enc2 /usr/lib64/libSvtAv1Enc.so.2 /usr/lib64/libSvtAv1Enc.so.2.3.0 /usr/share/licenses/libSvtAv1Enc2 /usr/share/licenses/libSvtAv1Enc2/LICENSE.md /usr/share/licenses/libSvtAv1Enc2/PATENTS.md I tested first that SVT-AV1 v. 2.3.0 encoding worked OK with my existing system ffmpeg v. 7.1 I'm not sure I ever have tested av1_svt rendering with my single-user build Cingg before now. But when I tried now to render the same hdv file as with ffmpeg, Cingg failed with int FFMPEG::open_encoder(const char*, const char*): cant find codec libsvtav1:/Videoklipp/AV1/hdv09_04_m2t_svt-av1_230.webm Shouldn't Cingg be able to work with the system upgraded libSvtAv1Enc2 v. 2-3-0 automatically as well as ffmpeg does? Or if necessary via a simple "update", without complete rebuild? ------------- I had a look at my last rebuild of Cingg for using ffmpeg 7.1 : Does "disabled libsvtav1" say something? # ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx configure: loading site script /usr/share/site/x86_64-pc-linux-gnu ..........snip checking for /usr/local/cuda/include/cuda.h... no checking cuda sdk... no checking for dlopen in -ldl... yes checking for numa_alloc in -lnuma... yes checking for openexr available... yes Reason Package ------ ------- disabled encore disabled audiofile disabled esound disabled libsvtav1 ...snip...

2 4

New SVT-AV1 release: v2.3.0 from AOM
by Terje J. Hanssen 05 Nov '24

05 Nov '24

As seen on reddit, the Alliance for Open Media - AOM has released SVT-AV1 v. 2.3.0 The Scalable Video Technology for AV1 (SVT-AV1 Encoder) is an AV1-compliant software encoder library. * NEW FAST DECODE MODE * New fast-decode (2) to allow for an average AV1 software cycle reduction of 25-50% vs fast-decode 0 with a 1-3% BD-Rate loss across the presets * Improved fast-decode (1) option to increase its AV1 software cycle reduction by ~10% while maintaining the same quality levels * Improved --lp settings for high resolutions, with CRF gaining a ~4% improvement in speed and VBR gaining ~15% * Further Arm-based optimizations improving the efficiency of previously written Arm-neon implementations by an average of 30% * Address speed regressions for high resolutions first pass encode by tuning the threading parameters, with 1080p showing the biggest gains * Enabled AVX512 by default in cmake allowing for ~2-4% speedup * ...and more https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v2.3.0#230---2024-10-28 https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/README.md?ref_type=he…

3 5

VAAPI supported Encoding formats
by Terje J. Hanssen 03 Nov '24

03 Nov '24

In hope it may be of some use for Cingg next, I make a summary and supplement to the guide in https://trac.ffmpeg.org/wiki/Hardware/VAAPI#Encoding And instead of adding a tail to already too long recent threads, I start a new thread here. Two additional references are used Developer Reference: Media Capabilities Supported by Intel Hardware https://www.intel.com/content/www/us/en/docs/onevpl/developer-reference-med… Supported Encoding Input Format and Max Resolution https://github.com/intel/media-driver/blob/master/docs/media_features.md#su… to clarify the Encode Features for my own Intel Arc A-series Discrete Graphics HEVC (fixed-function hardware + shader-based) 8-bit, 4:2:0 (NV12) 10-bit, 4:2:0 (P010) 8-bit, 4:2:2 (YUY2, Windows only) 10-bit, 4:2:2 (Y210) AV1 8-bit, 4:2:0 (NV12) 10-bit, 4:2:0 (P010) A short reminder: 8-bit vs 10-bit color depths is 256 vs 1024 color levels of each RGB color, or 16.7 mill. vs 1.0 bill colors. 4:2:0 vs 4:2:2 color sub-sampling is keeping 1/4 vs 1/2 of all 4:4:4 colors or the precision of color compression. https://fujifilm-x.com/en-us/series/the-filmmakers-handbook/8-bit-or-10-bit… An important point to notice is that the VAAPI encoding 'formats' are based on those in the parentheses () above. Three simplified ffmpeg code lines with default bit-rates and without audio are used in the following three examples. Resulting fps encoding counts or speeds are the same in all cases; I don't know why. The input file used: ffprobe -hide_banner cfhd01.mkv Input #0, matroska,webm, from 'cfhd01.mkv': Metadata: ENCODER : Lavf61.1.100 Duration: 00:01:11.24, start: 0.000000, bitrate: 393480 kb/s Stream #0:0(eng): 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) Metadata: HANDLER_NAME : Apple Video Media Handler VENDOR_ID : appl ENCODER : Lavc61.3.100 cfhd DURATION : 00:01:11.240000000 1) 8-bit yuv420p hevc vaapi encoding using -vf 'format=nv12,hwupload' ------------------------------------------------------------------ ffmpeg -hide_banner -vaapi_device /dev/dri/renderD128 -i cfhd01.mkv -vf 'format=nv12,hwupload' -c:v av1_vaapi cfhd01_av1_vaapi_format_nv12.mp4 ............ frame= 1781 fps= 46 q=-0.0 Lsize= 104132KiB time=00:01:11.24 bitrate=11974.3kbits/s speed=1.83x ffprobe -hide_banner cfhd01_av1_vaapi_format_nv12.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_av1_vaapi_format_nv12.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomav01iso2mp41 encoder : Lavf61.7.100 Duration: 00:01:11.24, start: 0.000000, bitrate: 11974 kb/s Stream #0:0[0x1](eng): Video: av1 (libdav1d) (Main) (av01 / 0x31307661), yuv420p(tv, bt709, progressive), 1920x1080, 11973 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : Apple Video Media Handler vendor_id : [0][0][0][0] encoder : Lavc61.19.100 av1_vaapi 2) 10-bit yuv420p10le hevc vaapi encoding using -vf 'format=p010,hwupload' ----------------------------------------------------------------------- ffmpeg -hide_banner -vaapi_device /dev/dri/renderD128 -i cfhd01.mkv -vf 'format=p010,hwupload' -c:v av1_vaapi cfhd01_av1_vaapi_format_p010.mp4 ............. frame= 1781 fps= 46 q=-0.0 Lsize= 111924KiB time=00:01:11.24 bitrate=12870.3kbits/s speed=1.82x ffprobe -hide_banner cfhd01_av1_vaapi_format_p010.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_av1_vaapi_format_p010.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomav01iso2mp41 encoder : Lavf61.7.100 Duration: 00:01:11.24, start: 0.000000, bitrate: 12870 kb/s Stream #0:0[0x1](eng): Video: av1 (libdav1d) (Main) (av01 / 0x31307661), yuv420p10le(tv, bt709, progressive), 1920x1080, 12869 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : Apple Video Media Handler vendor_id : [0][0][0][0] encoder : Lavc61.19.100 av1_vaapi 3) 10-bit yuv422p10le hevc_vaapi encoding using -vf 'format=y210,hwupload' ----------------------------------------------------------------------- ffmpeg -hide_banner -vaapi_device /dev/dri/renderD128 -i cfhd01.mkv -vf 'format=y210,hwupload' -c:v hevc_vaapi cfhd01_hevc_vaapi_format_y210.mp4 frame= 1781 fps= 46 q=-0.0 Lsize= 105482KiB time=00:01:11.20 bitrate=12136.3kbits/s speed=1.83x ffprobe -hide_banner cfhd01_hevc_vaapi_format_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_format_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.7.100 Duration: 00:01:11.24, start: 0.000000, bitrate: 12129 kb/s Stream #0:0[0x1](eng): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 12127 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : Apple Video Media Handler vendor_id : [0][0][0][0] encoder : Lavc61.19.100 hevc_vaapi

3 5

New October 2024 AppImages ready
by Phyllis Smith 31 Oct '24

31 Oct '24

The October 2024 AppImages are now available at: https://cinelerra-gg.org/download/images/CinGG-20241031-x86_64.AppImage https://cinelerra-gg.org/download/images/CinGG-20241031-x86_64-older-distro… https://cinelerra-gg.org/download/images/CinGG-20241031-alternative_shortcu… https://cinelerra-gg.org/download/images/CinGG-20241031-i386-newer_distros.… https://cinelerra-gg.org/download/images/CinGG-20241031-i386.AppImage *The preferred releases,* if you have newer versions of Suse, Ubuntu, Debian, and Fedora Operating Systems because of the flexibility, are Andrey's packages which were already up to date on October 30. They are at: https://github.com/einhander/cin-gg-packages/releases Nothing dramatic in this release - just 4 library upgrades to get updated. *GIT for Cinelerra-GG has the following changes from 10/01/2024-10/31/2024* *Library Upgrades:* X265 has been updated to the latest September release of 4.0 Libvpx for vp8/vp9 is now at version 1.14.1 from previous release of 1.13.1. Libwebp has been upgraded from 1.3.2 to 1.4.0. Libjpeg-turbo is now at version 3.0.4 from previous 2.1.5.1. To improve in-tree documentation, *Andrew* added files Description and Bugs to main cinelerra-5.1 directory and updated README.

2 1

QSVEnc to investigate HW encoder - Intel System Support Utility
by Terje J. Hanssen 31 Oct '24

31 Oct '24

QSVEnc is meant to investigate performance and image quality of HW encoder (QSV) of Intel. There are build packages for Fedora and Ubuntu, but it is missing for openSUSE/Slowroll. https://github.com/rigaya/QSVEnc/releases https://github.com/rigaya/QSVEnc/tree/master?tab=readme-ov-file#readme https://github.com/rigaya/QSVEnc/blob/master/Install.en.md There is also another tool, Intel System Support Utility for the Linux (and Windows) Intel SSU for the Linux operating system is a standalone utility that performs a detailed scan and report of the computer system information to assist you with customer support troubleshooting. Intel SSU for Linux produces an output file that can be saved, viewed and shared by the user. https://www.intel.com/content/www/us/en/download/18895/26735/intel-system-s…

1 1

I tried to improve in-tree documentation
by Andrew Randrianasulu 29 Oct '24

29 Oct '24

Changed README so it reflect current way of building system/single-user builds, hopefully added BUGS with entry that bit me recently added DESCRIPTION based on slack-desc, empathizing we can do rgba32f

2 2