<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 07.01.2025 20:33, Phyllis Smith
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOckJE33enas5q+m75-c6-LaVdZYjrLQZrYM-uqJcL1mzCRk6A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">When doing a
longer video of 2 minutes/22 seconds and no hardware, I only
found a<b> 3.3% increase</b>. So I think the results are very
dependent. This video was 3840x2160 with 25 framerate,
av1/webm. I rendered h264.mp4 format.<br>
</div>
<div class="gmail_default" style="font-size:small"> Build:
3602 frames 251.651 secs 14.313 fps</div>
<div class="gmail_default" style="font-size:small"> AppI:
3602 frames 260.165 secs 13.840 fps</div>
<div class="gmail_default" style="font-size:small">But anyway. I
did add a note to the Manual stating that AppImage could be
slower and referred to the section on "distros with Cinelerra
included" which references Andrey's RPMs, etc.<br>
</div>
</div>
<br>
</blockquote>
<br>
Yes, I think I have also experienced that h264 rendering behave
differently, and may be slower than default hevc and av1.<br>
<br>
The following h264 comparative tests with my same short hdv video
clip on Leap, show only 6% faster cpu rendering and close race 0.3%
faster gpu rendering for the RPM.<br>
These tests shows also that h264_qsv gpu rendering is 2.37x faster
than h264 cpu rendering.<br>
<br>
h264.mp4 (yuv420p, i7-12700KF cpu)<br>
** rendered 5972 frames in 46.738 secs, 127.776 fps (RPM, )<br>
** rendered 5972 frames in 49.732 secs, 120.084 fps (AppImage)<br>
<br>
h264_qsv_8b420.mp4 (A750 gpu)<br>
** rendered 5972 frames in 20.275 secs, 294.550 fps (RPM)<br>
** rendered 5972 frames in 20.345 secs, 293.536 fps (AppImage)<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAOckJE33enas5q+m75-c6-LaVdZYjrLQZrYM-uqJcL1mzCRk6A@mail.gmail.com">
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Tue, Jan 7, 2025 at 8:27 AM
Terje J. Hanssen <<a href="mailto:terjejhanssen@gmail.com"
moz-do-not-send="true" class="moz-txt-link-freetext">terjejhanssen@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> <br>
<br>
<br>
<div>Den 07.01.2025 15:48, skrev Phyllis Smith:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">Slower
AppImage is to be expected, but still disappointing.
Bottom line is that users who can take advantage of
Andrey's RPMs should always do so. Besides being
faster, it provides more capabilities and opportunity
to make some minor side changes. Thank you, Terje,
for doing the tests and passing along this
information.<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jan 6, 2025 at
5:35 PM Terje J. Hanssen via Cin <<a
href="mailto:cin@lists.cinelerra-gg.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">cin@lists.cinelerra-gg.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I
did a few hevc and av1 OSV render tests using the
latest RPM w/oneVPL <br>
on Leap, to compare it with my own AppImage.<br>
To get the AppImage from Slowroll to run om Leap, I
had to add-install a <br>
newer version libFLAC12.<br>
<br>
The machine is AlderLake w/Arc A750 gpu<br>
The OS root drive is on a std SATA disc, while the
video files are <br>
read/written to a fast M.2 disc.<br>
<br>
Results:<br>
<br>
hevc_qsv_8b420.mp4<br>
** rendered 5972 frames in 19.255 secs, 310.153 fps
(RPM)<br>
** rendered 5972 frames in 23.798 secs, 250.945 fps
(AppImage)<br>
<br>
av1_qsv_8b420.mp4<br>
** rendered 5972 frames in 18.612 secs, 320.868 fps
(RPM)<br>
** rendered 5972 frames in 21.470 secs, 278.156 fps
(AppImage)<br>
<br>
In average rendering is ca. 20% faster with the RPM.<br>
I did also additional test with the AppImage on
Slowroll and got a bit <br>
faster rendering, but not so fast as with RPM on Leap.<br>
<br>
</blockquote>
</div>
</blockquote>
==========================<br>
<br>
Not especially news or differently, but as I also have
supplemented my AppImages and native builds tests on
Slowroll, I add them here. My conclusion is that the
package (RPM) build (due to most dynamically linked libs I
guess?) still stands as fastest, while the AppImages supply
with benefit of portability (cross Linux distributions).<br>
<br>
<br>
On Slowroll (root and video on the M.2 NVMe SSD)<br>
------------------<br>
<br>
CinGG-20241120-x86_64.AppImage<br>
<br>
hevc_qsv_8b420.mp4<br>
** rendered 5972 frames in 20.574 secs, 290.269 fps<br>
<br>
av1_qsv_8b420.mp4<br>
** rendered 5972 frames in 21.612 secs, 276.328 fps<br>
-------------<br>
<br>
CinGG_use_system_ffmpeg-71_20241020-x86_64.AppImage<br>
<br>
hevc_qsv_8b420.mp4<br>
** rendered 5972 frames in 21.065 secs, 283.503 fps<br>
<br>
av1_qsv_8b420.mp4<br>
** rendered 5972 frames in 21.033 secs, 283.935 fps<br>
-------------------------<br>
<br>
Native built with Cingg's internal ffmpeg 7.0<br>
bin/cin<br>
Cinelerra Infinity - built: Nov 20 2024 22:06:05<br>
<br>
hevc_qsv_8b420.mp4<br>
** rendered 5972 frames in 21.299 secs, 280.389 fps<br>
<br>
av1_qsv_8b420.mp4<br>
** rendered 5972 frames in 21.313 secs, 280.205 fps<br>
---------------------------------<br>
<br>
Native built with dynamic linked system ffmpeg 7.1<br>
<br>
/Cin/bin_use_system_ffmpeg-71> bin/cin<br>
Cinelerra Infinity - built: Oct 20 2024 21:21:06<br>
<br>
hevc_qsv_8b420.mp4<br>
Had to comment out<br>
# profile=main<br>
** rendered 5972 frames in 20.988 secs, 284.544 fps<br>
<br>
av1_qsv_8b420.mp4<br>
Had to Set Format (hdv input) tff interlaced to Not
interlaced<br>
** rendered 5972 frames in 20.835 secs, 286.633 fps<br>
** rendered 5972 frames in 21.024 secs, 284.056 fps<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>