[Cin] Build rpm from current build Cingg and thirdparty fmpeg7
Andrew Randrianasulu
randrianasulu at gmail.com
Fri Dec 6 23:06:12 CET 2024
пт, 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)?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20241207/68ba3aba/attachment-0001.htm>
More information about the Cin
mailing list