[Cin] Build rpm from current build Cingg and thirdparty fmpeg7
Andrew Randrianasulu
randrianasulu at gmail.com
Fri Dec 6 11:48:19 CET 2024
пт, 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?
appimage should appear in same directory, in other words our source tree
root.
I think something still not installed.
squashfstools-ng ?
/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?
sorry, appimage does not work on termux or on NetBSD, so I am a bit out of
help here.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20241206/5bde5dd9/attachment-0001.htm>
More information about the Cin
mailing list