пт, 6 дек. 2024 г., 18:12 Terje J. Hanssen <[email protected]>:
> > > > Den 06.12.2024 11:48, skrev Andrew Randrianasulu: > > > > пт, 6 дек. 2024 г., 13:35 Terje J. Hanssen <[email protected]>: > >> >> >> >> Den 06.12.2024 04:32, skrev Andrew Randrianasulu: >> >> >> >> пт, 6 дек. 2024 г., 05:14 Terje J. Hanssen <[email protected]>: >> >>> >>> >>> >>> Den 06.12.2024 01:08, skrev Andrew Randrianasulu: >>> >>> >>> >>> пт, 6 дек. 2024 г., 02:06 Terje J. Hanssen <[email protected]>: >>> >>>> >>>> >>>> >>>> Den 03.12.2024 22:20, skrev Andrew Randrianasulu: >>>> >>>> >>>> >>>> вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>: >>>> >>>>> >>>>> 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 <[email protected]>: >>>>> >>>>>> >>>>>> Den 17.10.2024 13:51, skrev Andrew Randrianasulu: >>>>>> >>>>>> >>>>>> чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected] >>>>>> >: >>>>>> >>>>>>> >>>>>>> Den 14.10.2024 00:38, skrev Andrew Randrianasulu: >>>>>>> >>>>>>> >>>>>>> пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>: >>>>>>> >>>>>>>> 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)? > >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
