@sampeng 主题帖已经写了：我在主力 macOS 机器上有很多 Linux 虚拟机，还有移动硬盘装了很多。

@lolizeppelin 经过和朋友一起研究，总结了一些信息：

1. 类似微软的 DirectX ，Linux 使用 VAAPI 标准用于让应用和游戏开发者方便开发，而显卡驱动则让不同显卡符合 VAAPI 标准即可。不过 mesa 目前主要只有 Intel 和 AMD 的支持。

2. Intel Quick Sync Video 则是 Intel 显卡的硬件功能指标，并且根据 Intel 硬件的发展，提供了不同的 media stack 项目，如 oneVPL ，iHD driver ，MediaSDK ，Libva ，intel-vaapi-driver 等，不同的项目只是针对不同的硬件或者硬件范围进行设计。在 Linux 可以用到所有的项目，但是 Windows 默认 Intel 图形驱动只有 MediaSDK 支持。
3. Runtime 方面，Quick Sync 支持 VAAPI / libvpl / libmfx 不同的运行时，其中 libvpl 是 libmfx 的承接。

上面 2 和 3 可以参考此文章 https://www.intel.com/content/www/us/en/developer/articles/technical/onevpl-in-ffmpeg-for-great-streaming-on-intel-gpus.html

4. 目前我使用 RPM Fusion 的推荐安装，默认使用的 ffmpeg 已经加入了 --enable-libvpl 参数且没有 --enable-libmfx 参数，因此不需要额外重新编译 ffmpeg 了。
5. ffmpeg 的代码宏会进行 oneVPL 的支持，如果调用 ffmpeg 强制指定 oneVPL 作为后端 media stack 支撑，则 ffmpeg 会去寻找对应的 Runtime ，其 Runtime 在默认系统会是 oneVPL-intel-gpu 这个包，不过通过系统升级会更新为 intel-vpl-gpu-rt 这个包，在之前 dispatcher 和 runtime 是分开的，现在 dispatcher 和 runtime 合并了，因此只需要用后者即可。
6. 通过 https://trac.ffmpeg.org/wiki/Hardware/QuickSync 这个页面后面的一些确认和核实，并且我实际使用如下命令转码，通过 intel_gpu_top 发现 GPU 编解码运作正常。
ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -vf 'vpp_qsv=framerate=60,scale_qsv=w=1920:h=1080' -c:v av1_qsv output.mp4

结论：
如今走标准推荐流程 https://rpmfusion.org/Howto/Multimedia 不用特别去考虑 ffmpeg 具体的编译了：RPM Fusion 的 ffmpeg 版本已经预先加入 oneVPL 后端支持，而 Fedora 40 也有对应的调用路径，所以没什么额外需要做的了。

@bianjp 我的问题应该是硬件太新，虽然有 firmware ，也加载了：

[ 5.103687] sof-audio-pci-intel-mtl 0000:00:1f.3: DMICs detected in NHLT tables: 4
[ 5.144950] sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware paths/files for ipc type 1:
[ 5.144953] sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware file: intel/sof-ipc4/mtl/sof-mtl.ri
[ 5.144954] sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware lib path: intel/sof-ipc4-lib/mtl
[ 5.144955] sof-audio-pci-intel-mtl 0000:00:1f.3: Topology file: intel/sof-ace-tplg/sof-hda-generic-4ch.tplg
[ 5.173803] sof-audio-pci-intel-mtl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.9.0.1

但是应该是 firmware 不匹配

[ 12.705960] sof-audio-pci-intel-mtl 0000:00:1f.3: no matching blob for sample rate: 48000 sample width: 32 channels: 4
[ 12.705968] sof-audio-pci-intel-mtl 0000:00:1f.3: failed to prepare widget dai-copier.DMIC.dmic01.capture
[ 12.705970] sof-audio-pci-intel-mtl 0000:00:1f.3: Failed to prepare connected widgets
[ 12.705973] sof-audio-pci-intel-mtl 0000:00:1f.3: error: failed widget list set up for pcm 6 dir 1
[ 12.705975] sof-audio-pci-intel-mtl 0000:00:1f.3: ASoC: error at snd_soc_pcm_component_hw_params on 0000:00:1f.3: -22
[ 12.706074] sof-audio-pci-intel-mtl 0000:00:1f.3: no matching blob for sample rate: 48000 sample width: 32 channels: 4

