Den 30.12.2023 10:03, skrev Andrea paz:
At first I tried to run it on Leap 15.5, but its glibc 2.31 was too old.
On Tumbleweed-Slowroll the cin-aom-38_svt.AppImage started ok.
Thanks for the test. So it is useless to create appimage from one
rolling because they only work on other rolling.
Well, Leap15.5 is openSUSE's LTS stable release, while
Tumbleweed-Slowroll is the upcoming successor (a stabilized version
of the fast rolling Tumbleweed).
If the cin-aom-38_svt error or warning startup and rendering
messages is of interest to look at, I have attached them here for
each of these releases
Notice that on Tumbleweed-Slowroll this is the very first Cin-GG
startup and run from scratch, without any project setup etc.
cin-aom-38_svt_startup_messages.tar.xz
But unhappily it was a bit even slower on my machine than the previous aom.
And continued playback Video with aspect ratio 4:3 and scratch sound on the Audio.
smpte170m colors seems for me to be for NTSC, and not for PAL video.
Rendering took 0:41:08, almost 6 times the clip duration
I too have a lot of confusion about how CinGG treats colors in
specific cases. See the notions on Kernel.org if they can help you:
https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/colorspaces-details.html
In the meantime, I'll post the ffprobes from my tests (project's size
1920x1080; 16:9. source1: DNxHR, 1080p; source2: h264, 2160p; source3:
VP9, 640x480):
AOM_3.8.0:
$ ffprobe -hide_banner test_aom_38.webm
[libdav1d @ 0x5619aeb26140] libdav1d 1.3.0
Input #0, matroska,webm, from 'test_aom_38.webm':
Metadata:
ENCODER : Lavf60.16.100
Duration: 00:01:12.17, start: 0.000000, bitrate: 1266 kb/s
Stream #0:0: Video: av1 (Main), yuv420p(pc,
bt2020nc/unknown/unknown, progressive), 1920x1080, SAR 1:1 DAR 16:9,
24 fps, 24 tbr, 1k tbn
Metadata:
DURATION : 00:01:12.128000000
Stream #0:1(ita): Audio: vorbis, 48000 Hz, stereo, fltp
Metadata:
DURATION : 00:01:12.170000000
[libdav1d @ 0x5619aeb62400] libdav1d 1.3.0
(12.5 fps; 10.9 MB,)
AOM-SVT:
$ ffprobe -hide_banner test_aom_svt.webm
[libdav1d @ 0x55b740a0a140] libdav1d 1.3.0
Input #0, matroska,webm, from 'test_aom_svt.webm':
Metadata:
ENCODER : Lavf60.16.100
Duration: 00:01:12.17, start: 0.000000, bitrate: 1369 kb/s
Stream #0:0: Video: av1 (Main), yuv420p(pc,
bt2020nc/unknown/unknown, progressive), 1920x1080, SAR 1:1 DAR 16:9,
24 fps, 24 tbr, 1k tbn
Metadata:
DURATION : 00:01:12.128000000
Stream #0:1(ita): Audio: vorbis, 48000 Hz, stereo, fltp
Metadata:
DURATION : 00:01:12.170000000
[libdav1d @ 0x55b740a46400] libdav1d 1.3.0
(11.8 MB; 58 fps)
The video, but especially the audio, seem to me to be of slightly
lower quality than the original sources.
If SVT-AV1 1.8.0 rendering is possible with cin-aom-38_svt.AppImage, where do you select this?
Among the webm presets should also appear av1-svt.webm, the profile
created by Andrew; see image:
https://postimg.cc/cgjQfR11
Yes, thanks I found it. I had not looked there or simply overseen
it, as it normally is referred to as svt-av1 :)
And SVT-AV1 1.8 confirms to be VERY FAST and of most interest as
default CPU AV1 encoder (also for CinGG?)
As mentioned in Phoronix recent release article:
https://www.phoronix.com/news/SVT-AV1-1.8-Released
SVT-AV1 1.8 brings more speed-ups at various preset levels --
especially M0 to M6 where there can be gains as much as 53%.
Two Cin-GG AV1-SVT rendering tests of the same loaded hdv07_05.m2t
clip took 0:02:54 and 0:02:51 respectively.
If not due to technical issues (see the attached messages), that is
impressive FPS = 10240/172 = 59.5 or 2.4x faster than the clip
duration!
And compared to the AOM 3.8 40-minutes rendering above, this is
14.3x times faster!
The CinGG svt-av1 v.1.8 preset seemed to use Preset 6 and CRF 26
In comparison I started a temporary test with the same FFmpeg
SVT-AV1 v. 1.7 Preset 6, which seemed to perform much slower (ca. 8
FPS).
The default faster Preset 10 and CRF 35 from my previous FFPmpeg
test of the same clip provided 68 FPS.
That is, very Promising SVT-AV1 speed rendering, BUT
the HDV Aspect ratio and broken Audio has to be fixed in CinGG
yuv420p(pc, smpte170m/unknown/unknown), 1440x1080 [SAR 1:1 DAR 4:3]
Or the procedure has to be clarified, in case I have done something
wrong or inadequate.