Release for 12/2024 + question for Andrey
AppImages available for the December 2024 release at: https://cinelerra-gg.org/download/images/ + https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... Packages available for the newer operating systems at: https://github.com/einhander/cin-gg-packages/releases/tag/20241229 See latest release notes below the *****. Question for *Andrey*: Would it be possible to easily add --with-onevpl to the configure line in your build script for Leap 15.5 RPM package? It would require the added package of "oneVPL-devel" to be installed on that O/S (that is the package name for Fedora). If you use the same build script on all of your package builds, they would have to have "oneVPL-devel" installed also. I have tested the build on Fedora 40 after installing that package and had no problem. I have none of the new Intel hardware to test but Terje would like to be able to use these new Intel hardware/software features on his computer. It should not impact normal usage (hopefully). ********* GIT for Cinelerra-GG has the following changes from 11/01/2024-12/31/2024 ********* *SVT_AV1* has been upgraded to 2.3.0 from 2.2.1 with no known problems. *Nvidia encode headers* updated from 10.0.26.0 to 12.2.72.0 which corresponds to Video Codec SDK version 12.0.16. The required driver version for Linux is 550.54.14 or newer. You can check to see if your Nvidia graphics board is supported at this website at the time of this release: https::// developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new There may be user impact since the previous required driver for Linux was 445.87. Minor addition to add non-working ffmpeg filters to plugin.opts; these are blacklisted items. *Andrew-R contributions* The build for *NetBSD* 10.0/amd64 is now working with 3 patches applied and checked in. New *Termux* (Android) encoding render formats have been added: h264_mediacodec.mp4, hevc_mediacodec.mp4, and mpeg2_hdv.mpeg. The 2 mediacodec formats will only work on Android (mediacodec is part of the Android low-level multimedia support infrastructure). A mod to mjpegtools disables compilation of y4mdenoise to prevent compiler errors in *clang*. *Terje testing/building and Andrew-R diagnosing contributions* 12 *new render formats* for qsv, which can be used only if you have that particular Intel hardware and software, have been added as developed/tested by Andrew and Terje. (QSV is Intel’s Quick Sync Video for its dedicated video encoding/decoding hardware core.) 12 *new or replaced vaapi hardware encoding *render formats are now available. Run the vainfo program to determine what formats your hardware/software recognizes. There are some patches to ffmpeg.C and ffmpeg.h to support the above. Additions for building with *oneVPL* (Intel’s oneAPI Video Processing Library) is now an option to be enabled if desired - not enabled by default - on the autogen line by adding “--with-onevpl”. Note in reference to the previous paragraph: There should be no impact to standard usage of CinGG but users need to be especially aware of the fact that using a render encoding format that requires specific hardware/software implementation will give an error. In addition, the standard AppImage releases will not provide the availability to use specific hardware features. This is the same as the inability to use vdpau/vaapi from those same appimages since they are created on a computer without the end users specific hardware. An *AppImage* has been graciously created for users who do have the Intel hardware that supports these newly tested/implemented features *of oneVPL, av1, qsv, and vaapi* for download at: https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm...
Would it be possible to easily add --with-onevpl to the configure line in your build script for Leap 15.5 RPM package?
No problem. The configure line should be changed only for Leap 15.5, or packages for other systems should be build also with that option? Best regards, Andrey вт, 31 дек. 2024 г., 23:15 Phyllis Smith via Cin <[email protected]
:
AppImages available for the December 2024 release at: https://cinelerra-gg.org/download/images/ + https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... Packages available for the newer operating systems at: https://github.com/einhander/cin-gg-packages/releases/tag/20241229 See latest release notes below the *****.
Question for *Andrey*: Would it be possible to easily add --with-onevpl to the configure line in your build script for Leap 15.5 RPM package? It would require the added package of "oneVPL-devel" to be installed on that O/S (that is the package name for Fedora). If you use the same build script on all of your package builds, they would have to have "oneVPL-devel" installed also. I have tested the build on Fedora 40 after installing that package and had no problem. I have none of the new Intel hardware to test but Terje would like to be able to use these new Intel hardware/software features on his computer. It should not impact normal usage (hopefully).
********* GIT for Cinelerra-GG has the following changes from 11/01/2024-12/31/2024 ********* *SVT_AV1* has been upgraded to 2.3.0 from 2.2.1 with no known problems. *Nvidia encode headers* updated from 10.0.26.0 to 12.2.72.0 which corresponds to Video Codec SDK version 12.0.16. The required driver version for Linux is 550.54.14 or newer. You can check to see if your Nvidia graphics board is supported at this website at the time of this release: https::// developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new There may be user impact since the previous required driver for Linux was 445.87. Minor addition to add non-working ffmpeg filters to plugin.opts; these are blacklisted items.
*Andrew-R contributions* The build for *NetBSD* 10.0/amd64 is now working with 3 patches applied and checked in. New *Termux* (Android) encoding render formats have been added: h264_mediacodec.mp4, hevc_mediacodec.mp4, and mpeg2_hdv.mpeg. The 2 mediacodec formats will only work on Android (mediacodec is part of the Android low-level multimedia support infrastructure). A mod to mjpegtools disables compilation of y4mdenoise to prevent compiler errors in *clang*.
*Terje testing/building and Andrew-R diagnosing contributions* 12 *new render formats* for qsv, which can be used only if you have that particular Intel hardware and software, have been added as developed/tested by Andrew and Terje. (QSV is Intel’s Quick Sync Video for its dedicated video encoding/decoding hardware core.) 12 *new or replaced vaapi hardware encoding *render formats are now available. Run the vainfo program to determine what formats your hardware/software recognizes. There are some patches to ffmpeg.C and ffmpeg.h to support the above. Additions for building with *oneVPL* (Intel’s oneAPI Video Processing Library) is now an option to be enabled if desired - not enabled by default - on the autogen line by adding “--with-onevpl”. Note in reference to the previous paragraph: There should be no impact to standard usage of CinGG but users need to be especially aware of the fact that using a render encoding format that requires specific hardware/software implementation will give an error. In addition, the standard AppImage releases will not provide the availability to use specific hardware features. This is the same as the inability to use vdpau/vaapi from those same appimages since they are created on a computer without the end users specific hardware. An *AppImage* has been graciously created for users who do have the Intel hardware that supports these newly tested/implemented features *of oneVPL, av1, qsv, and vaapi* for download at:
https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrey, since I do not know if Terje will be able to actually take advantage of his Intel hardware using the RPM you generate for Leap with the oneVPL added, I suggest just changing it for Leap first and then wait for Terje to test it before doing them all. Thank you very much, Phyllis On Tue, Dec 31, 2024 at 1:25 PM Андрей Спицын via Cin < [email protected]> wrote:
Would it be possible to easily add --with-onevpl to the configure line in your build script for Leap 15.5 RPM package?
No problem. The configure line should be changed only for Leap 15.5, or packages for other systems should be build also with that option?
Best regards, Andrey
вт, 31 дек. 2024 г., 23:15 Phyllis Smith via Cin < [email protected]>:
AppImages available for the December 2024 release at: https://cinelerra-gg.org/download/images/ + https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... Packages available for the newer operating systems at: https://github.com/einhander/cin-gg-packages/releases/tag/20241229 See latest release notes below the *****.
Question for *Andrey*: Would it be possible to easily add --with-onevpl to the configure line in your build script for Leap 15.5 RPM package? It would require the added package of "oneVPL-devel" to be installed on that O/S (that is the package name for Fedora). If you use the same build script on all of your package builds, they would have to have "oneVPL-devel" installed also. I have tested the build on Fedora 40 after installing that package and had no problem. I have none of the new Intel hardware to test but Terje would like to be able to use these new Intel hardware/software features on his computer. It should not impact normal usage (hopefully).
********* GIT for Cinelerra-GG has the following changes from 11/01/2024-12/31/2024 ********* *SVT_AV1* has been upgraded to 2.3.0 from 2.2.1 with no known problems. *Nvidia encode headers* updated from 10.0.26.0 to 12.2.72.0 which corresponds to Video Codec SDK version 12.0.16. The required driver version for Linux is 550.54.14 or newer. You can check to see if your Nvidia graphics board is supported at this website at the time of this release: https::// developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new There may be user impact since the previous required driver for Linux was 445.87. Minor addition to add non-working ffmpeg filters to plugin.opts; these are blacklisted items.
*Andrew-R contributions* The build for *NetBSD* 10.0/amd64 is now working with 3 patches applied and checked in. New *Termux* (Android) encoding render formats have been added: h264_mediacodec.mp4, hevc_mediacodec.mp4, and mpeg2_hdv.mpeg. The 2 mediacodec formats will only work on Android (mediacodec is part of the Android low-level multimedia support infrastructure). A mod to mjpegtools disables compilation of y4mdenoise to prevent compiler errors in *clang*.
*Terje testing/building and Andrew-R diagnosing contributions* 12 *new render formats* for qsv, which can be used only if you have that particular Intel hardware and software, have been added as developed/tested by Andrew and Terje. (QSV is Intel’s Quick Sync Video for its dedicated video encoding/decoding hardware core.) 12 *new or replaced vaapi hardware encoding *render formats are now available. Run the vainfo program to determine what formats your hardware/software recognizes. There are some patches to ffmpeg.C and ffmpeg.h to support the above. Additions for building with *oneVPL* (Intel’s oneAPI Video Processing Library) is now an option to be enabled if desired - not enabled by default - on the autogen line by adding “--with-onevpl”. Note in reference to the previous paragraph: There should be no impact to standard usage of CinGG but users need to be especially aware of the fact that using a render encoding format that requires specific hardware/software implementation will give an error. In addition, the standard AppImage releases will not provide the availability to use specific hardware features. This is the same as the inability to use vdpau/vaapi from those same appimages since they are created on a computer without the end users specific hardware. An *AppImage* has been graciously created for users who do have the Intel hardware that supports these newly tested/implemented features *of oneVPL, av1, qsv, and vaapi* for download at:
https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
вт, 31 дек. 2024 г., 23:15 Phyllis Smith via Cin <[email protected]
:
AppImages available for the December 2024 release at: https://cinelerra-gg.org/download/images/ + https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... Packages available for the newer operating systems at: https://github.com/einhander/cin-gg-packages/releases/tag/20241229 See latest release notes below the *****.
Question for *Andrey*: Would it be possible to easily add --with-onevpl to the configure line in your build script for Leap 15.5 RPM package? It would require the added package of "oneVPL-devel" to be installed on that O/S (that is the package name for Fedora). If you use the same build script on all of your package builds, they would have to have "oneVPL-devel" installed also. I have tested the build on Fedora 40 after installing that package and had no problem. I have none of the new Intel hardware to test but Terje would like to be able to use these new Intel hardware/software features on his computer. It should not impact normal usage (hopefully).
********* GIT for Cinelerra-GG has the following changes from 11/01/2024-12/31/2024 ********* *SVT_AV1* has been upgraded to 2.3.0 from 2.2.1 with no known problems. *Nvidia encode headers* updated from 10.0.26.0 to 12.2.72.0 which corresponds to Video Codec SDK version 12.0.16. The required driver version for Linux is 550.54.14 or newer. You can check to see if your Nvidia graphics board is supported at this website at the time of this release: https::// developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new There may be user impact since the previous required driver for Linux was 445.87. Minor addition to add non-working ffmpeg filters to plugin.opts; these are blacklisted items.
*Andrew-R contributions* The build for *NetBSD* 10.0/amd64 is now working with 3 patches applied and checked in. New *Termux* (Android) encoding render formats have been added: h264_mediacodec.mp4, hevc_mediacodec.mp4, and mpeg2_hdv.mpeg. The 2 mediacodec formats will only work on Android (mediacodec is part of the Android low-level multimedia support infrastructure). A mod to mjpegtools disables compilation of y4mdenoise to prevent compiler errors in *clang*.
*Terje testing/building and Andrew-R diagnosing contributions* 12 *new render formats* for qsv, which can be used only if you have that particular Intel hardware and software, have been added as developed/tested by Andrew and Terje. (QSV is Intel’s Quick Sync Video for its dedicated video encoding/decoding hardware core.) 12 *new or replaced vaapi hardware encoding *render formats are now available. Run the vainfo program to determine what formats your hardware/software recognizes. There are some patches to ffmpeg.C and ffmpeg.h to support the above. Additions for building with *oneVPL* (Intel’s oneAPI Video Processing Library) is now an option to be enabled if desired - not enabled by default - on the autogen line by adding “--with-onevpl”. Note in reference to the previous paragraph: There should be no impact to standard usage of CinGG but users need to be especially aware of the fact that using a render encoding format that requires specific hardware/software implementation will give an error. In addition, the standard AppImage releases will not provide the availability to use specific hardware features. This is the same as the inability to use vdpau/vaapi from those same appimages since they are created on a computer without the end users specific hardware.
I think you can use appimage's libva IF your operating system closely match one used for creating appimage. Testing without hardware obviously will not work .... Thanks a lot, have nice turn of year! An *AppImage* has been graciously created for users who do have the Intel
hardware that supports these newly tested/implemented features *of oneVPL, av1, qsv, and vaapi* for download at:
https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 31.12.2024 23:31, skrev Andrew Randrianasulu via Cin:
вт, 31 дек. 2024 г., 23:15 Phyllis Smith via Cin <[email protected]>:
AppImages available for the December 2024 release at: https://cinelerra-gg.org/download/images/ + https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... Packages available for the newer operating systems at: https://github.com/einhander/cin-gg-packages/releases/tag/20241229 See latest release notes below the *****.
Question for *Andrey*: Would it be possible to easily add --with-onevpl to the configure line in your build script for Leap 15.5 RPM package? It would require the added package of "oneVPL-devel" to be installed on that O/S (that is the package name for Fedora). If you use the same build script on all of your package builds, they would have to have "oneVPL-devel" installed also. I have tested the build on Fedora 40 after installing that package and had no problem. I have none of the new Intel hardware to test but Terje would like to be able to use these new Intel hardware/software features on his computer. It should not impact normal usage (hopefully).
********* GIT for Cinelerra-GG has the following changes from 11/01/2024-12/31/2024 ********* *SVT_AV1* has been upgraded to 2.3.0 from 2.2.1 with no known problems. *Nvidia encode headers* updated from 10.0.26.0 to 12.2.72.0 which corresponds to Video Codec SDK version 12.0.16. The required driver version for Linux is 550.54.14 or newer. You can check to see if your Nvidia graphics board is supported at this website at the time of this release: https:://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new <http://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new> There may be user impact since the previous required driver for Linux was 445.87. Minor addition to add non-working ffmpeg filters to plugin.opts; these are blacklisted items.
_Andrew-R contributions_ The build for *NetBSD* 10.0/amd64 is now working with 3 patches applied and checked in. New *Termux* (Android) encoding render formats have been added: h264_mediacodec.mp4, hevc_mediacodec.mp4, and mpeg2_hdv.mpeg. The 2 mediacodec formats will only work on Android (mediacodec is part of the Android low-level multimedia support infrastructure). A mod to mjpegtools disables compilation of y4mdenoise to prevent compiler errors in *clang*.
_Terje testing/building and Andrew-R diagnosing contributions_ 12 *new render formats* for qsv, which can be used only if you have that particular Intel hardware and software, have been added as developed/tested by Andrew and Terje. (QSV is Intel’s Quick Sync Video for its dedicated video encoding/decoding hardware core.) 12 *new or replaced vaapi hardware encoding *render formats are now available. Run the vainfo program to determine what formats your hardware/software recognizes. There are some patches to ffmpeg.C and ffmpeg.h to support the above. Additions for building with *oneVPL* (Intel’s oneAPI Video Processing Library) is now an option to be enabled if desired - not enabled by default - on the autogen line by adding “--with-onevpl”. Note in reference to the previous paragraph: There should be no impact to standard usage of CinGG but users need to be especially aware of the fact that using a render encoding format that requires specific hardware/software implementation will give an error. In addition, the standard AppImage releases will not provide the availability to use specific hardware features. This is the same as the inability to use vdpau/vaapi from those same appimages since they are created on a computer without the end users specific hardware.
I think you can use appimage's libva IF your operating system closely match one used for creating appimage. Testing without hardware obviously will not work ....
Thanks a lot, have nice turn of year!
Happy new year everybody ! Well, starting the new year with continued shoveling snow from polar low pressure here at this season 🙁 First, to correct a minor typo that stemmed from me, but it hardly doesn't matter: Leap "15.5" should be "15.6". As I have Leap and Tumbleweed/Slowroll installed in dual-boot setups on my three, older and relative new Intel platforms; SkyLake (2015), KabyLake (2016/17) and Arc Alchemist (2022/23), I can test the RPM and qsv and vaapi presets on all. Additional, I hope we also manage to get the newest Vulkan (Vaapi successor) video encoding feature incorporated next 😉 Currently I have posted the ffmpeg-Vulkan issue, which the Intel community team has promised to investigate further https://community.intel.com/t5/Graphics/ffmpeg-h264-vulkan-and-hevc-vulkan-E...
An *AppImage* has been graciously created for users who do have the Intel hardware that supports these newly tested/implemented features *of oneVPL, av1, qsv, and vaapi* for download at: https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Thank you so much for the new release! Always a great job, You all do. I did some rendering test on an old project of mine using "CinGG-20241231-alternative_shortcuts.AppImage"; only 10 secs by selection (highlight) in Timeline. Render setup: vp9_1280x270_24or24or50fps.webm - Info by terminal says: 300 frames 94.918 secs 3.161 fps; File Size 1.6MB An old Cin version, same setup,... - Info by terminal says: 300 frames 83.582 secs 3.589 fps; File Size 1.5MB I think, it is strange that rendering of an old version of CinGG is slightly faster than a new one. Is it, probably, due to the old Laptop and old Operating System that adapts better? IgorBeg Il 31/12/2024 21:14, Phyllis Smith via Cin ha scritto:
AppImages available for the December 2024 release at: https://cinelerra-gg.org/download/images/ + https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... Packages available for the newer operating systems at: https://github.com/einhander/cin-gg-packages/releases/tag/20241229 See latest release notes below the *****.
Question for *Andrey*: Would it be possible to easily add --with-onevpl to the configure line in your build script for Leap 15.5 RPM package? It would require the added package of "oneVPL-devel" to be installed on that O/S (that is the package name for Fedora). If you use the same build script on all of your package builds, they would have to have "oneVPL-devel" installed also. I have tested the build on Fedora 40 after installing that package and had no problem. I have none of the new Intel hardware to test but Terje would like to be able to use these new Intel hardware/software features on his computer. It should not impact normal usage (hopefully).
********* GIT for Cinelerra-GG has the following changes from 11/01/2024-12/31/2024 ********* *SVT_AV1* has been upgraded to 2.3.0 from 2.2.1 with no known problems. *Nvidia encode headers* updated from 10.0.26.0 to 12.2.72.0 which corresponds to Video Codec SDK version 12.0.16. The required driver version for Linux is 550.54.14 or newer. You can check to see if your Nvidia graphics board is supported at this website at the time of this release:
https:://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new <http://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new> There may be user impact since the previous required driver for Linux was 445.87. Minor addition to add non-working ffmpeg filters to plugin.opts; these are blacklisted items.
_Andrew-R contributions_ The build for *NetBSD* 10.0/amd64 is now working with 3 patches applied and checked in. New *Termux* (Android) encoding render formats have been added: h264_mediacodec.mp4, hevc_mediacodec.mp4, and mpeg2_hdv.mpeg. The 2 mediacodec formats will only work on Android (mediacodec is part of the Android low-level multimedia support infrastructure). A mod to mjpegtools disables compilation of y4mdenoise to prevent compiler errors in *clang*.
_Terje testing/building and Andrew-R diagnosing contributions_ 12 *new render formats* for qsv, which can be used only if you have that particular Intel hardware and software, have been added as developed/tested by Andrew and Terje. (QSV is Intel’s Quick Sync Video for its dedicated video encoding/decoding hardware core.) 12 *new or replaced vaapi hardware encoding *render formats are now available. Run the vainfo program to determine what formats your hardware/software recognizes. There are some patches to ffmpeg.C and ffmpeg.h to support the above. Additions for building with *oneVPL* (Intel’s oneAPI Video Processing Library) is now an option to be enabled if desired - not enabled by default - on the autogen line by adding “--with-onevpl”. Note in reference to the previous paragraph: There should be no impact to standard usage of CinGG but users need to be especially aware of the fact that using a render encoding format that requires specific hardware/software implementation will give an error. In addition, the standard AppImage releases will not provide the availability to use specific hardware features. This is the same as the inability to use vdpau/vaapi from those same appimages since they are created on a computer without the end users specific hardware. An *AppImage* has been graciously created for users who do have the Intel hardware that supports these newly tested/implemented features *of oneVPL, av1, qsv, and vaapi* for download at: https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm...
IgorB, Thank you for testing and documenting your results. Did you test the new AppImage first and then the old Appimage? The faster time on the old AppImage may have been due to some of the video file/rendering still being in memory. Were both cases tested with AppImages? Do you get the same results if you test the old AppImage first and then the new? Or the results could be because of the increased size of the new AppImage versus the old; the upgraded library packages; or something else! I did some rendering test on an old project of mine using
"CinGG-20241231-alternative_shortcuts.AppImage"; only 10 secs by selection (highlight) in Timeline. Render setup: vp9_1280x270_24or24or50fps.webm - Info by terminal says: 300 frames 94.918 secs 3.161 fps; File Size 1.6MB An old Cin version, same setup,... - Info by terminal says: 300 frames 83.582 secs 3.589 fps; File Size 1.5MB
I think, it is strange that rendering of an old version of CinGG is slightly faster than a new one. Is it, probably, due to the old Laptop and old Operating System that adapts better?
IgorBeg
Thank you, Phyllis for you yours good replies/questions. All yours questions are good. The tests were done using "CinGG-20241231-alternative_shortcuts.AppImage" versus a very old "cinelerra-5.1-ub16.04-20201031.x86_64-static.txz" (no Appimage). I tested the new Appimage first and then the old release. Yesterday I did other tests: always the same project, the same selection in the Timeline, the same Render setup (vp9_1280x270_24or24or50fps.webm). I did the same render four times (no other programs run by me), first the old version (A) and then the new Appimage (B). A. - Started using "cinelerra-5.1-ub16.04-20201031.x86_64-static.txz" (no Appimage) A1. Info by terminal says: 300 frames 86.179 secs 3.481 fps A2. Info by terminal says: 300 frames 85.862 secs 3.494 fps A3. Info by terminal says: 300 frames 89.611 secs 3.348 fps A4. Info by terminal says: 300 frames 82.930 secs 3.618 fps Media: 86.1455 secs B. - Then using "CinGG-20241231-alternative_shortcuts.AppImage" B1. Info by terminal says: 300 frames 92.788 secs 3.233 fps B2. Info by terminal says: 300 frames 88.714 secs 3.382 fps B3. Info by terminal says: 300 frames 90.842 secs 3.302 fps B4. Info by terminal says: 300 frames 90.586 secs 3.312 fps Media: 90.7325 secs Every time the result is different, I think it is normal,... and all the things Phyllis wrote are valid. Thanks! IgorBeg Il 06/01/2025 16:12, Phyllis Smith ha scritto:
IgorB, Thank you for testing and documenting your results. Did you test the new AppImage first and then the old Appimage? The faster time on the old AppImage may have been due to some of the video file/rendering still being in memory. Were both cases tested with AppImages? Do you get the same results if you test the old AppImage first and then the new? Or the results could be because of the increased size of the new AppImage versus the old; the upgraded library packages; or something else!
I did some rendering test on an old project of mine using "CinGG-20241231-alternative_shortcuts.AppImage"; only 10 secs by selection (highlight) in Timeline. Render setup: vp9_1280x270_24or24or50fps.webm - Info by terminal says: 300 frames 94.918 secs 3.161 fps; File Size 1.6MB An old Cin version, same setup,... - Info by terminal says: 300 frames 83.582 secs 3.589 fps; File Size 1.5MB
I think, it is strange that rendering of an old version of CinGG is slightly faster than a new one. Is it, probably, due to the old Laptop and old Operating System that adapts better?
IgorBeg
IgorB, Your tests prove that the new version is always slower, with only the 1 exception of 89.611 secs (old) versus 88.714 secs (new). Unfortunately that is not what we want as many of the libraries continuously attempt to improve speeds with CinGG only having minor changes to it. Thanks again. On Tue, Jan 7, 2025 at 2:08 AM Igor BEGHETTO via Cin < [email protected]> wrote:
Thank you, Phyllis for you yours good replies/questions. All yours questions are good.
The tests were done using "CinGG-20241231-alternative_shortcuts.AppImage" versus a very old "cinelerra-5.1-ub16.04-20201031.x86_64-static.txz" (no Appimage). I tested the new Appimage first and then the old release.
Yesterday I did other tests: always the same project, the same selection in the Timeline, the same Render setup (vp9_1280x270_24or24or50fps.webm). I did the same render four times (no other programs run by me), first the old version (A) and then the new Appimage (B). A. - Started using "cinelerra-5.1-ub16.04-20201031.x86_64-static.txz" (no Appimage) A1. Info by terminal says: 300 frames 86.179 secs 3.481 fps A2. Info by terminal says: 300 frames 85.862 secs 3.494 fps A3. Info by terminal says: 300 frames 89.611 secs 3.348 fps A4. Info by terminal says: 300 frames 82.930 secs 3.618 fps Media: 86.1455 secs
B. - Then using "CinGG-20241231-alternative_shortcuts.AppImage" B1. Info by terminal says: 300 frames 92.788 secs 3.233 fps B2. Info by terminal says: 300 frames 88.714 secs 3.382 fps B3. Info by terminal says: 300 frames 90.842 secs 3.302 fps B4. Info by terminal says: 300 frames 90.586 secs 3.312 fps Media: 90.7325 secs
Every time the result is different, I think it is normal,... and all the things Phyllis wrote are valid. Thanks!
IgorBeg
Il 06/01/2025 16:12, Phyllis Smith ha scritto:
IgorB, Thank you for testing and documenting your results. Did you test the new AppImage first and then the old Appimage? The faster time on the old AppImage may have been due to some of the video file/rendering still being in memory. Were both cases tested with AppImages? Do you get the same results if you test the old AppImage first and then the new? Or the results could be because of the increased size of the new AppImage versus the old; the upgraded library packages; or something else!
I did some rendering test on an old project of mine using "CinGG-20241231-alternative_shortcuts.AppImage"; only 10 secs by selection (highlight) in Timeline. Render setup: vp9_1280x270_24or24or50fps.webm - Info by terminal says: 300 frames 94.918 secs 3.161 fps; File Size 1.6MB An old Cin version, same setup,... - Info by terminal says: 300 frames 83.582 secs 3.589 fps; File Size 1.5MB
I think, it is strange that rendering of an old version of CinGG is slightly faster than a new one. Is it, probably, due to the old Laptop and old Operating System that adapts better?
IgorBeg
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (5)
-
Andrew Randrianasulu -
Igor BEGHETTO -
Phyllis Smith -
Terje J. Hanssen -
Андрей Спицын