我目前用小尾巴可以正常用麦克风和声音，考虑到 sof 更新大概就能解决，所以我就临时加了一个参数作为一个 workaround 来解决这个问题了，接下来就是等 sof 更新 sof-mtl.ri 了

sudo grubby --update-kernel=DEFAULT --args="snd-intel-dspcfg.dsp_driver=1"

@lolizeppelin 好的，多谢，我会仔细看看再来回复～
就目前和朋友了解到的知识，也顺便贴在这里～

```
就以编码这个功能来说，显卡端提供了名为 quick sync 的编码器，然后 intel 提供了 media sdk 和 oneVPL 两组 sdk ，上层应用可以选择使用其中任意一种来调用 quick sync 功能。
所以，从用户端来说，你只会使用 ffmpeg ，或者基于 ffmpeg 的应用，但你不需要关心 ffmpeg 是通过哪个 sdk 调用 quick sync 功能的
从用户的角度上说，没有哪个 sdk 更好一点的说法，因为用户不和 sdk 打交道。当然对于我或者 ffmpeg 的维护者来说，oneVPL 确实更好用一些，api 更好用。
```

@lolizeppelin 我觉得这是两件事：
RPM Fusion 是官方人员维护的，这个的确如您所说“官方不能在包里打有版权的东西”，但是至少是有标准文档说明的。
但是 ffmpeg 编译默认不加入--enable-libvpl ，我还在寻求官方文档的支撑，如果您有看到也可以发给我。
前者可以认为是做样子避免法律，后者，只能说我还是需要持续学习。

@lolizeppelin oneVPL 的相关信息我还在学习，针对这个参数，我并没有说使用是对或者错的，我只是觉得需要弄明白这些为什么没有作为默认参数，当然最后结论很可能也是您所说的：“因为不能确定你用的是什么显卡”，只是我需要自己弄明白才可能会去做修改。
也许对您来说很简单的事情，对我来说可能还是需要仔细学习研究，毕竟您已经用 Linux 这么久了，不是么～

@lolizeppelin 我自己给一些金融保险业做的安全运维项目，就是给很多不同的 Linux 服务器自己修改源代码打 rpm ，以上。

@FightPig 16 寸选择 2.5K 用 1.5 倍缩放，我因为目前还是定在了 wayland+gnome ，还没精力折腾桌面和 wm ，只能说根据自己手头的机器，用非整数缩放，一种是字体渲染的效果就不如 macOS 了，有轻微差距（整数倍是比 macOS 好的），另外一个是 x11 的应用，包括 Electron 的 app 的渲染表现就很糟，如我在用 Obsidian 记笔记，就特别明显。所以我就希望能够一个更高分辨率的屏幕，这样我的 UI 就可以更舒服一些。

@lolizeppelin 我个人的一些看法吧
既然选择红帽系，选择 Fedora ，肯定是把具体 Linux 发行版的特点和文化遵循下来，否则我干嘛要用 Fedora ，只是因为命令行和包管理以及权限管理不一样？
红帽系的特点就是标准化，Fedora 能够保证自己的系统一直非常快速甚至被其他 Linux 发行版用户感受到激进的做法，也源于标准化，这个标准化带来了很多思考，如：为什么这个参数默认不会被编译？为什么这个包没有被加入进来？

所以这也是在这篇文章的 Threads 里面，不少和您一样的大佬用户们的建议，我都是先仔细看看，和朋友咨询讨论，然后再考虑如何用一种更合适符合发行版规则的方式去操作。

这样操作的方式肯定会影响性能，但是如果一开始就决定性能优先，可能我不会选择 Fedora ，甚至我也不会选择 Linux 了，因为我连 Mac 上的编译都搞得定，我还怕 Linux😂？

我选择 Linux ，很多时候是在想让自己真正站在 Linuxer 的角度，享受自由世界带来的真正好处，但是很怕自己在这个自由世界，成为 hacker 或者 cracker ，因为后两者的系统虽然是独一无二， 但是那恰恰走入了我不想要的折腾之路，即可能为了一个非标准化的行为，造成了后续升级或者使用新应用产生的另外的折腾，而这种折腾，其实和 macOS/Windows ，没有本质区别。

