V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  othercat  ›  全部回复第 2 页 / 共 4 页
回复总数  75
1  2  3  4  
@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 ,以上。
@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 初学者,如果有一些说话冒犯的,请谅解~
1  2  3  4  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2708 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 16ms · UTC 00:34 · PVG 08:34 · LAX 16:34 · JFK 19:34
Developed with CodeLauncher
♥ Do have faith in what you're doing.