lack of the flags answering for --enable-libmfx --enable-memalign-hack Also there is no library for satisfaction of dependences of this (mfx library https://git.videolan.org/?p=mfx_dispatch.git)
Intel Quick Sync Video is available since 2011, it's time to support it in Gentoo
I believe we also would need to have Intel Media Server Studio in portage as a dependency for --enable-libmfx
QSV support is a true nightmare: https://blogs.gentoo.org/lu_zero/2016/10/31/intel-mediasdk-mini-walkthrough/ - Requires outdated and heavy patched libraries. - Requires outdated kernel in order to apply all required patches. (lu_zero is also the mfx_dispacth's mantainer https://github.com/lu-zero/mfx_dispatch) Intel doesn't provide any kind of support on mediasdk community support. VA-API works fine and offers the same performance level. ciao luigi
(In reply to Luigi 'Comio' Mantellini from comment #3) > QSV support is a true nightmare: > Perhaps for the full support of the tools one needs Intel Media Server Studio, but for ffmpeg it says otherwise. "FFmpeg QSV support relies on libmfx" and then "Requriments on Linux: ... or use a recent enough supported system, with the libva and libdrm libraries, the libva Intel drivers, and the libmfx library packaged by lu_zero." see here: https://trac.ffmpeg.org/wiki/HWAccelIntro#IntelQSV Therefore adding it to Gentoo should be as easy as adding libmfx library and --enable-libmfx flag to ffmpeg.
Created attachment 468486 [details] mfx-dispatch-1.21.ebuild With this ebuild QSV library downloaded and built successfully for me.
Created attachment 468490 [details] ffmpeg-3.2.4.ebuild With simple addition of below --- /usr/portage/media-video/ffmpeg/ffmpeg-3.2.4.ebuild 2017-03-20 21:24:35.000000000 +0100 +++ /usr/local/portage/media-video/ffmpeg/ffmpeg-3.2.4.ebuild 2017-03-27 22:39:35.559946221 +0200 @@ -91,7 +91,7 @@ FFMPEG_ENCODER_FLAG_MAP=( amrenc:libvo-amrwbenc mp3:libmp3lame kvazaar:libkvazaar nvenc:nvenc - openh264:libopenh264 snappy:libsnappy theora:libtheora twolame:libtwolame + openh264:libopenh264 snappy:libsnappy qsv:libmfx theora:libtheora twolame:libtwolame wavpack:libwavpack webp:libwebp x264:libx264 x265:libx265 xvid:libxvid ) @@ -169,6 +169,7 @@ nvenc? ( media-video/nvidia_video_sdk ) openh264? ( >=media-libs/openh264-1.4.0-r1[${MULTILIB_USEDEP}] ) snappy? ( >=app-arch/snappy-1.1.2-r1[${MULTILIB_USEDEP}] ) + qsv? ( >=media-libs/mfx-dispatch-1.19[${MULTILIB_USEDEP}] ) theora? ( >=media-libs/libtheora-1.1.1[encode,${MULTILIB_USEDEP}] >=media-libs/libogg-1.3.0[${MULTILIB_USEDEP}] I got ffmpeg compiled with Intel Quick Sync Video. I used QSV as use flag as it seemed more appropriate than less understandable MFX. BTW I was unable to find licence specific for Intel and BSD3 therefore added new one under name BSD-3-Intel in the mfx-dispatch ebuild taken from https://github.com/lu-zero/mfx_dispatch/raw/master/COPYING
Any particular reason why QSV has not been added to portage for new ffmpeg-3.3? You guys know it is mainly used for fast encoding not decoding right?
Created attachment 480106 [details] ffmpeg-3.3.2.ebuild Not only QSV flag is not added but also there is no nvidia flag for ffmpeg. This results in cuvid being installed on PCs with Intel only platforms! Results of USE="-nvidia qsv" emerge ffmpeg (unfixed ebuild) Enabled hwaccels: h263_vaapi mpeg1_cuvid vc1_cuvid h264_cuvid mpeg1_vdpau vc1_vaapi h264_vaapi mpeg2_cuvid vc1_vdpau h264_vdpau mpeg2_vaapi vp8_cuvid hevc_cuvid mpeg2_vdpau vp9_cuvid hevc_vaapi mpeg4_cuvid vp9_vaapi hevc_vdpau mpeg4_vaapi wmv3_vaapi mjpeg_cuvid mpeg4_vdpau wmv3_vdpau Results of USE="-nvidia qsv" emerge ffmpeg (fixed ebuild ) Enabled hwaccels: h263_vaapi mpeg1_vdpau vc1_vaapi h264_qsv mpeg2_qsv vc1_vdpau h264_vaapi mpeg2_vaapi vp8_qsv h264_vdpau mpeg2_vdpau vp9_vaapi hevc_qsv mpeg4_vaapi wmv3_vaapi hevc_vaapi mpeg4_vdpau wmv3_vdpau hevc_vdpau vc1_qsv Please fix it!
Unfortunately, it failed for me. Full report is at https://forums.gentoo.org/viewtopic-p-8184646.html $ffmpeg -hwaccel qsv -hwaccel_device qsv -i his_girl_friday.mpeg -c:v h264_qsv qsv.mkv ffmpeg version 3.3.6 Copyright (c) 2000-2017 the FFmpeg developers built with gcc 6.4.0 (Gentoo 6.4.0-r1 p1.3) configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --docdir=/usr/share/doc/ffmpeg-3.3.6/html --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-O2 -pipe -march=native' --disable-static --enable-avfilter --enable-avresample --disable-stripping --disable-indev=oss --disable-indev=jack --disable-outdev=oss --enable-nonfree --enable-bzlib --disable-runtime-cpudetect --disable-debug --disable-gcrypt --disable-gnutls --disable-gmp --enable-gpl --enable-hardcoded-tables --enable-iconv --disable-lzma --enable-network --disable-cuda --disable-cuvid --disable-openssl --enable-postproc --disable-libsmbclient --enable-ffplay --enable-sdl2 --enable-vaapi --enable-vdpau --enable-xlib --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --enable-zlib --disable-libcdio --disable-libiec61883 --disable-libdc1394 --disable-libcaca --disable-openal --enable-opengl --enable-libv4l2 --disable-libpulse --disable-libopencore-amrwb --disable-libopencore-amrnb --enable-libfdk-aac --disable-libopenjpeg --disable-libbluray --disable-libcelt --disable-libgme --disable-libgsm --disable-mmal --disable-libmodplug --disable-libopus --disable-libilbc --disable-librtmp --disable-libssh --disable-libschroedinger --enable-libspeex --enable-libvorbis --enable-libvpx --disable-libzvbi --disable-libbs2b --disable-chromaprint --disable-libflite --disable-frei0r --disable-libfribidi --disable-fontconfig --disable-ladspa --disable-libass --enable-libfreetype --disable-librubberband --disable-netcdf --disable-libzmq --disable-libzimg --disable-libsoxr --enable-pthreads --disable-libvo-amrwbenc --enable-libmp3lame --disable-libkvazaar --disable-nvenc --disable-libopenh264 --disable-libsnappy --enable-libmfx --enable-libtheora --disable-libtwolame --disable-libwavpack --disable-libwebp --enable-libx264 --disable-libx265 --disable-libxvid --disable-amd3dnow --disable-amd3dnowext --disable-fma4 --disable-xop --cpu=host --disable-doc --disable-htmlpages --enable-manpages libavutil 55. 58.100 / 55. 58.100 libavcodec 57. 89.100 / 57. 89.100 libavformat 57. 71.100 / 57. 71.100 libavdevice 57. 6.100 / 57. 6.100 libavfilter 6. 82.100 / 6. 82.100 libavresample 3. 5. 0 / 3. 5. 0 libswscale 4. 6.100 / 4. 6.100 libswresample 2. 7.100 / 2. 7.100 libpostproc 54. 5.100 / 54. 5.100 Input #0, mpeg, from 'his_girl_friday.mpeg': Duration: 01:31:44.17, start: 0.223733, bitrate: 4784 kb/s Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3], 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc Stream #0:1[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s Stream #0:2[0x1bf]: Data: dvd_nav_packet Stream mapping: Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_qsv)) Stream #0:1 -> #0:1 (ac3 (native) -> vorbis (libvorbis)) Press [q] to stop, [?] for help [h264_qsv @ 0x5585128f7fc0] Error initializing an internal MFX session: unsupported (-3) Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Created attachment 542452 [details] mfx-dispatch-9999.ebuild (In reply to Rajil Saraswat from comment #9) > Unfortunately, it failed for me. Full report is at > https://forums.gentoo.org/viewtopic-p-8184646.html > I actually tried to encode using quick sync, but I failed with the same error You have (more in the forum). I also failed with git version which also add several new Intel platforms (see new attachment), but maybe you or others will have more luck. I think bunder in the forum was right and it all comes down to whether all firmware on your platform works properly or not. Make use to check module options for your kernel version as their names change. In 4.17 it is "i915.enable_guc=2". You may also try "i915.enable_guc=-1" but it almost hanged my desktop, YMMV.
Bumping. There's no good reason not to have the MFX ebuild and ffmpeg with +QSV USE flags in the tree. Intel-MediaSDK is already in the tree.
Official intel guide https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/quicksync-video-ffmpeg-install-valid.pdf
depends on https://bugs.gentoo.org/688192
Awaiting https://github.com/Intel-Media-SDK/MediaSDK/issues/1908
I has got first working version of ported. I'll pulling its when I test ones
Created attachment 604224 [details] media-video/ffmpeg With qsv on x86_64
Created attachment 604226 [details] x11-libs/libva-intel-media-driver
Created attachment 604228 [details] media-libs/intel-mediasdk Dependecies
Created attachment 604230 [details] media-libs/gmmlib Deps to mediasdk
Created attachment 604232 [details] media-video/libva-utils
(In reply to Reva Denis from comment #20) > Created attachment 604232 [details] > media-video/libva-utils 2.6.0
Created attachment 611178 [details] difference between my and standart
It the anyone interested in?
(In reply to Reva Denis from comment #23) > It the anyone interested in? I am. Currently successfully running a locally patched USE +qsv ebuild on my laptop, works great.
Leho Kraav, I've lost access to Intel GPU, so I'm not sure I can help. I also no more interesting in. Feel free to modify my contributions.
*** Bug 778875 has been marked as a duplicate of this bug. ***
See also bug 778875.
Hi all, Has there been any further movement on adding QSV to ffmpeg? I picked up one of Intel's "Alchemist" dedicated graphics cards but it looks like it needs the even newer "OneAPI" along with "libvpl" support baked into ffmpeg Some of the earlier ebuilds such as the intel-media-driver and libva-utils are also required which might be enough to get it working. I will report back in a few days if I have any luck If anyone has any videos they'd like me to test encoding please feel free to provide along with the desired ffmpeg settings. (I plan on using the GPU for purely H.265 encoding but AV1 is also supported)
Intelminer, check it: https://590752.bugs.gentoo.org/attachment.cgi?id=611178 It shows what flags you should add if you want to create custom ebuild
Well, may be it even outdated, thus just shows where to start. I am able to do research and create ebuild but I'm unemployed so I don't have any stimula to do that (I'm supporting AMDVLK in GURU in that time). Also I'm no more have any intel gpu.
@Reva I appreciate being pointed in the right direction. Though I don't have a lot of free time to work on this at the moment. I have gotten the card to work correctly on my home server with a virtual machine (Resizable BAR on AMD Epyc is difficult). I would be happy to offer a Gentoo virtual machine for testing it if that would be useful?
(In reply to intelminer from comment #28) > Has there been any further movement on adding QSV to ffmpeg? I picked up one > of Intel's "Alchemist" dedicated graphics cards but it looks like it needs > the even newer "OneAPI" along with "libvpl" support baked into ffmpeg I also have one of Intel's new dGPU cards. I'll look into packaging the oneAPI stuff, though I am currently a bit busy so this might be a job for December.
(In reply to Andrew Ammerlaan from comment #32) > I also have one of Intel's new dGPU cards. I'll look into packaging the > oneAPI stuff, though I am currently a bit busy so this might be a job for > December. Pull Request is open here: https://github.com/gentoo/gentoo/pull/28365 It would be great if you could test it and let me know if everything works as expected.
> It would be great if you could test it and let me know if everything works > as expected. That was quick! :D Cloned the repo, emerged the new packages and added the vpl flag to ffmpeg. Updated to kernel 6.0.8 to gain DG2 driver support Attempted to run an ffmpeg encode command with "ffmpeg -hwaccel qsv -i [test-file] -c:v hevc_qsv -load_plugin hevc_hw test.mp4" Ffmpeg instantly aborts and reports the following error output [AVHWDeviceContext @ 0x55d547b1bd80] No supported child device type is enabled Device creation failed: -38. No device available for decoder: device type qsv needed for codec hevc_qsv. Stream mapping: Stream #0:0 -> #0:0 (hevc (hevc_qsv) -> hevc (hevc_qsv)) Stream #0:1 -> #0:1 (ac3 (native) -> aac (native)) Device setup failed for decoder on input stream #0:0 : Function not implemented
I added "opengl" and "vaapi" as global flags since it looks like they may be required in places New error [AVHWDeviceContext @ 0x5595659256c0] Error adding a MFX configurationVendorID property: -9. Device creation failed: -1313558101. Failed to set value 'qsv=hw' for option 'init_hw_device': Unknown error occurred
Apparently I'm smart and should be using "mfx" instead of "vpl" :) Swapping ffmpeg's use flags to mfx seems to improve things, but still fails to start encoding. [AVHWDeviceContext @ 0x561595f656c0] Error initializing an MFX session: -3. Device creation failed: -1313558101. Failed to set value 'qsv=hw' for option 'init_hw_device': Unknown error occurred Searching that error seems to lead to a long solution on Stack Overflow saying it's trying to load VAAPI instead of the qsv encoder. Though it's building against Ubuntu 18.04 LTS https://superuser.com/questions/1428442/using-ffmpeg-to-encode-a-video-to-h264-using-intel-quicksync
(In reply to intelminer from comment #34) > > It would be great if you could test it and let me know if everything works > > as expected. > > That was quick! :D > > Cloned the repo, emerged the new packages and added the vpl flag to ffmpeg. > > Updated to kernel 6.0.8 to gain DG2 driver support > > Attempted to run an ffmpeg encode command with "ffmpeg -hwaccel qsv -i > [test-file] -c:v hevc_qsv -load_plugin hevc_hw test.mp4" > > Ffmpeg instantly aborts and reports the following error output > > [AVHWDeviceContext @ 0x55d547b1bd80] No supported child device type is > enabled > Device creation failed: -38. > No device available for decoder: device type qsv needed for codec hevc_qsv. > Stream mapping: > Stream #0:0 -> #0:0 (hevc (hevc_qsv) -> hevc (hevc_qsv)) > Stream #0:1 -> #0:1 (ac3 (native) -> aac (native)) > Device setup failed for decoder on input stream #0:0 : Function not > implemented Just to double check, did you also install oneVPL-intel-gpu? intel-mediasdk provides both a dispatcher and runtime for older intel hardware. oneVPL on the other hand is split, oneVPL provides the dispatcher which can then use oneVPL-intel-gpu, oneVPL-cpu or intel-mediasdk as runtime. This allows you to use the new dispatcher (oneVPL) both with older and newer hardware since it can use intel-mediasdk runtime when older hardware is detected. The other way around should also work, the older intel-mediasdk dispatcher should load the oneVPL-intel-gpu runtime when newer hardware is detected. So with oneVPL-intel-gpu installed it should be possible to use either USE="vpl" or USE="mfx" on ffmpeg depending on which dispatcher you want to use. I would recommend using VPL since it is the newer dispatcher. When oneVPL is emerged with USE="tools" the vpl-inspect command will be installed which you can use to check if everything is detected properly.
>Just to double check, did you also install oneVPL-intel-gpu? I had not. I've now corrected that and re-emerged ffmpeg with vpl instead of mfx as suggested I straced the vpl-inspect since it wasn't giving any output and realized that the GPU had not been initialized by the kernel(!). It looks like enabling "ARC Alchemist" dedicated GPU's currently requires adding CONFIG_DRM_I915_FORCE_PROBE="*" even on 6.1-rc6 I attached a basic monitor after that and verified I'm able to get an accelerated XFCE desktop going (glxgears etc) Re-running vpl-inspect now produces what looks to be a correct output (attached) but both vpl-inspect and ffmpeg seem to want mfx instead? Running ffmpeg with all the dependencies installed, the i915 driver loaded against the DG2 graphics card and even the X server running for "covering all bases" yields this output [AVHWDeviceContext @ 0x5637c7a0dc40] Trying to use DRM render node for device 0. [AVHWDeviceContext @ 0x5637c7a0dc40] libva: VA-API version 1.16.0 [AVHWDeviceContext @ 0x5637c7a0dc40] libva: User requested driver 'iHD' [AVHWDeviceContext @ 0x5637c7a0dc40] libva: Trying to open /usr/lib64/va/drivers/iHD_drv_video.so [AVHWDeviceContext @ 0x5637c7a0dc40] libva: Found init function __vaDriverInit_1_16 [AVHWDeviceContext @ 0x5637c7a0dc40] libva: va_openDriver() returns 0 [AVHWDeviceContext @ 0x5637c7a0dc40] Initialised VAAPI connection: version 1.16 [AVHWDeviceContext @ 0x5637c7a0dc40] VAAPI driver: Intel iHD driver for Intel(R) Gen Graphics - 22.6.3 (). [AVHWDeviceContext @ 0x5637c7a0dc40] Driver not found in known nonstandard list, using standard behaviour. [AVHWDeviceContext @ 0x5637c7a0d6c0] Use Intel(R) oneVPL to create MFX session, API version is 2.7, the required implementation version is 1.3 [AVHWDeviceContext @ 0x5637c7a0d6c0] Error adding a MFX configurationVendorID property: -9. Device creation failed: -1313558101. Failed to set value 'qsv=hw' for option 'init_hw_device': Unknown error occurred Error parsing global options: Unknown error occurred Out of curiosity I rebuilt with +mfx and -vpl instead and got a much longer initialization output which I've added as an attachment
Created attachment 835909 [details] Output of vpl-inspect vpl-inspect output
Created attachment 835911 [details] ffmpeg mfx debug output ffmpeg mfx debug output log
(In reply to intelminer from comment #39) > Created attachment 835909 [details] > Output of vpl-inspect > > vpl-inspect output The log indicates that only the mfx (intel-mediasdk) runtime is found by the onevpl dispatcher: > Total number of implementations found = 1 This can mean that: - oneVPL-intel-gpu is not installed properly, there is a bug in the ebuild, or - There still is a hardware/kernel problem somewhere, or - oneVPL-intel-gpu is not detecting the gpu or does not want to use it for some reason. Which use flags are enabled on oneVPL? Is the arc card your primary renderer, or is some other gpu primary? I don't know for sure, but I can imagine that vpl uses whichever gpu is primary first (this is what VA-API does). If so, then vpl-inspect might not give you the expected output because it is trying to use the integrated GPU (which is probably not supported by oneVPL-intel-gpu, but probably is supported by intel-mediask). You might be able to toggle which gpu is used with the DRI_PRIME=1 variable. Could you also try the following commands and see if they produce sensible output: "vainfo" and "DRI_PRIME=1 vainfo" and "DRI_PRIME=1 vpl-inspect".
>Which use flags are enabled on oneVPL? oneVPL-2022.2.5 is built with USE="X dri drm tools vaapi" media-libs/oneVPL-cpu is not installed, however media-libs/oneVPL-intel-gpu *is* installed, so I assume it's attempting to use the GPU path at least. >Is the arc card your primary renderer, or is some other gpu primary? The intel card is the only card in the system currently. The only other card is an ASPEED 2500 server GPU but I have completely disabled its driver as part of testing the Intel GPU. >Could you also try the following commands and see if they produce sensible output Absolutely. Attachments to follow
Created attachment 835913 [details] vainfo output vainfo output
Created attachment 835915 [details] dri-prime-vainfo dri-prime-vainfo output
Created attachment 835917 [details] dri-prime-vpl-inspect dri-prime vpl-inspect
Hmmm, it still does not detect onevpl-intel-gpu. Could you attach the output of "glxinfo" and "DRI_PRIME=1 glxinfo"? Does dmesg show you anything unusual? Could you try re-compiling onevpl-intel-gpu? Maybe it somehow compiles differently when the arc gpu is actually used by the kernel.
Created attachment 835919 [details] glxinfo glxinfo
Created attachment 835921 [details] glxinfo dri-prime glxinfo dri-prime
re-emerged oneVPL-intel-gpu successfully. No obvious changes in build output Tried ffmpeg with both vpl and mfx modes. Same result as before
Does your kernel succesfully load the HuC/GuC firmware? You can find this information in dmesg, could you attach the full output?
(In reply to intelminer from comment #40) > Created attachment 835911 [details] > ffmpeg mfx debug output > > ffmpeg mfx debug output log Actually, disregard what I said, it seems to be detecting oneVPL-intel-gpu just fine: > Library path: /usr/lib64/libmfx-gen.so.1.2.8 This is the library installed by oneVPL-intel-gpu. I got confused because both things are named libmfx*, sorry about that. The failure must be somewhere else, the ffmpeg log doesn't really show anything obvious. A dmesg log might still be helpful. I think I should maybe rename the mfx flag on ffmpeg to msdk or something. That both packages install a libmfx* makes things confusing when one flag is named mfx. Or maybe we forget about adding two different flags and add one single flag "mfx" which on the older ffmpeg versions (that support intel-mediasdk but not oneVPL) pulls in intel-mediasdk, but on the newer versions (that support both) pulls in oneVPL. Since we can only use one dispatcher at a time, and since both dispatchers can load each others runtime this should be fine. What do you think?
>What do you think? It'd be good if Intel could just unify this stuff out so we aren't flipping switches to "figure out" which library we should be using :( That aside. I've attached my dmesg output. One thing of note is the line [ 3.386917] i915 0000:03:00.0: [drm] Incompatible option enable_guc=3 - HuC is not supported! That one has been present since I got the card working initially (just running an X server) but is apparently harmless(?) according to various comments around Github and others I've seen
Created attachment 835991 [details] dmesg
(In reply to intelminer from comment #52) > >What do you think? > > It'd be good if Intel could just unify this stuff out so we aren't flipping > switches to "figure out" which library we should be using :( > > That aside. I've attached my dmesg output. One thing of note is the line > > [ 3.386917] i915 0000:03:00.0: [drm] Incompatible option enable_guc=3 - > HuC is not supported! > > That one has been present since I got the card working initially (just > running an X server) but is apparently harmless(?) according to various > comments around Github and others I've seen You can get rid of this kernel parameter, this card is new enough that the kernel will load the Huc/GuC firmware automatically. What confuses me though is that it says HuC is not supported, I think it should be supported on your card, but maybe I am mistaken. I think you might be hitting an upstream ffmpeg problem. I have changed my Pull Request as I described in my earlier post, and also added the qsv flag to the older ffmpeg ebuilds. Can you maybe retry with a release ffmpeg version (i.e. not the 9999 ebuild)? Btw, there is another unrelated error in your dmesg: [ 3.066360] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 3.066364] cfg80211: failed to load regulatory.db You can silence this by installing net-wireless/crda
>You can get rid of this kernel parameter, this card is new enough that the kernel will load the Huc/GuC firmware automatically. What confuses me though is that it says HuC is not supported, I think it should be supported on your card, but maybe I am mistaken. That parameter is not specified by the kernel command line but seems to be automatically enabled on certain versions of these Intel GPU's? I'll try the stable ffmpeg version later on today and report back on that one >Btw, there is another unrelated error in your dmesg: There's no Wi-Fi installed in the machine so it should be safe to ignore. I appreciate it though :)
No change with ffmpeg-5.1.2-r1 Attaching output log
Created attachment 836049 [details] ffmpeg-5.1.2-r1 output
(In reply to intelminer from comment #56) > No change with ffmpeg-5.1.2-r1 > > Attaching output log So I dug into this a bit deeper, and it looks like the problem is simply that HEVC hardware acceleration is not yet supported for DG2 in linux 6.1. This explains your error: > [drm] Incompatible option enable_guc=3 -> HuC is not supported! You are trying to use the HEVC quick sync video (hevc_qsv): > Reading option '-c:v' ... matched as option 'c' (codec name) with argument 'hevc_qsv'. Which will not work if HuC (HEVC micro controller) is not supported. According to this phoronix article[1] support for HuC will be added in linux 6.2. [1] https://www.phoronix.com/news/Linux-6.2-HuC-HWMON Maybe you can try qsv with some other codec? In theory you should have no problems with e.g. h264. You can use the intel_gpu_top command from x11-apps/igt-gpu-tools to monitor if the gpu is doing something.
>According to this phoronix article[1] support for HuC will be added in linux >6.2. Ah. That would do it! :) H.264 isn't super useful as it's bigger than H.265/HEVC in file size and AV1 support isn't quite there yet I'll keep an eye out for 6.2-rc1 and report back once that releases however
(In reply to Cursed Silicon from comment #59) > I'll keep an eye out for 6.2-rc1 and report back once that releases however By the way, if you don't want to wait you can download and build the latest 'drm-tip' of the kernel from here: https://cgit.freedesktop.org/drm-tip This is basically the latest mainline release candidate plus the latest drm code that is yet to merged into the mainline kernel. On my system this enables HuC (as well as some other 6.2 features such as basic hwmon support): > andrew@andrew-gentoo-pc ~ % dmesg | grep -i GuC > [ 1.024651] i915 0000:03:00.0: [drm] GuC firmware i915/dg2_guc_70.bin version 70.5.1 > [ 1.039858] i915 0000:03:00.0: [drm] GuC submission enabled > [ 1.039860] i915 0000:03:00.0: [drm] GuC SLPC enabled > [ 1.040294] i915 0000:03:00.0: [drm] GuC RC: enabled > andrew@andrew-gentoo-pc ~ % dmesg | grep -i HuC > [ 1.024654] i915 0000:03:00.0: [drm] HuC firmware i915/dg2_huc_gsc.bin version 7.10.3 > [ 1.511907] i915 0000:03:00.0: [drm] HuC authenticated This is of course all very experimental, so you use it at your own risk. Also, my Pull Request now enables qsv in gstreamer via gst-plugins-bad.
>you can download and build the latest 'drm-tip' of the kernel I'll grab that later today. Thanksgiving in the US is a bit hectic :) I'll report back with my findings
I had some spare time and grabbed the new kernel. I'm not sure if the firmware loading on mine is completely correct. The GuC lines match up, but HuC seems to fail loading the first try? >[ 3.328281] i915 0000:03:00.0: [drm] Can't load HuC due to missing MEI modules >[ 3.328285] i915 0000:03:00.0: [drm] HuC init failed with -5 >[ 3.328720] i915 0000:03:00.0: [drm] HuC firmware i915/dg2_huc_gsc.bin version 7.10.3 It seems to execute after that. But I've been beating my head against a wall trying to get the right ffmpeg settings to invoke the hardware encoder Right now it looks something like >ffmpeg -v debug -init_hw_device qsv=hw -i [input-file] -map 0:v:0 -map 0:a:0 -c:a copy -vf 'scale=w=720:h=480:1:1,hwupload=extra_hw_frames=64,format=qsv' -c:v hevc_qsv -pix_fmt nv12 -sn hevc3.mp4 It feels like I may have conflicting settings, but that's the only set of settings that provides a different error to the default. The error that outputs is >Impossible to convert between the formats supported by the filter 'Parsed_format_2' and the filter 'auto_scale_0' >Error reinitializing filters! >Failed to inject frame into filter network: Function not implemented >Error while processing the decoded data for stream #0:0 Which seems like it's trying to do *something* but some combination of these required settings is conflicting (or possibly it doesn't like the original video file?) Running a much less complex command like the one below to just try and re-encode the file however >ffmpeg -v debug -init_hw_device qsv=hw -i [input-file] -c:v hevc_qsv -sn hevc3.mp4 Results in this output >[hevc_qsv @ 0x55939945d680] Selected ratecontrol mode is unsupported >[hevc_qsv @ 0x55939945d680] Low power mode is unsupported >[hevc_qsv @ 0x55939945d680] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. >Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height This happens on both the ffmpeg 5.x stable and the latest git build
Minor note. The HuC module seems to be wanting the Intel Management Engine (IME) Apparently the HuC is used for encrypted video playback (HDCP) as well as firmware updates and possibly power management? I'm on an AMD Epyc so I'm left out in the cold there. Thanks intel! :( https://www.tomshardware.com/news/intel-arc-firmware-trouble
(In reply to Cursed Silicon from comment #63) > Minor note. The HuC module seems to be wanting the Intel Management Engine > (IME) > > Apparently the HuC is used for encrypted video playback (HDCP) as well as > firmware updates and possibly power management? > > I'm on an AMD Epyc so I'm left out in the cold there. Thanks intel! :( > > https://www.tomshardware.com/news/intel-arc-firmware-trouble This shouldn't be a problem. There was a misunderstanding earlier that caused people to think that DG2 would somehow require an intel processor for some functionality. But this has been clarified here: https://www.phoronix.com/news/Intel-GSC-Firmware-Needs-ME > [drm] Can't load HuC due to missing MEI modules I had the same problem earlier. I fixed it by enabling the CONFIG_INTEL_MEI_* related settings in the kernel. I'm not sure exactly which setting is the one that is required so I just enabled them all.
>I fixed it by enabling the CONFIG_INTEL_MEI_* related settings in the kernel That also fixed it for me And miraculously that *also* fixed ffmpeg(!) Running the following command on a 480p video absolutely blisters through at over 703 FPS on my A380 >ffmpeg -init_hw_device qsv=hw -i [input-file] -c:v hevc_qsv -sn [output-file]
(In reply to Cursed Silicon from comment #65) > >I fixed it by enabling the CONFIG_INTEL_MEI_* related settings in the kernel > > That also fixed it for me > > And miraculously that *also* fixed ffmpeg(!) > > Running the following command on a 480p video absolutely blisters through at > over 703 FPS on my A380 > > >ffmpeg -init_hw_device qsv=hw -i [input-file] -c:v hevc_qsv -sn [output-file] Awesome! Thanks for testing and reporting back. I'll wait a bit on feedback from the media-video and gstreamer projects and then I'll merge the Pull Request.
