Bugzilla – Bug 1219494
libmfx no longer supported
Last modified: 2024-06-17 22:04:49 UTC
libmfx is no longer supported https://github.com/Intel-Media-SDK/MediaSDK DISCONTINUATION OF PROJECT. This project will no longer be maintained by Intel. This project has been identified as having known security escapes. Intel has ceased development and contributions including, but not limited to, maintenance, bug and security fixes, new releases, or updates, to this project. Intel no longer accepts patches to this project. If you have an ongoing need to use this project, are interested in independently developing it, or would like to maintain patches for the open source software community, please create your own fork of this project. [...] Let's get rid of it, i.e. remove the support from the following affected packages libavfilter7_110 libavutil56_70 libavcodec58_134 --> ffmpeg-4 vlc-noX --> vlc libavfilter8 libavutil57 libavcodec59 --> ffmpeg-5 gstreamer-plugins-bad --> gstreamer-plugins-bad Then drop libmfx package (includes libmfx-samples subpackage).
Submitted changes for ffmpeg-4, ffmpeg-5, vlc and gstreamer-plugins-bad: https://build.opensuse.org/request/show/1143610 https://build.opensuse.org/request/show/1143611 https://build.opensuse.org/request/show/1143613 https://build.opensuse.org/request/show/1143612 Drop request for libmfx: https://build.opensuse.org/request/show/1143614
This is an autogenerated message for OBS integration: This bug (1219494) was mentioned in https://build.opensuse.org/request/show/1143658 Factory / ffmpeg-5 https://build.opensuse.org/request/show/1143659 Factory / ffmpeg-4
At least for ffmpeg, this should be replaced by libvpl (which is available as a package): ~/git_projects/ffmpeg-static/build/ffmpeg-6.1> ./configure --help | grep mfx --enable-libmfx enable Intel MediaSDK (AKA Quick Sync Video) code via libmfx [no] --enable-libvpl enable Intel oneVPL code via libvpl if libmfx is not used [no]
Ignore comment above, libvpl is already used for ffmpeg-6.
(In reply to Michael Pujos from comment #8) > Ignore comment above, libvpl is already used for ffmpeg-6. Yes, this seems to be a new feature in ffmpeg-6. I just checked ffmpeg-4 and ffmpeg-5 and both only support libmfx.
Yes and by removing libmfx in ffmpeg 4 and 5, you removed Intel QSV support in these packages. Since, QSV is available in ffmpeg 6 that might be acceptable, but I'd have kept libmfx for the time being as it still work just fine.
(In reply to Michael Pujos from comment #10) > Yes and by removing libmfx in ffmpeg 4 and 5, you removed Intel QSV support > in these packages. > Since, QSV is available in ffmpeg 6 that might be acceptable, but I'd have > kept libmfx for the time being as it still work just fine. This ticket is about dropping libmfx. So how can I keep it? I'm puzzled. Sure you've read what Intel writes on https://github.com/Intel-Media-SDK/MediaSDK
You can keep it by not dropping it ? It has not suddenly become radioactive or not working anymore just because its github page says it is unmaintained and replaced by the oneVPL library. Anyway, it is not my call to make. Inevitably at least one user will complain that QSV is not working anymore with ffmpeg 4 or 5.
- VLC will not be able to use QSV for decoding - whatever uses gstreamer will not be able to use QSV for decoding - package obs-studio in Packman depends on libmfx. They will have to package it on their own Is it really what is wanted ?
(In reply to Michael Pujos from comment #13) > - VLC will not be able to use QSV for decoding Can't VLC use oneAPI/libvpl instead as does gstreamer-plugins-bad? > - whatever uses gstreamer will not be able to use QSV for decoding I think they can with my change in gstreamer-plugins-bad. Or is oneAPI/libvpl lacking features of libmfx? > - package obs-studio in Packman depends on libmfx. They will have to package > it on their own Ok. I guess they will if needed. > Is it really what is wanted ? I just tried not to ignore the (I think valuable) input by Fabian. Sigh.
Only ffmpeg-6 uses the newer libvpl as a replacement to libmfx. The output of 'zypper se --requires libvpl' confirms it. So removing libmfx dependency to packages other than ffmpeg-6 actually removes QSV support for these packages (gstreamer, vlc, ffmpeg 4 and 5). I do not think this is a good idea and I think this removal of libmfx should be reverted. I suggest to ask relevant other people in charge of the distro for their opinion.
(In reply to Michael Pujos from comment #15) > Only ffmpeg-6 uses the newer libvpl as a replacement to libmfx. > The output of 'zypper se --requires libvpl' confirms it. And this: https://build.opensuse.org/request/show/1143612 I no longer remember the build error message exactly after I removed libmfx, but it told me that either libmfx or libvpl needs to be enabled. So I enabled the latter. > So removing libmfx dependency to packages other than ffmpeg-6 > actually removes QSV support for these packages (gstreamer, vlc, ffmpeg 4 > and 5). Obviously doubt gstreamer, see above. > I do not think this is a good idea and I think this removal of libmfx should > be reverted. > > I suggest to ask relevant other people in charge of the distro for their > opinion. Feel free, but be warned! You may end up as maintainer of libmfx - and this for the rest of your life. ;-)
Yes indeed for gstreamer. I missed the added dependency on libvpl. VLC remains. And obs-studio on Packman, a program for which QSV is popular with streamers. VLC does not have libvpl support. There's this PR but it was not merged: https://code.videolan.org/videolan/vlc/-/merge_requests/3843 From what I understand maybe it will be in VLC 4.0.
Oh wow. Seems to be trivial to switch from libmfx to libvpl. At least with vlc. No idea how hard it would be for osb-studio.
Oh. obs-studio already switched to libvpl with version 30.0 in Dec 2023. https://github.com/obsproject/obs-studio/releases/tag/30.0.2 [...] 30.0 Changes Updated QSV from MSDK to VPL [thyintel] VPL only guarantees support back to the Broadwell platform. Older platforms may not work. [...]
Yes libvpl is conceived as aneasy replacement for libmfx (aka Intel Media SDK). Quoting FFmpeg QuickSync documentation (https://trac.ffmpeg.org/wiki/Hardware/QuickSync): "The library is the successors of libmfx. It will support Intel's platform >= Alder Lake and will add new features. libvpl.so is compatible with MSDK's runtime (libmfxhw64.so) and libmfx.so also has forward compatibility with oneVPL's runtime (libmfx-gen.so)." But there is a big catch ! libvpl is only compatible with >= Alder Lake CPUs (Aka Intel's 12th gen) if the Intel Media SDK (libmfx) is not installed! I could test this on my Skylake (8th gen) laptop with ffmpeg-6 from Packman. The Packam version already removed libmfx and enabled libvpl. I'm familiar with FFmpeg QSV transcoding and could test that the Packman ffmpeg version (compiled against only libvpl) is working fine for QSV transcoding. However, I have libmfx installed. If I rename its main lib (/usr/lib64/libmfxhw64.so.1.35) to simulate mfx not installed without actually uninstalling libmfx, QSV transcoding via ffmpeg-6/libvpl does not work anymore! So by removing libmfx, you are removing QSV support for all Intel CPU below Alder Lake. All of this is confirmed by this chart: https://github.com/Intel-Media-SDK/MediaSDK?tab=readme-ov-file#media-sdk-support-matrix So the legacy libmfx is really needed. Please don't remove it :(.
Long story short: modifying packages to only use libvpl is OK but libmfx must still be installed for QSV to work on Intel hardware below Alder Lake, as libvpl dispatch to it.
>= Tigerlake according to https://github.com/oneapi-src/oneVPL-intel-gpu?tab=readme-ov-file but this doesn't change much. BTW, I haven't updated libmfx-gen since a long time. Indeed it would remove support for a lot of machines still running. Now that we removed the dependancy to libmfx.so.1 in our system, we need to make sure it still gets installed. Otherwise dynamic loading of libmfxhw64.so.1 will just fail. I will appropriate hardware supplements for this.
libmfx drop request revoked > [...] I will appropriate hardware supplements for this. https://build.opensuse.org/request/show/1143787
> BTW, I haven't updated libmfx-gen since a long time. https://build.opensuse.org/request/show/1143789
Yes, libmfx1 must be added as a (x86_64) runtime dependency of packages that are now using libvpl as a compile dependency. However, I could not find a single package that depends on package libmfx-gen1_2 ('zypper se --requires --recommends libmfx-gen1_2' give no result). I could verify that FFmpeg QSV decoding (the Packman version that is already using only libvpl) does not need it. So it is a bit obscure what libmfx-gen1_2 is doing to me. Since you reverted the removal of libmfx, you can also reinstate it for use in VLC (as a compile dep) until enventually VLC supports libvpl.
Ah sorry was not familiar with the Supplement thing. I suppose it will work as expected with either libmfx or libmfx-gen installed depending on hardware.
(In reply to Michael Pujos from comment #26) > Ah sorry was not familiar with the Supplement thing. > I suppose it will work as expected with either libmfx or libmfx-gen > installed depending on hardware. Exactly.
(In reply to Michael Pujos from comment #25) > Since you reverted the removal of libmfx, you can also reinstate it for use > in VLC (as a compile dep) until enventually VLC supports libvpl. I would prefer applying the patch you mentioned in comment#17, i.e. switching to libvpl right now. Best would be to ship only libmfx runtime drivers. Otherwise we'll never get rid of it.
Understood. I suppose you want to get rid of libmfx-devel (and libmfx-sample) so no package try to use it anymore.
I will look into having VLC work with libvpl, assuming it is as easy as the patch suggests.
(In reply to Michael Pujos from comment #29) > Understood. I suppose you want to get rid of libmfx-devel (and > libmfx-sample) so no package try to use it anymore. Yes, but I don't know, whether this is realistic. It might exist a lot of applications/libs in OBS, which still need it (forever?). (In reply to Michael Pujos from comment #30) > I will look into having VLC work with libvpl, assuming it is as easy as the > patch suggests. Thanks. That would be great!
Had a quick try, but build fails against TW currently (but it also fails without my changes! even the version before I removed libmfx support!) https://build.opensuse.org/package/show/home:sndirsch:branches:multimedia:libs/vlc
The compilation failure is caused by taglib. The taglib package was recently updated to v2.0 which is supposed to be source compatible "if no deprecated features are used": https://build.opensuse.org/package/view_file/multimedia:libs/taglib/taglib.changes?expand=1 Would not be surprised VLC uses deprecated features, hence the failure.
https://code.videolan.org/videolan/vlc/-/issues/28502
Thanks. The patch works for me. # for i in $(ls /tmp/build-root/openSUSE_Tumbleweed-x86_64/home/abuild/rpmbuild/RPMS/x86_64/*.rpm); do rpm --requires -qp $i|grep vpl && echo $i; done libvpl.so.2()(64bit) libvpl.so.2(LIBVPL_2.0)(64bit) /tmp/build-root/openSUSE_Tumbleweed-x86_64/home/abuild/rpmbuild/RPMS/x86_64/vlc-noX-3.0.20-0.x86_64.rpm So at least the dep is created. I haven't tested it though.
Will test tomorrow.
(In reply to Michael Pujos from comment #36) > Will test tomorrow. That would be nice. https://build.opensuse.org/package/show/home:sndirsch:branches:multimedia:libs/vlc I also already stripped down libmfx to only package runtlime libs really needed. https://build.opensuse.org/package/show/X11:XOrg/libmfx
This is an autogenerated message for OBS integration: This bug (1219494) was mentioned in https://build.opensuse.org/request/show/1143875 Factory / libmfx
I have tested VLC and it does not work, but as you will see not a big deal. Had to dig a bit into VLC as I'm not familiar with it as I do for FFmpeg. First, the only QSV support in VLC is for encoding, and only to H.264/H.262, which is very limited. In comparison, FFmpeg can use QSV for encode/decode in all formats supported by QSV. The only plugin making use of libvpl in VLC us the qsv encode plugin: ldd /usr/lib64/vlc/plugins/codec/libqsv_plugin.so | grep vpl libvpl.so.2 => /lib64/libvpl.so.2 (0x00007fb2220cc000) Using it for a simple encode to a h264 file fails: ~/Videos> cvlc oceans.mp4 --sout "#transcode{vcodec=h264,venc=qsv}:standard{access=file,mux=mp4,dst=blargh.mp4}" vlc://quit VLC media player 3.0.20 Vetinari (revision 3.0.20-0-g6f0d0ab126b) [000055cbb441f010] dummy interface: using the dummy interface module... [00007fb1a4c06160] qsv encoder error: Unable to find an Intel Media SDK implementation. [00007fb194003e20] stream_out_transcode stream out error: cannot find video encoder (module:qsv fourcc:h264). Take a look few lines earlier to see possible reason. [00007fb194003e20] stream_out_transcode stream out error: cannot create video chain [00007fb194c1ab10] main decoder error: cannot create packetizer output (h264) [00007fb194c1ab10] main decoder error: buffer deadlock prevented [00007fb194004800] idummy demux: command `quit' ///// It fails on "Unable to find an Intel Media SDK implementation" Looking at the plugin code (https://github.com/videolan/vlc/blob/3.0.18/modules/codec/qsv.c), it is the call to MFXInit() that fails. I compared with FFmpeg QSV code and its has libvpl specific init code if it is compiled with libvpl. So for converting a program from mfx to vpl it looks like there is more than an include swap. Or something else I do not know. Anyway, there's no need to spend more time on this, as the number of people using the abysmal VLC QSV support for H264 encoding must be super low, and VLC will probably update to working libvpl support at some point (4.0). And for the one user of VLC/QSV, he can be redirected to use FFmpeg which is much much better.
Thanks for digging into this! So let's not touch vlc any longer due to this change.
(In reply to Stefan Dirsch from comment #37) > I also already stripped down libmfx to only package runtlime libs really > needed. > > https://build.opensuse.org/package/show/X11:XOrg/libmfx Have you tried that? In case your Intel GPU is old enough.
Yes I just tested it (Skylake) and it worked fine. The spec file of libmfx could be simplified, not compiling samples and tools, passing to cmake: -DBUILD_TOOLS:BOOL=OFF (change this one as it is set to ON) -DBUILD_TUTORIALS:BOOL=OFF -DBUILD_SAMPLES:BOOL=OFF I you want to test QSV transcoding with FFmpeg (especially if you have newer hardware, which I do not have), you can do so with: ffmpeg -c:v h264_qsv -i http://bubblesoftapps.com/bubbleupnpserver/transcode_test/tos_sample_h264.mkv -c:v h264_qsv -f null - This will use QSV for encoding/decoding of a small H264 sample file hosted on my server. Looking at the beginning of the verbose output you will see oneVPL (and more) mentioned.
For ffmpeg verbose output: ffmpeg -v verbose -c:v h264_qsv -i http://bubblesoftapps.com/bubbleupnpserver/transcode_test/tos_sample_h264.mkv -c:v h264_qsv -f null -
Thanks. Adjusted libmfx package now. https://build.opensuse.org/request/show/1144149 With that I think we can close this bugreport. Hope I will find some time later for testing also on newer Intel hardware. I think you can even switch the driver easily by env. variable if supported by both - libmfx and libmfx-gen - drivers. Already forgot where I read that. libmfx package may need some cleanup, but this is not that urgent.
(In reply to Michael Pujos from comment #12) > You can keep it by not dropping it ? > It has not suddenly become radioactive or not working anymore just because > its github page says it is unmaintained and replaced by the oneVPL library. > Anyway, it is not my call to make. THe GitHub page says more than just "unmaintained": > This project will no longer be maintained by Intel. > This project has been identified as having known security escapes. > Intel has ceased development and contributions including, but not limited to, maintenance, bug and security fixes, new releases, or updates, to this project. > Intel no longer accepts patches to this project. Especially the "known security escapes" part is something that must be considered. > Inevitably at least one user will complain that QSV is not working anymore > with ffmpeg 4 or 5.
The libmfx runtime is still needed for working QSV support on < Tiger Lake. So it cannot be just removed.
To be clear, I meant oneVPL delegates QSV decoding/encoding to libmfx on platforms < Tiger Lake.
Well, I tried to get rid of it ASAP by removing development files and main libmfx - just still shipping driver lib for "older" GPUs still needed by libvpl. I don't see how I can do more than this. I'm sorry.
This is an autogenerated message for OBS integration: This bug (1219494) was mentioned in https://build.opensuse.org/request/show/1169676 Backports:SLE-15-SP5 / ffmpeg-4
This is an autogenerated message for OBS integration: This bug (1219494) was mentioned in https://build.opensuse.org/request/show/1169721 Backports:SLE-15-SP5 / ffmpeg-4
This is an autogenerated message for OBS integration: This bug (1219494) was mentioned in https://build.opensuse.org/request/show/1180387 Backports:SLE-15-SP5 / vlc https://build.opensuse.org/request/show/1180388 Backports:SLE-15-SP6 / vlc https://build.opensuse.org/request/show/1180389 Backports:SLE-15-SP4 / vlc
This is an autogenerated message for OBS integration: This bug (1219494) was mentioned in https://build.opensuse.org/request/show/1180704 Backports:SLE-15-SP6 / vlc https://build.opensuse.org/request/show/1180705 Backports:SLE-15-SP5 / vlc https://build.opensuse.org/request/show/1180706 Backports:SLE-15-SP4 / vlc
This is an autogenerated message for OBS integration: This bug (1219494) was mentioned in https://build.opensuse.org/request/show/1180919 Backports:SLE-15-SP5 / vlc
openSUSE-RU-2024:0165-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1219494,1223909 CVE References: JIRA References: Sources used: openSUSE Backports SLE-15-SP5 (src): vlc-3.0.21-bp155.2.6.1