[语音播放实现设计讨论] 建议使用ffplay在后台启动子进程播放声音从而绕过浏览器限制

[JavaCS3]

用ffplay可以做跨平台音乐播放 ffplay -nodisp -autoexit docs/assets/showoff-1.mp4。可以在插件active的时候把预先静态编译好的ffplay下下来。目前在NPM上面只看到一个这个https://www.npmjs.com/package/ffbinaries 不过这个会把ff全家桶全下下来。目前来看只需要ffplay就可以了，可以参考https://github.com/eugeneware/ffmpeg-static 用Github Action把各个平台的ffplay静态编译出来。vscode的tabnine.tabnine-vscodeAI代码补全就是这么干的，把预编译好的binary下下来直接执行。

经过调查发现已经有现成的FFmpeg各个平台静态编译版本，可以直接下载：https://ffmpeg.zeranoe.com/builds/
不过静态编译的ffplay大约有60MB，进程启动速度会比动态编译的慢3%

目前调研发现vscode播放音乐的方案大致有以下几种：

1. 调用命令行工具(afplay, mplayer, aplay...)：缺点是不同平台支持的命令行工具不太一样
2. 替换vscode的ffmpeg的动态链接库：nondanee.vsc-netease-music：缺点是每次升级vscode都需要手动修改动态链接库
3. 调用其他音乐播放器客户端的API：缺点就是必须安装相应的客户端程序

解决方案：
在插件初始化的时候，把相应的ffplay静态编译程序（静态编译的程序不依赖动态库，所以只需要一个文件即可执行）下下来，在需要播放音乐的时候直接调用该命令行程序。

[JavaCS3]

@SaekiRaku Updated

[SaekiRaku]

@JavaCS3 感谢！不过 60MB 对于一个插件来说确实不算小了。无论是整合进插件本身，还是启动后下载，个人感觉用户体验都没有很大的提升。因为在执行播放动作前，都需要用户进行操作或等待，并且为了稳定的网络访问，可能还需要镜像服务器。

BTW，我还发现了一个有趣的插件：https://github.com/auchenberg/vscode-browser-preview ，借助 Chrome Headless（本机仍需安装 Chrome，不过我感觉这几乎是大部分程序员的标配）在 VSCode 内嵌入一个全功能浏览器，这样也无需用户手动启动浏览器了，并且插件体积也比较容易接受（vscode-browser-preview 10MB）

[JavaCS3]

@SaekiRaku 其实不需要ffplay打包到插件里。第一次启动插件的时候下载一次即可，只有第一次使用的时候体验会差一点。这个体验跟vscode一些language server插件一样都是运行时下载依赖包。我觉得可以接受。另外由于目前只需要播放音频，启动一个Chrome Headless感觉没啥必要额

[SaekiRaku]

@JavaCS3 Chrome Headless 的优势是不需要所有人都下载前置依赖，劣势是内存占用70MB，远大于 ffplay 的 6MB 内存。我觉得这里的问题是在于权衡用户是更能忍受 60MB 前置依赖的下载时间，还是更能忍受 70MB 的内存占用。

[SaekiRaku]

@JavaCS3 不知道还有没有更小一些的工具，ffplay 还内置了GUI/绘图等操作，而且还有一堆不太需要的解码器。实际情况下，我觉得只需要支持一小部分的音频格式就行了。

---

我觉得用 Golang 处理这件事不错，编写简单、容易维护还跨平台，单纯只解码播放MP3也许可以做到足够小巧。目前的一些简单的检索结果：

• https://github.com/hajimehoshi/oto
• https://github.com/lieff/minimp3

[JavaCS3]

@SaekiRaku 如果你觉得目前的ffplay太大，可以在后续的版本自己重新编译去掉不必要的依赖。oto在不同的平台需要安装不同的依赖库。这种跟底层硬件打交道的东西必须是平台相关的，跟使用的语言无关，即使的语言本身是跨平台的。就像同样一个绘图指令在不同平台实现都是不一样的，需要分别编译，这个坑是绕不过去的。而且ffmpeg是个相对成熟的工具。

[SaekiRaku]

@JavaCS3 这个我理解，不过我不太了解 ffplay 的源码实现，不知道其剔除依赖的工作量有多大。我想的是将平台相关的播放部分和音频解码剥离开，播放部分单独找个小型库，解码部分单独找库，由 Golang 串联起来进行编译，这样可以尽可能的小一些，实现也不复杂，还有一部分自行定制的能力和空间。

[zombie110year]

为什么不让用户提前下好 ffplay，然后在插件配置中指定可执行文件的路径呢？根本不需要把这么大一个依赖和扩展一起安装吧。

Linux、macOS 都有包管理器可以用，还有国内镜像。Windows 有点麻烦，官网下载速度太慢了，60MB 在我这里得下一天。

[fgheng]

@JavaCS3 感谢！不过 60MB 对于一个插件来说确实不算小了。无论是整合进插件本身，还是启动后下载，个人感觉用户体验都没有很大的提升。因为在执行播放动作前，都需要用户进行操作或等待，并且为了稳定的网络访问，可能还需要镜像服务器。

BTW，我还发现了一个有趣的插件：https://github.com/auchenberg/vscode-browser-preview ，借助 Chrome Headless（本机仍需安装 Chrome，不过我感觉这几乎是大部分程序员的标配）在 VSCode 内嵌入一个全功能浏览器，这样也无需用户手动启动浏览器了，并且插件体积也比较容易接受（vscode-browser-preview 10MB）

sdl2好像也可以播放音频吧？而且比较小？

[songzhi]

我觉得最好是像其他基于LSP的VSCode插件那样，用一个原生语言比如C++，Rust写一个服务器，插件和它通信控制它播放声音。插件在安装的时候下载预编译的可执行文件，启动的时候启动它作为一个后台进程。

[ouuan]

可以让用户自己设定播放音频的命令，然后在使用说明中提供一些解决方案？