回到您说的“官方也就做做样子而已....” 我觉得官方并没有做做样子，只是恰好大家在维护者一种标准，而我们也在使用着各种标准，而一旦想要接触一些非标准的应用或服务，又或者自己开发了一些没有那么标准的内容，可能才会发现真正发行版的特点吧。

最后，我还是个 Linuxer 初学者，如果有一些说话冒犯的，请谅解～

@lolizeppelin 嗯，这个 LIBVA_DRIVER_NAME=iHD 刚上手已经加入到了 ~/.config/environment.d/20-vaapi.conf

@lolizeppelin 好的多谢，针对 oneVPL 相关信息，我会先学习学习，之后再来更新～

@lolizeppelin 嗯，其实 Linux 下很多人的做法很多，自己编译然后配置环境变量替换 so 等等，不过我个人还是比较倾向使用官方文档的标准做法，红帽系发行版的特点就是标准化，使用标准的硬件，搭配标准化的系统和发行版，剩下的就是标准化的使用方式和习惯吧，当然这纯粹是我个人看法。

@lolizeppelin 另外补充一下上面说的内容

按照 https://rpmfusion.org/Howto/Multimedia 这个页面的操作对我来说，就是如下的几个行为：
1. 使用标准方式用 ffmpeg 替换 ffmpeg-free ，并且更换一切对应依赖
2. 多出来两个 gstreamer 的包用于 codec 的补完，目前我这里是 streamer1-plugins-bad-freeworld 和 gstreamer1-plugins-ugly

当然那个页面还有一些额外的第三方支持，但是对于 Codec 补完，大约就是上面描述的。

@lolizeppelin 非常感谢，这个话题我下午和朋友仔细聊了聊，他给我介绍一些故事：

```
大概 f36 或者 f37 的时候，fedora 因为法律限制决定移除 mesa 相关包里面的 h264 h265 hevc 这些解码器支持。不过这个只影响使用 amd 开源驱动的用户，intel 和 amd 闭源驱动不受影响，但是相关包的依赖结构变了。
所以很长一段时间，Fedora 很多包在官方仓库和 rpmfusion 都有两个版本。
比如 chromium ，比如官方包的 chromium 有硬件解码支持，但因为其依赖的 gstreamer 也是官方包的版本，所以前面那几个编码格式是不支持的。
然后去年的时候，fedora 和 rpmfusion 把这个解码器相关的包依赖结构重做了，你看到 gstreamer1 相关的包不是替代关系，而是 rpmfusion 把官方没有的包补全了,所以 rpmfusion 就没必要再维护一整套 ffmpeg gstreamer 以及依赖他们的 chromium 这些。
因为我是一路升级上来的，依赖一直是 rpmfusion 那边的，所以没想起来这个事情。你是新安装的，如果没把依赖切换过去就会少一些解码器支持。av1 这些有是因为它版权公开，h264 这些就不行。
```

所以，他让我按照 rpmfusion 那个 multimedia 页面把 codec 补了一下，页面地址 https://rpmfusion.org/Howto/Multimedia

这样我的 vainfo 就比较齐全了。

```
Trying display: wayland
vainfo: VA-API version: 1.21 (libva 2.21.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 24.1.5 ()
vainfo: Supported profile and entrypoints
VAProfileNone : VAEntrypointVideoProc
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointEncSlice
VAProfileVP9Profile1 : VAEntrypointVLD
VAProfileVP9Profile1 : VAEntrypointEncSlice
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointEncSlice
VAProfileVP9Profile3 : VAEntrypointVLD
VAProfileVP9Profile3 : VAEntrypointEncSlice
VAProfileHEVCMain12 : VAEntrypointVLD
VAProfileHEVCMain422_10 : VAEntrypointVLD
VAProfileHEVCMain422_12 : VAEntrypointVLD
VAProfileHEVCMain444 : VAEntrypointVLD
VAProfileHEVCMain444 : VAEntrypointEncSlice
VAProfileHEVCMain444_10 : VAEntrypointVLD
VAProfileHEVCMain444_10 : VAEntrypointEncSlice
VAProfileHEVCMain444_12 : VAEntrypointVLD
VAProfileHEVCSccMain : VAEntrypointVLD
VAProfileHEVCSccMain : VAEntrypointEncSlice
VAProfileHEVCSccMain10 : VAEntrypointVLD
VAProfileHEVCSccMain10 : VAEntrypointEncSlice
VAProfileHEVCSccMain444 : VAEntrypointVLD
VAProfileHEVCSccMain444 : VAEntrypointEncSlice
VAProfileAV1Profile0 : VAEntrypointVLD
VAProfileAV1Profile0 : VAEntrypointEncSlice
VAProfileHEVCSccMain444_10 : VAEntrypointVLD
VAProfileHEVCSccMain444_10 : VAEntrypointEncSlice
```

