[Cin] Build rpm from current build Cingg and thirdparty fmpeg7
Terje J. Hanssen
terjejhanssen at gmail.com
Sat Dec 7 00:03:25 CET 2024
Den 06.12.2024 23:06, skrev Andrew Randrianasulu:
>
>
> пт, 6 дек. 2024 г., 18:12 Terje J. Hanssen <terjejhanssen at gmail.com>:
>
>
>
>
> Den 06.12.2024 11:48, skrev Andrew Randrianasulu:
>>
>>
>> пт, 6 дек. 2024 г., 13:35 Terje J. Hanssen <terjejhanssen at gmail.com>:
>>
>>
>>
>>
>> Den 06.12.2024 04:32, skrev Andrew Randrianasulu:
>>>
>>>
>>> пт, 6 дек. 2024 г., 05:14 Terje J. Hanssen
>>> <terjejhanssen at gmail.com>:
>>>
>>>
>>>
>>>
>>> Den 06.12.2024 01:08, skrev Andrew Randrianasulu:
>>>>
>>>>
>>>> пт, 6 дек. 2024 г., 02:06 Terje J. Hanssen
>>>> <terjejhanssen at gmail.com>:
>>>>
>>>>
>>>>
>>>>
>>>> Den 03.12.2024 22:20, skrev Andrew Randrianasulu:
>>>>>
>>>>>
>>>>> вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen
>>>>> <terjejhanssen at gmail.com>:
>>>>>
>>>>>
>>>>> From a previous thread:
>>>>> Re: [Cin] another set of test profiles
>>>>>
>>>>> Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
>>>>>>
>>>>>> чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen
>>>>>> <terjejhanssen at gmail.com>:
>>>>>>
>>>>>>
>>>>>> Den 17.10.2024 13:51, skrev Andrew
>>>>>> Randrianasulu:
>>>>>>>
>>>>>>> чт, 17 окт. 2024 г., 13:40 Terje J.
>>>>>>> Hanssen <terjejhanssen at gmail.com>:
>>>>>>>
>>>>>>>
>>>>>>> Den 14.10.2024 00:38, skrev Andrew
>>>>>>> Randrianasulu:
>>>>>>>>
>>>>>>>> пн, 14 окт. 2024 г., 01:36 Phyllis
>>>>>>>> Smith <phylsmith2017 at gmail.com>:
>>>>>>>>
>>>>>>>> Andrew, so it seems prudent to
>>>>>>>> check into GIT, the
>>>>>>>> av1_vaapi.mp4 render format
>>>>>>>> (after successfully tested of
>>>>>>>> course); but what about the QSV
>>>>>>>> encoders?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> wait for Terje's testing OR try to
>>>>>>>> build oneVPL-cpu (it sort of
>>>>>>>> circles back to different branch of
>>>>>>>> ffmpeg, so ffmpeg will think it
>>>>>>>> uses qsv but it in fact will use
>>>>>>>> another ffmpeg .... well, in
>>>>>>>> theory! it does not work for me on
>>>>>>>> 32-bit!)
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I wonder if Hw accellerated encoding
>>>>>>> support via Vaapi and QSV is to be
>>>>>>> embedded in future Cingg Appimage
>>>>>>> and/or packages if possible?
>>>>>>> What about a list of supported
>>>>>>> dGPUs/iGPUs?
>>>>>>>
>>>>>>>
>>>>>>> Problem is - QSV/vaapi basically search
>>>>>>> for driver component and this one might
>>>>>>> be in different location on different
>>>>>>> distros, and interface between two also
>>>>>>> not set in stone.
>>>>>>>
>>>>>>> For appimage you can just unpack them
>>>>>>> and remove libva.so so on startup cingg
>>>>>>> will link to system's libva.
>>>>>>>
>>>>>>> QSV as we learned is another layer with
>>>>>>> their own runtime path for yet another
>>>>>>> set of driver components. So, while
>>>>>>> building libvpl itself is relatively
>>>>>>> easily making sure it finds its drivers
>>>>>>> is not easy (at least for me).
>>>>>>>
>>>>>>> speaking about GPU list I think it will
>>>>>>> be fairly short, you,Phyllis and Andrea
>>>>>>> probably only ones who use it and report
>>>>>>> back. Stephan noticed some troubles and
>>>>>>> reverted back to software. I can test
>>>>>>> nvdec/nvenc on livecd but this is not my
>>>>>>> everyday setup (Nvidia proprietary
>>>>>>> drivers enforce 64-bit system).
>>>>>>>
>>>>>>> But well, feel free to post short
>>>>>>> summary of that works on your GPUs in
>>>>>>> cingg as another thread, hopefully
>>>>>>> others will chime in!
>>>>>>
>>>>>> If we get available a packaged Cingg test
>>>>>> build (rpm/Leap for me), it would be more
>>>>>> useful to do this test. Then I have
>>>>>> available three gen. Intel, legacy
>>>>>> Skylake/Kabylake iGPUs and current
>>>>>> DG2/Arc GPU. I also have/had a Nvidia GPU
>>>>>> on Skylake, but it looks like it past away.
>>>>>>
>>>>>>
>>>>>> I think you can build rpm yourself, but for
>>>>>> this we need to update spec file, so it will
>>>>>> point at new source and add openvpl as
>>>>>> requirements.
>>>>>>
>>>>>> In meantime you can just make your own
>>>>>> appimage from just build
>>>>>> cingg-with-system-ffmpeg, so it hopefully
>>>>>> will not be lost after few system updates.
>>>>>>
>>>>>>
>>>>>
>>>>> Andrew,
>>>>> I don't know how busy you are currently with
>>>>> other tasks, but i case you have time, I would
>>>>> be interested to fulfill this rpm and
>>>>> (possibly Appimage) exercise?
>>>>> That is from my current build with third-party
>>>>> (internal) ffmpeg7.0.
>>>>>
>>>>>
>>>>>
>>>>> for rpm you need to edit blds/cinelerra.spec at
>>>>> the very top there is date, I think latest tar
>>>>> version is
>>>>>
>>>>> https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz
>>>>>
>>>>>
>>>>> so replace 2020 something with 20241031
>>>>>
>>>>> but then it need to be patched up, and I do not
>>>>> have tested procedure for doing this. Probably rpm
>>>>> should wait until new tagged release .... you can
>>>>> search for rpmbuild command on your system and
>>>>> read its manpage/help and may be test run it on
>>>>> some other (faster to rebuild) .spec file in meantime
>>>>>
>>>>>
>>>>> Appimage should be simpler from existing source
>>>>> directory
>>>>>
>>>>>
>>>>> just run
>>>>>
>>>>> bld_appimage.sh
>>>>>
>>>>> but be sure to get additional file and put it
>>>>> where it belong as described in comment:
>>>>> =====
>>>>>
>>>>> # Get the appropriate appimagetool from
>>>>> https://github.com/AppImage/AppImageKit/releases
>>>>> # and put it in your path. Only install the
>>>>> version for your platform
>>>>> # and mark it executable. The file name must start
>>>>> with "appimagetool".
>>>>>
>>>>> ====
>>>>>
>>>>> probably /usr/local/bin will be simplest place to
>>>>> put it as root?
>>>>
>>>> /Cin # sh ./bld_appimage.sh
>>>> .....snip
>>>> -- Copying files into AppDir --
>>>> Copying file image/cin.desktop to
>>>> AppDir/usr/share/applications/cin.desktop
>>>> Copying file image/cin.svg to
>>>> AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
>>>>
>>>> -- Deploying files into AppDir root directory --
>>>> Deploying files to AppDir root using desktop file:
>>>> AppDir/usr/share/applications/cin.desktop
>>>> Deploying desktop file to AppDir root:
>>>> AppDir/usr/share/applications/cin.desktop
>>>> Creating symlink for file
>>>> AppDir/usr/share/applications/cin.desktop in/as AppDir
>>>> Deploying icon to AppDir root:
>>>> AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
>>>> Creating symlink for file
>>>> AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
>>>> in/as AppDir
>>>> Deploying AppRun symlink for executable in AppDir
>>>> root: AppDir/usr/bin/cin
>>>> Creating symlink for file AppDir/usr/bin/cin in/as
>>>> AppDir/AppRun
>>>> Found appimagetool:
>>>> /usr/local/bin/appimagetool-x86_64.AppImage
>>>> Running command:
>>>> /usr/local/bin/appimagetool-x86_64.AppImage
>>>> "appimagetool" "AppDir" "
>>>>
>>>>
>>>> Thanks, I think I got AppImage(?) built and it
>>>> seemingly runs OK.
>>>>
>>>> That is when I found the CinGG executable file,
>>>> because I expected a file somewhere with a name
>>>> "CinGG*.AppImage"
>>>>
>>>> /Cin # file -sh AppDir/*
>>>> AppDir/AppRun: symbolic link to usr/bin/cin
>>>> AppDir/cin.desktop: symbolic link to
>>>> usr/share/applications/cin.desktop
>>>> AppDir/cin.svg: symbolic link to
>>>> usr/share/icons/hicolor/scalable/apps/cin.svg
>>>> AppDir/usr: directory
>>>>
>>>>
>>>> Cin # du -sh AppDir
>>>> 216M AppDir
>>>>
>>>> /Cin # du -sh AppDir/*/*
>>>> 198M AppDir/usr/bin
>>>> 19M AppDir/usr/lib
>>>> 100K AppDir/usr/share
>>>>
>>>>
>>>> /Cin # AppDir/usr/bin/cin
>>>> Cinelerra Infinity - built: Nov 20 2024 22:06:05
>>>> .......
>>>> BC_DisplayInfo::gl_fb_config failed
>>>> build plugin index for:
>>>> /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/plugins
>>>> PluginFFilter::new_ffilter(overlay_qsv)
>>>> err: Input/output error
>>>> PluginFFilter::new_ffilter(hstack_qsv)
>>>> err: Operation not permitted
>>>> PluginFFilter::new_ffilter(vstack_qsv)
>>>> err: Operation not permitted
>>>> PluginFFilter::new_ffilter(xstack_qsv)
>>>> err: Operation not permitted
>>>> build lv2 index for: $CIN_PATH/lv2
>>>> build ladspa plugin index for:
>>>> /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/ladspa
>>>>
>>>> Loaded hdv09_04.m2t (tff interlaced)
>>>> Tested rendering using preset hevc_qsv_10b420 which
>>>> worked fine
>>>>
>>>> libva info: VA-API version 1.22.0
>>>> libva info: Trying to open
>>>> /usr/lib64/dri/iHD_drv_video.so
>>>> libva info: Found init function __vaDriverInit_1_22
>>>> libva info: va_openDriver() returns 0
>>>> libva info: VA-API version 1.22.0
>>>> libva info: Trying to open
>>>> /usr/lib64/dri/iHD_drv_video.so
>>>> libva info: Found init function __vaDriverInit_1_22
>>>> libva info: va_openDriver() returns 0
>>>> Render::render_single: Session finished.
>>>> ** rendered 5972 frames in 19.320 secs, 309.110 fps
>>>>
>>>> ---------------------------
>>>>
>>>> So some questions when comparing the above AppDir
>>>> result with the pre-build Appimage file I download
>>>> to and run from
>>>>
>>>>
>>>> du -sh ~/Applications/Cin*
>>>> 171M CinGG-20241031-x86_64.AppImage
>>>>
>>>> ./CinGG-20241031-x86_64.AppImage
>>>>
>>>> I notice the prebuild has no symlink as in the
>>>> above AppDir
>>>>
>>>> My own built appimage has not startup errors:
>>>>
>>>> (AppImageLauncher:127697): GdkPixbuf-CRITICAL **:
>>>> 23:56:28.831: gdk_pixbuf_get_rowstride: assertion
>>>> 'GDK_IS_PIXBUF (pixbuf)' failed
>>>>
>>>>
>>>> I wonder the larger total space 216M vs 171M is due
>>>> to oneVPL and maybe some other additional libs ?
>>>>
>>>> How to possibly build an equivalent single AppImage
>>>> file directly?
>>>>
>>>>
>>>>
>>>> make sure you have mksquashfs installed?
>>>
>>> No "mksquashfs" package installed or found, but
>>> "quashfs" was installed.
>>>
>>>
>>> Cin # zypper se squash
>>> Loading repository data...
>>> Reading installed packages...
>>>
>>> S | Name | Summary | Type
>>> ---+------------------+----------------------------------------------------+--------
>>> | libsquashfuse0 | FUSE module to mount squashfs
>>> images | package
>>> i | squashfs | A Read-Only File System with
>>> Efficient Compression | package
>>> | squashfuse | FUSE module to mount squashfs
>>> images | package
>>> | squashfuse-devel | FUSE module to mount squashfs
>>> images | package
>>> | squashfuse-tools | Squafs Tools for squashfsfuse |
>>> package
>>>
>>> Not sure if they are required, but add-installed also
>>> the other on this list.
>>>
>>>
>>>>
>>>> I think last part (compressing appdir into single file
>>>> and bolting on run-time decompressor to it) failed in
>>>> your case .....
>>>>
>>>
>>> Tried bld_appimage once more:
>>>
>>> /Cin # sh ./bld_appimage.sh
>>>
>>> ..........snip
>>>
>>> Setting rpath in ELF file AppDir/usr/lib/libz.so.1.3.1
>>> to $ORIGIN
>>>
>>> -- Deploying icons --
>>> Deploying icon image/cin.svg
>>>
>>> -- Deploying desktop files --
>>> Deploying desktop file image/cin.desktop
>>>
>>> -- Copying files into AppDir --
>>> Copying file image/cin.desktop to
>>> AppDir/usr/share/applications/cin.desktop
>>> Copying file image/cin.svg to
>>> AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
>>>
>>> -- Deploying files into AppDir root directory --
>>> Deploying files to AppDir root using desktop file:
>>> AppDir/usr/share/applications/cin.desktop
>>> Deploying desktop file to AppDir root:
>>> AppDir/usr/share/applications/cin.desktop
>>> Creating symlink for file
>>> AppDir/usr/share/applications/cin.desktop in/as AppDir
>>> Deploying icon to AppDir root:
>>> AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
>>> Creating symlink for file
>>> AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
>>> in/as AppDir
>>> Deploying AppRun symlink for executable in AppDir root:
>>> AppDir/usr/bin/cin
>>> Creating symlink for file AppDir/usr/bin/cin in/as
>>> AppDir/AppRun
>>> Found appimagetool:
>>> /usr/local/bin/appimagetool-x86_64.AppImage
>>> Running command:
>>> /usr/local/bin/appimagetool-x86_64.AppImage
>>> "appimagetool" "AppDir" "
>>> /usr/bin/AppImageLauncher: /lib64/libcurl.so.4: no
>>> version information available (required by
>>> /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
>>>
>>>
>>> ====>>>> AppImageLauncher popup here and want to
>>> integrate/run, and maybe break something (?)
>>>
>>>
>>>
>>> https://github.com/TheAssassin/AppImageLauncher/issues/602
>>>
>>> ====
>>> AppImageLauncher would need to be updated to support Zstd,
>>> unsure why it still doesn't support it yet (is
>>> AppImageLauncher still maintained?). But for now AppImage
>>> authors need to use another compression format than the
>>> default one by passing either |--comp xz| or |--comp gzip|
>>> to appimagetool to have it work with AppImageLauncher.
>>>
>>> =====
>>>
>>> workaround is to remove (temporarily?) AppImagelauncher
>>> until it fixed ... see end of issue, it was still not done
>>> as of 2 weeks ago.
>>>
>>>
>>
>> Yes, I have also had the impression that Appimagelauncher are
>> old and outdated.
>> So I remove it here, but keep the appimaged installed (?)
>>
>>
>> # zypper se appimage
>> Loading repository data...
>> Reading installed packages...
>>
>> S | Name |
>> Summary | Type
>> ---+-----------------------+----------------------------------------+-----------
>> i+ | appimaged | Daemon handles (un)registering
>> AppIm-> | package
>> | appimaged | Daemon handles (un)registering
>> AppIm-> | srcpackage
>> | appimaged-debuginfo | Debug information for package
>> appima-> | package
>> | appimaged-debugsource | Debug sources for package
>> appimaged | package
>> i+ | appimagelauncher | AppImageLauncher built using
>> CMake | package
>> | obs-service-appimage | Handles source downloads defined
>> in -> | package
>>
>>
>> # zypper se -is appimage
>> Loading repository data...
>> Reading installed packages...
>>
>> S | Name | Type | Version |
>> Arch | Repository
>> ---+------------------+---------+----------------------+--------+-------------------------
>> i+ | appimaged | package | 10-2.1 |
>> x86_64 | openSUSE-Slowroll-Update
>> i+ | appimagelauncher | package | 2.2.0-gha111~d9d4c73 |
>> x86_64 | (System Packages)
>>
>> # zypper rm appimagelauncher
>>
>> -----------------------------
>>
>> /Cin # sh ./bld_appimage.sh
>> ......snip
>>
>> -- Deploying files into AppDir root directory --
>> Deploying files to AppDir root using desktop file:
>> AppDir/usr/share/applications/cin.desktop
>> Deploying desktop file to AppDir root:
>> AppDir/usr/share/applications/cin.desktop
>> Creating symlink for file
>> AppDir/usr/share/applications/cin.desktop in/as AppDir
>> Deploying icon to AppDir root:
>> AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
>> Creating symlink for file
>> AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as
>> AppDir
>> Deploying AppRun symlink for executable in AppDir root:
>> AppDir/usr/bin/cin
>> Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun
>> Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage
>> Running command: /usr/local/bin/appimagetool-x86_64.AppImage
>> "appimagetool" "AppDir" "
>> [appimagelauncher-binfmt-bypass/interpreter] AppImageLauncher
>> not found at /usr/bin/AppImageLauncher, launching AppImage
>> directly: /usr/local/bin/appimagetool-x86_64.AppImage
>> [appimagelauncher-binfmt-bypass/lib] WARNING: could not find
>> preload library path, using temporary file
>> fusermount3 version: 3.16.2
>> execv error: No such file or directory
>>
>> -----------
>>
>> Error and still no AppImage file has been created:
>>
>> /Cin # du -sh AppDir
>> 216M AppDir
>>
>> /Cin # ls -la AppDir
>> total 12
>> drwxr-xr-x 3 root root 4096 Dec 6 11:00 .
>> drwxr-xr-x 31 root root 4096 Dec 6 10:59 ..
>> lrwxrwxrwx 1 root root 11 Dec 6 11:00 AppRun -> usr/bin/cin
>> lrwxrwxrwx 1 root root 34 Dec 6 11:00 cin.desktop ->
>> usr/share/applications/cin.desktop
>> lrwxrwxrwx 1 root root 45 Dec 6 11:00 cin.svg ->
>> usr/share/icons/hicolor/scalable/apps/cin.svg
>> drwxr-xr-x 5 root root 4096 Dec 6 10:59 usr
>>
>>
>>
>>
>> there must be appimage.log in same directory with bld_appumage.sh
>>
>> check it?
>
> Yes, appimage.log is there, but indeed smaller than my own saved
> terminal output to bld_appimage.log
> The tail is identical in both as shown above.
>
>>
>> appimage should appear in same directory, in other words our
>> source tree root.
>>
>>
>> I think something still not installed.
>>
>> squashfstools-ng ?
>
> No such package available; the most similar is the installed
> squashfuse-tools.
> All squash packages available and installed are
>
> S | Name |
> Summary | Type
> ---+------------------+----------------------------------------------------+------
> i+ | libsquashfuse0 | FUSE module to mount squashfs
> images | pakke
> i | squashfs | A Read-Only File System with Efficient
> Compression | pakke
> i+ | squashfuse | FUSE module to mount squashfs
> images | pakke
> i+ | squashfuse-devel | FUSE module to mount squashfs
> images | pakke
> i+ | squashfuse-tools | Squafs Tools for
> squashfsfuse | pakke
>
>>
>> /usr/local/bin/appimagetool-x86_64.AppImage
>>
>> may be this one does have --help parameter?
>>
>> if it allows for setting compression may be rename it new name,
>> and made script calling renamed binary with hardcoded compression
>> argument?
>
> The --help didn't output compression setting. However the Readme
> contains among Application Options:
> https://github.com/AppImage/appimagetool?tab=readme-ov-file#appimagetool---
>
> --comp Squashfs compression
>
>> sorry, appimage does not work on termux or on NetBSD, so I am a
>> bit out of help here.
>
> Yes, I'm stuck and put Appimage file on hold (yet, the AppDir
> binary looked promising)
> -------------
>
>
>
> may be run appimagetool manually with appdir directory as argument,
> like in this question?
>
> https://stackoverflow.com/questions/64564820/how-to-use-appimagetool-to-create-package-to-run-on-older-linux
>
>
> it should output long text saying among other things
>
> "Generating squashfs..."
>
> if this does not work may be try older appimagetool and not latest
> (from 2021 instead of 2023)?
Yes, thanks, the latter worked much better.
I downloaded the absolete, legacy version from 2020, and only 2.07MB
https://github.com/AppImage/AppImageKit/releases/download/13/appimagetool-x86_64.AppImage
and replaced the recommended quite new version since 3 days and 12.1 MB
large
https://github.com/AppImage/appimagetool/releases/download/continuous/appimagetool-x86_64.AppImage
This old one ran bld_appimage without issues:
-- Deploying files into AppDir root directory --
Deploying files to AppDir root using desktop file:
AppDir/usr/share/applications/cin.desktop
Deploying desktop file to AppDir root:
AppDir/usr/share/applications/cin.desktop
Creating symlink for file AppDir/usr/share/applications/cin.desktop
in/as AppDir
Deploying icon to AppDir root:
AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
Creating symlink for file
AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir
Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin
Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun
Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage
Running command: /usr/local/bin/appimagetool-x86_64.AppImage
"appimagetool" "AppDir" "
appimagetool, continuous build (commit 8bbf694), build <local dev build>
built on 2020-12-31 11:48:33 UTC
WARNING: appstreamcli command is missing, please install it if you want
to use AppStream metadata
/home/cinelerra/cinelerra-5.1/AppDir/cin.desktop: warning: key
"Encoding" in group "Desktop Entry" is deprecated
Using architecture x86_64
Deleting pre-existing .DirIcon
Creating .DirIcon symlink based on information from desktop file
WARNING: AppStream upstream metadata is missing, please consider creating it
in usr/share/metainfo/cin.appdata.xml
Please see
https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
for more information or use the generator at
http://output.jsbin.com/qoqukof.
Generating squashfs...
Parallel mksquashfs: Using 20 processors
Creating 4.0 filesystem on cin-x86_64.AppImage, block size 131072.
[=============================================================/]
3122/3122 100%
Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
compressed data, compressed metadata, compressed fragments,
compressed xattrs, compressed ids
duplicates are removed
Filesystem size 92375.82 Kbytes (90.21 Mbytes)
42.67% of uncompressed filesystem size (216509.91 Kbytes)
Inode table size 20123 bytes (19.65 Kbytes)
31.66% of uncompressed inode table size (63565 bytes)
Directory table size 18018 bytes (17.60 Kbytes)
45.57% of uncompressed directory table size (39543 bytes)
Number of duplicate files found 53
Number of inodes 1790
Number of files 1706
Number of fragments 266
Number of symbolic links 4
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 80
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
Embedding ELF...
Marking the AppImage as executable...
Embedding MD5 digest
Success
Please consider submitting your AppImage to AppImageHub, the crowd-sourced
central directory of available AppImages, by opening a pull request
at https://github.com/AppImage/appimage.github.io
/home/cinelerra/cinelerra-5.1/AppDir should be packaged as
cin-x86_64.AppImage
============
~/Applications> ./cin-x86_64.AppImage
......
tested the same tff interlaced hdv09_04.m2t file and rendered it using
hevc_qsv_10b420
.......
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
Render::render_single: Session finished.
** rendered 5972 frames in 29.555 secs, 202.064 fps
audio0 pad 64 0 (64)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20241207/0798de30/attachment-0001.htm>
More information about the Cin
mailing list