As Terje suggested below ("Therefore I suggest that the Cingg preset make use of the same SVT-AV1 defaults, to avoid confusing."), I modified and tested the render format av1_svt.webm to be as follows.

File contents of cinelerra-5.1/ffmpeg/video/av1_svt.webm
webm libsvtav1
# If you do not want 10 bit, switch pixel_format
#   to yuv420p which is standard 8 bit.
crf = 35
preset = 6
pixel_format = yuv420p10le

As long as no one objects, I will check this into GIT later.

What confuse me more, is that Cingg rendering seems out of proportion 2.5x faster than corresponding transcoding the same hdv file using ffmpeg directly. Possibly Cingg calculates the speed after loading the input file, and ffmpeg not(?)

hdv09_04.m2t --> hdv09_04_m2t_svt-av1-220_pr6+opus.webm
CinGG:  **rendered 5972 frames in 34.052 secs, 175.379 fps
FFmpeg: frame= 5963 fps= 69 q=35.0 Lsize=  121908KiB time=00:03:58.77 bitrate=4182.4kbits/s speed=2.77x
Here is the FFmpeg command line I use, which also out some mpeg2 errors:
ffmpeg -hide_banner -i hdv09_04.m2t -c:v libsvtav1 -preset 6 -crf 35 -c:a libopus hdv09_04_m2t_ffmpeg-7_svt-av1-221_pr6+opus.webm

you can try to add same parameters to av1 profile?

-preset 6 -crf 35

just without "-" and as two lines ...? (commented-out params use preset 6/crf 25 - you probably can uncomment and edit second param too)

Thank you. Yes, with parameters "preset 6" and "crf 35" the Cingg/FFmpeg rendering speed matched:
Cingg: ** rendered 5972 frames in 84.437 secs, 70.727 fps
At first I wondered if perhaps different CPU core utilization had been used above. I verified now with top that Cingg used CPU 1400-1500% on a 12-core (8-mt/4-st) model: 12th Gen Intel Core i7-12700KF.

I also had a look back into our January conversation about SVT-AV1 parameters. As already seen above, Cingg output what I think are SVT-AV1 defaults
Svt[info]: SVT [config]: BRC mode / rate factor                 : CRF / 35 
Therefore I suggest that the Cingg preset make use of the same SVT-AV1 defaults, to avoid confusing.

Another suggestion from the Simple SVT-AV1 Beginner guide, is to always use 10-bit encoding:
https://gist.github.com/BlueSwordM/86dfcb6ab38a93a524472a0cbe4c4100
  • I always recommend to use 10-bit (-pix_fmt yuv420p10le) no matter what. It provides a good quality boost in all cases, particularly in darker shades and noisy stuff.
I tested this yuv420p10le pixel format with Cingg too (no yuv42210le pix_fmt supported by SVT-AV1 yet):
Result: 10-bit a bit slower rendering and smaller file size, both my samples looks good in my eyes.
Svt[info]: SVT [config]: bit-depth / color format : 10 / YUV420
** rendered 5972 frames in 97.816 secs, 61.053 fps


119M    hdv09_04_m2t_svt-av1-221_cf35_pr6+opus.webm
117M    hdv09_04_m2t_svt-av1-221_cf35_pr6_yuv420p10le+opus.webm





[mpeg2video @ 0x562aa8f5b4c0] Invalid frame dimensions 0x0.
    Last message repeated 3 times
[mpegts @ 0x562aa8f55e00] PES packet size mismatch
[mpegts @ 0x562aa8f55e00] Packet corrupt (stream = 1, dts = 258142320).
[mpegts @ 0x562aa8f55e00] Could not find codec parameters for stream 2 (Unknown: none ([160][0][0][0] / 0x00A0)): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
[mpegts @ 0x562aa8f55e00] Could not find codec parameters for stream 3 (Unknown: none ([161][0][0][0] / 0x00A1)): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
Input #0, mpegts, from 'hdv09_04.m2t':
  Duration: 00:03:59.06, start: 2629.496000, bitrate: 26110 kb/s
  Program 100
  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
  Stream #0:2[0x815]: Unknown: none ([160][0][0][0] / 0x00A0)
  Stream #0:3[0x811]: Unknown: none ([161][0][0][0] / 0x00A1)
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> av1 (libsvtav1))
  Stream #0:1 -> #0:1 (mp2 (native) -> opus (libopus))
Press [q] to stop, [?] for help
[libopus @ 0x562aa8f8b940] No bit rate set. Defaulting to 96000 bps.
Svt[info]: -------------------------------------------
Svt[info]: SVT [version]:    SVT-AV1 Encoder Lib v2.2.0
.........snip
Output #0, webm, to 'hdv09_04_m2t_ffmpeg-7_svt-av1-221_pr6+opus.webm':
  Metadata:
    encoder         : Lavf61.1.100
  Stream #0:0: Video: av1, yuv420p(tv, bt709, top coded first (swapped)), 1440x1080 [SAR 4:3 DAR 16:9], q=2-31, 25 fps, 1k tbn
      Metadata:
        encoder         : Lavc61.3.100 libsvtav1
  Stream #0:1: Audio: opus, 48000 Hz, stereo, s16, 96 kb/s
      Metadata:
        encoder         : Lavc61.3.100 libopus
[mpegts @ 0x562aa8f55e00] PES packet size mismatch0:03:50.00 bitrate=4148.7kbits/s speed=2.75x    
[mpegts @ 0x562aa8f55e00] Packet corrupt (stream = 1, dts = 258142320).
[mpeg2video @ 0x562aa8f86800] ac-tex damaged at 10 61
[mpeg2video @ 0x562aa8f86800] Warning MVs not available
[mpeg2video @ 0x562aa8f86800] concealing 630 DC, 630 AC, 630 MV errors in P frame
[vist#0:0/mpeg2video @ 0x562aa8f5de80] [dec:mpeg2video @ 0x562aa90fa840] corrupt decoded frame
[out#0/webm @ 0x562aa8f8d380] video:119306KiB audio:2490KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.091528%



> RenderFarmClient::main_loop: client started
> FFMPEG::open_decoder: some stream times estimated: /home/guest/0005.avi
> Svt[info]: -------------------------------------------
> Svt[info]: SVT [version]:       SVT-AV1 Encoder Lib v2.2.0

I also got and noticed the output version

Svt[info]: SVT [version]: SVT-AV1 Encoder Lib v2.2.0


Shouldn't it be SVT-AV1 Lib 2.2.1 as mentioned above

cinelerra-5.1/thirdparty/src/libsvtav1-v2.2.1.tar.xz

or possibly the 2.2.1 sub-version isn't shown in the Svt info?

 
Andrey, if you see this, Andrew has suggested "maybe compilefarm configure command line for new OSes need to be
augmented with '--enable-libsvtav1" ?".
libsvtav1 requires cmake to be at 3.16 (or so far has been working at 3.12) so we did not want to have failures by making it compile by default in order to not impact older operating systems where it would always fail.