用ffmpeg向b站斗鱼等推流24小时直播一路踩的坑总结

有关性能

1. 玩客云，随身wifi棒子等，可以用copy模式无压力推流1080p视频
2. copy模式不能加水印（比如播放时间），要加水印必须转码
3. 玩客云，随身wifi棒子等，cpu过弱，无论做何设置均不能流畅转码推流，也就不能加水印
4. 四百元的j4105+4g内存工控机，windows10系统，性能够用，可以软解1080p视频并推流（温度60，cpu占用30-50）
5. 启用j4105的qsv硬解，并不能有效降低cpu占用。

有关无人值守和断流重连

1. 推流码有效期只有5分钟，5分钟后，如果流不断，就会一直有效
2. ffmpeg在推流过程中，有概率卡死并断流，需要人工重新获取推流码并重新推流。
3. 可以监控cpu占用或网卡流量，cpu占用过低，或网卡流量过低，强行关闭ffmpeg并重启ffmpeg可以定程度解决
4. ffmpeg推完一个视频切换到下一个时，或被关闭重启，都会短暂断流，有一定概率被服务端认为重新推流，需要人工重新获取推流码并重新推流。
5. 只要需要人工获取推流码，就不能保证24小时无人值守直播。断流可能出现在任何时间，人不可能看得起。
6. 用爬虫脚本模拟登录斗鱼并自动获取推流码的研究失败了。
7. 用爬虫解析cookie自动登录斗鱼并获取推流码未研究，因为cookie有有效期，仍然不能完全实现无人值守。
8. 最终解决办法是用斗鱼直播助手，启用第三方推流模式。ffmpeg先向斗鱼直播助手推流，直播助手收到流后，自动开播，向斗鱼推送。
9. 网络波动时，斗鱼直播助手会提示”网络错误“并且不会重连。
10. 所以仍然需要监控ffmpeg的网卡或cpu占用，必要时强行关闭并重启ffmpeg，这样斗鱼直播助手就会自动重新推流。
11. ffmpeg命令行参数要加上-ss <开始时间>以便被结束后，能够断点续推
12. ffmpeg-python库，可以获取到视频总长度。通过视频起始播放时间，断线时间和视频总长度，可以计算出断点后起始播放时间。
13. 读取视频总长度很耗时，最好提前读出来存进数据库。
14. 至此，基本上可以实现24小时无人值守。
15. 只是必须要在windows上推流，比较无趣。

有关点播

1. python有pydouyu库用来解析弹幕，可以直接pip install安装。需要一个数据库，存储视频列表和排序。当检测到以#号开头，并且后面是数字的弹幕时，修改数据库中对应编号视频的权重，即可实现点播。
2. 点播结果无法显示在屏幕上，因为ffmpeg命令行方式调用不支持。必须要用c++调用其api才行。
3. 点播结果也无法用弹幕回馈，因为斗鱼现在必须要用api调用才能用程序发送弹幕。而api需要企业资格申请。
4. 我的方式是做了一个网站，对外展示播放列表。

有关无缝切换视频

1. 因为是命令行方式调用ffmpeg，所以视频切换后，会自动重启ffmpeg，这会导致短暂断流。观看者必须要刷新才能看到新视频。
2. 如何实现无缝切换？
3. 有关使用管道方式。管道的原理是开启两个ffmpeg进程，一个读取视频送入管道，另一个从管道读视频进行推流。的确可以实现无缝切换，但当网络中断，需要自动重启ffmpeg以触发斗鱼直播助手的自动开播机制时，无法断点续播，所以排除。
4. 有关使用obs中继推流。原理是搭建nginx+rtmp服务器，ffmpeg推流到此服务器。而后用obs拉取此流，再向斗鱼推流。这种方式也可以实现无缝推流，ffmpeg重启后，obs会向斗鱼推送黑屏或其他自定义流。问题是，当ffmpeg重启切换视频时，obs有时候会获取不到新流并卡死，有时候则会黑屏只播放声音。这个方案并不稳定，而且更加占用系统资源（电脑平需要转码，再转码），所以排除。
5. 有关使用ts格式，拼接m3u文件。理论上可行，但我的文件都是mp4，大且多，都转成ts格式有些代价太大，暂时搁置。
6. 总结：暂未找到适合无人值守的无缝切换视频方案。
7. 还有一个方向，抛弃ffmpeg，使用程序通过obs的obs-websocket插件控制obs。如果能根据数据库内容控制obs切换本地视频以及显示不同文字的话，同样能实现点播和无缝切换的效果。理论上，obs-studio的所有操作，都可以用外部程序控制。但我并没有找到具体细节，仅仅找到了开始/停止推流，切换/删除场景等基本操作。但这远远不够，需要进一步研究。

最终结果

最终还是实现了用python操控obs-studio实现我想要的功能，是个完美的解决方案。

详见我写的这篇：

https://blog.csdn.net/tansuo2005/article/details/130878990?spm=1001.2014.3001.5501