QD

录播姬自己的说法应该是静态链接并且最小化ffmpeg代码了。只要是二进制的话我倒是有经验，无非就是调用command罢了~我也是觉得可以先搞搞二进制，方便太多了。

1. 我觉得挺好，直播状态检测或许应该于所有功能分离，只要检测到直播结束，或许其他所有功能都可以直接关闭。 2. 公共逻辑无所谓啦，不太了解xml，不过大部分格式应该可以直接append没毛病的。如果公共逻辑不符合某种格式，简单的覆盖就好。公共逻辑我感觉是不是主要考虑大部分格式都通用，避免重复写就好。 3. 我感觉或许可以，但是应该影响不大吧，哈哈，感觉接口不太消耗cpu，就是需要等待网络IO。目前的程序我运行起来，哪怕记录弹幕，也是基本0%CPU占有率。

我感觉应该没啥区别吧，能用就行。

我看了下他的doc，一个问题是，他只支持x86-linux。然后看了下这些库基本都链接的比如“ffmpeg_sys”这些底层库，然后这些底层库基本也只支持x86-linux。

还真是，我是看了api文档，上面platform只写着linux。 话说，没run成功，啥都设置好了，连build都能成功。但是run之后，哪怕不调用record函数，也会疯狂报错，说XXX.lib找不到，实际上环境变量“FFMPEG_DIR”里都有。。。。没搞懂了，要不你build下试试看，在main里加入`ffmpeg::init().unwrap();`看看能不能run过？

我成功了，就是直接把lib随seam.exe一起放置就可以，然而悖论是，那些lib的总和远比ffmpeg.exe大。。。额，一个`avcodec-59.dll`就73MB了，`avfilter-8.dll`有38MB

那这类似于第三个方案了： > 通过cc库使用静态链接到ffmpeg源代码 也不是不行，bilibili录播姬也是精简的ffmpeg，但是需要很懂ffmpeg的来操刀吧，我是基本只会调ffmpeg cli的水平。需要一个大手。

我感觉让用户自己下载和安装肯定是不太方便的吧，特别是win用户还得搞环境变量，要不然学习[rustdesk](https://github.com/rustdesk/rustdesk/releases)这样，只有大功能更新才放一个标准release，然后做一个nightly pre-release，不停更新这样？而且如果没有大更新或者恶性bug可以不release。 另外，99%的使用者都是WIN使用者，可以考虑只在WIN版本放ffmpeg，其他版本放一个说明让包管理自己安装ffmpeg呗。 至于flv切片，比如M3U8的，一个切片仅有几秒钟，拿来放肯定也是不可能的了，拿来合成，那等同于还要让用户自己再下一个ffmpeg去合成与封装了。 还有一种办法就是，其他平台不知道啥情况，win是放在ffmpeg放在同一个文件夹里就能用，可以考虑添加一个自动下载ffmpeg.exe的功能。release的时候不加入ffmpeg.exe，然后第一次使用会提示没有ffmpeg，然后用reqwest下载ffmpeg？

> 我觉得最后一个办法比较好， windows 用户使用了 record 功能就提示用户可以自动下载, 我们提供速度较快的cdn， 然后 linux 或者 mac 就建议用户自行安装ffmpeg 一种方法是，直接连接到github的[ffmpeg build](https://github.com/BtbN/FFmpeg-Builds/releases/download/latest/ffmpeg-master-latest-win64-lgpl.zip)。这个链接应该是可以一直使用的。好处是，官方build，信任度较高。缺点是，会同时下载ffplay.exe和ffprobe.exe。不过我感觉对于现在的带宽来说，下载30M和100M没啥区别了。 另一种方法是，其他的cdn甚至是自己的cdn。好处是只用ffmpeg.exe，压缩完大概只要30M吧。

解压倒是无所谓，可以直接使用zip之类的库完成，然后自动删掉多余的就好。我是比较推崇尽量少让使用者动手的。 期待server这方面的功能~