另外朋友补充了一些内容：
```
目前 ff 和 chromium 的加速处理是不一样的，ff 只用到了解码，但是 chromium 用到了 enhance ，所以 chromium 那个硬解效果要好一些，特别是叠加 b 站弹幕之后，但是估计还没对最新的 cpu 做适配。
```

这个反馈在我这台红米上，就是通过 intel_gpu_top 看到的，FF 解码的确没用到 enhance ，而 chromium 是用到了，但是 chromium 目前显示是花屏，这个估计要等 chromium 对新的 cpu 做适配就好了。

再次谢谢你的信息，至少我现在可以在系统层面使用 H264/HEVC 硬解了（ AV1 是默认支持的）

@vhwwls 同期应该还尝试过 Fedora Core 3 还是 4 ，OpenSuse 好像在 2011 年尝试过，反正都是无疾而终，这次就正式切换了。

@vhwwls 我是从 03 年开始用 Redhat Linux 5.5-6.0 作为双启动用了一年多，那个时候的配置更麻烦，FreeBSD 也用过。05 年主要是工作相关主力换到了 macOS 。其实也就是 18 年之后我觉得 Linux 桌面才算是堪用起来，而且如果身边没有朋友的成功案例，加上 Intel 14 代 U 的确在 45-90W 这个能耗比能用了，所以我才开始决心换了，否则我也是继续观望还是不会出手的。

@huijiewei Intel 14 代 U 加上硬件通过 Intel EVO 认证，加上这台 99Wh 的电池（ 16 寸笔电重量还能保持在 1.8kg)我最近几次全天出去忙事情电源都没用上，常规使用 10-15 小时，如果有时间不用不盒盖，会很快进入到激进待机，这样考虑如果轻量使用 20 小时。
休眠的问题目前没遇到任何问题，只是 165Hz 刷新率下突然发生过 2 次 Night Shift 的色温失控，所以我调整到了 120Hz ，就没看到过类似问题了

@lolizeppelin 嗯，能编译大概是最后一招，我现在是如果用起来对发热，续航，风扇没太多体感的影响，那就暂时先不着急编译，可以等 2 ，3 个月内核主线并入更好的 Intel 驱动就行了。

目前看到是 mpv 通过修改参数设置 vo=gpu-next 以及 hwdec=vaapi ，至少 AV1 可以硬解，而且还支持色彩管理了。之前 vo=gpu 是不支持色彩管理的，具体这篇 https://github.com/mpv-player/mpv/issues/8009 也有一些讨论。

大概这样目前用起来凑合，CPU 的确很强，掩饰了驱动的不足。

@xzpjerry731 感谢分享经验啊～ 我之前用 M1 Macbook Air 使用 Moonlight 串流家里的 N 卡台式机玩游戏，发现其实有些对触摸屏优化的游戏，还是触摸屏舒服，所以我个人觉得最舒服的串流设备：
1. 在家 11 寸以上，在外面通勤 7 ，8 寸（这样串流设备可能是掌机）
2. 高刷屏还是有一些用，可能 90Hz 以上就好
3. 必须触摸屏，有些游戏用鼠标点击太痛苦，需要鼠标串流的游戏就让串流设备接鼠标键盘好了，所以必须是平板
4. 支持 HEVC 或 AV1 硬解码串流，因为 HEVC 和 AV1 其实带宽要求不大，但是 HEVC 对比 H264 的带宽要求区别就太大了（上面提到对比过 B 站同样片子不同编码的尺寸，H264 1GB 大小，HEVC 是 318MB ，AVI 是 285MB ，所以支持 HEVC 编码就可以了

综上所述，没有买其他设备的情况下，在家我用 11 寸 M1 iPad Pro ，在外目前用 8 寸的 iPad mini 5 ，但是 iPad mini 高刷不满足，考虑换一个 8 寸安卓平板设备
扯远了，扯远了😂
简单来说，macOS 串流触摸屏优化的游戏，还是没触摸屏的平板舒服。