@w568w

> 例如，LocalSend 的协议实现就是纯 Dart 编写的。

是啊，都能看到 LocalSend 的协议实现是纯 Dart 编写了，其实也可以大概判断出如果不用这些协议，使用其他 SSDP 到底是自己造轮子方便，还是借鉴代码方便了吧。

> 协议层可以就在这里。请不要把 Flutter 当成 HTML 那样的前端标记语言，它没有什么「主程序」、「前端」、「后端」的概念，编写一个操作系统模拟器都不在话下，实现一个网络协议还是非常容易的。

我说的协议层指的是 cocoapods 包这些东西，核心在这里，而不是 LocalSend 代码。简单来说，我 WireShark 抓包的内容，并不在 LocalSend 主程序实现，而是在 cocoapods 里面实现的
具体而言，可能是 https://github.com/localsend/localsend/blob/main/app/macos/Podfile.lock 这里面的

```
Reachability
network_info_plus
connectivity_plus
```

等等。

如果这些东西两者调用实现都不同，而仅仅是中间层调用 API 相似，这。。。

@w568w 补充一点我自己个人的猜测，仅仅是猜测：

作者是基于 LocalSend 的代码结构还有设计思路，自己修改了 UI ，同时自己实现了他描述当中的核心功能协议替换。

另外大家逆向的看到的主要还是基于 Flutter 打包的结构，这个结构可能写的规范的人都差不多，很难证明什么。

@w568w 没有打烟雾弹，只是描述一个事实。因为 Flutter UI 实在太好替换和借鉴，而 LocalSend 的代码结构说实话因为写的太规范，所以也可以认为有规范的人都可以写的相似。

目录结构现在我只看到大家借鉴的是主程序部分，但是主程序说老实话，只有 UI ，因为协议层都不在这里。

因此这部分我仔细看了一下引用的几个核心网络层面 Framework 的实现，其实有很多和 LocalSend 引用的不同，当然因为闭源很难证明，我也没精力和兴趣去证明。

我只想表达，协议层面自己造轮子实现，如果用 LocalSend 的代码二次开发，可能会更痛苦。

@Goooooos 所以我只是说关键代码不是基于 LocalSend 修改，因为协议层实现比 UI 还是要复杂得多（当然不一定比 LocalSend 更优雅或者安全）

我相信通过替换 Framework 可以直接使用，应该是有借鉴 Flutter 层面相关代码的，但是由于关键功能的协议层自己有实现，因此作者认为自己没有抄袭可能也有他自己的道理。

我把最新的发现更新在了这个帖子

https://v2ex.com/t/1052440

我觉得 Airclap 代码关键部分可能不是基于 LocalSend 改的。

不好意思，上面两张图顺序贴反了，不过不影响结论～

偶然看到这篇，好奇做了一个实验：

我把 Mac App Store 目前的 1.2.0 版本的 Airclap ，app 里面所有 Frameworks ，全部复制到我 1.14.0 的 LocalSend app 进行取代，见图 1
https://www.dropbox.com/scl/fi/6gzbwgvdoauktcsc7b5ts/LocalSend-with-Ariclap-Frameworks-20240625-121141.png?rlkey=69aw9r81c7krxbkd4c36rzpio&dl=0

然后直接打开这个复制后的 LocalSend app ，就神奇的得到了一个 1.14.0 版本的 Airclap 😂 ，见图 2
https://www.dropbox.com/scl/fi/tckxnniqo7sf1mk1q42br/LocalSend-with-Ariclap-Frameworks-20240625-120908.png?rlkey=d3utc61mle70b1lax5lkp9nh6&dl=0

只能说，很有趣～

@cluefly @waahii 想请教一下两位大佬关于 Firefox 如何开启 视频硬解码的 VideoEnhance 增强效果啊，我现在在 Fedora40 下 Chromium 是支持 VideoEnhance 的，如图下面 VideoEnhance 那一条，但是 FF 是不起用的。

https://www.dropbox.com/scl/fi/v5bjqa7u09ntwlwinxwkh/VideoEnhance-on-Chromium-under-Fedora-40.png?rlkey=7xqb2t50haxfmk8qieafqfdj8&st=8jevxjg9&dl=0

@jheroy 另外微信 QQ 如果是用 Android 手机，用 scrcpy 直接作为一个屏幕在 Linux 上就很简单了，我在 macOS 上也是用 scrcpy 来控制的。所以想想选择 Linux 笔电,主力手机换成 Android 手机， 大概也没有微信/QQ 的烦恼了吧😃 不过我短期还是习惯 iPhone 了。

@jheroy N 卡 Linux 只能用于 AI 了，版权相关的问题太难处理。
关于 Asahi Linux 可以参考我 12 楼说的，而且我这台续航并不比 M1 Macbook Air 差，这个还是得益于 Intel EVO 标准的原因。
“ 最新的进度大概是 H264 一年内有望，只是如今串流的核心是 HEVC ，拿 B 站的编码来看，同样一部片子，H264 1GB 大小，HEVC 是 318MB ，AVI 是 285MB ，局域网串流使用 HEVC ，无线带宽的压力是大大减少的。所以 HEVC 的硬解啥时候能在 asahi 成长呢，那个时候恐怕 Intel 16 代，17 代 U 都出来了😂”

另外我为什么要保留 M1 的 Macbook Air,还有一个原因是接下来的 macOS18 的 iPhone Mirroring 功能，所以以后一个场景就是，在家 M1 的 Macbook Air 通过 iPhong Mirroring 连接到 iPhone, 我的红米 Linux 笔电通过串流访问 Macbook Air 屏幕，这样就可以使用 iPhone 了，如果 M1 的 Macbook Air 装了 Asahi,那我的 iPhone 可能真的在家用就很烦了。

@jheroy 我个人觉得，拿现有硬件强行上 Linux 肯定会有各种问题，或者就是无止尽的折腾。我只能通过 LiveCD 尝试能够接受的硬件，然后再通过 7 天无理由之类的（不激活 Win 的笔记本一般都可以 7 天无理由）方式去试用，这样硬件问题给你的折腾就好了。
再说软件，其实 GUI 软件的更新肯定 Linux 不如其他的，但是 GNU 工具 一定是 Fedora 或 Arch 比较积极更新，所以这个还是要看到底常用的工具是 GUI 还是 CLI 的 GNU
如果都比较依赖图形界面，或者大部分都是国产桌面软件，其实 Mac 和 Win 的确是首选。我是因为我还能留一台 M 芯片的 Macbook Air 和我 iPhone 做同步，所以我之后就是 Linux 桌面加上虚拟 Win 用专用图形应用，配合 M 芯片的 Macbook Air 一起的。
至于开源编辑器是 Mac 上的好用，这个事情可能每个人都有自己的判断，为了一些特定软件留在一个操作系统当然是很正常的。
最后 Wayland 支持的软件太少，目前我还在研究，因为大部分都用浏览器或者命令行，整体没有看到太多的而问题。
X11 不支持非整数倍缩放，是的这个是问题，只能说少用 X11 吧，哈哈

@webfrogs 用 Linux 开发对我来说其实只要 ssh 之类的就足够了，我现在说 Linux 主力意味着就是桌面系统也要换了，主要还是日常使用的一些应用。

@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 ，以上。