пт, 18 окт. 2024 г., 13:48 Terje J. Hanssen <[email protected]>:
> > > > Den 18.10.2024 11:33, skrev Terje J. Hanssen: > > > > > 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. > > > Andrey replied to me in a previous thread: > Hardware acceleration methods Sat, 14 Sep 2024 08:55:11 +0300 > https://lists.cinelerra-gg.org/pipermail/cin/2024-September/008621.html > > >Is there something that prevent typical QSV to be prebuilt in the > CinGG/FFmpeg rpm? > > The ffmpeg not installed on my suse build host. If you how to enable QSV, > I'll change the build script. > > > Is this a "path" we can continue with here? > > > Isn't it so that to apply oneVPL in prebuilt and packaged Cingg, it's > internal ffmpeg has to be enabled with oneVPL? > Please correct me and explain better ...... > There should be another patch I sent both to list and you, it should enable building internal ffmpeg with onevpl if it present on host system ..... can you try it? > > > > > > > >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
