从去年10月起，一直帮群友们录制直播录像。现在这套系统已经运行大半年了，还算比较稳定。如果你想自建，可以参考本文的部分内容。
Docker 与直接启动服务相比比较好管理，所以本文介绍的基本都是 Docker 部署方案。
💭 须知挂录播是比较烧钱的，你可能的支出有服务器成本、网盘成本、电费成本、带宽成本、维护的时间成本等等。包括但不限于 b 站会对你的 IP 进行风控，导致录制失败甚至是同局域网下哔哩哔哩加载速度变慢、无法载入视频等。
现在 b 站对于主流云服务商的多个 IP 段进行风控，可能无法用云服务器挂录播了。
📹️ 直播录制现在有很多的基于 ffmpeg 的录制项目可以选择，部分甚至支持多平台。我只有哔哩哔哩的需求，所以常用的有以下两种。
mikufans 录播姬项目地址
使用 Docker 部署 mikufans 录播姬1234567docker run -d \ --name bililive-recorder \ -p 2356:2356 \ -v /path/to/recordings:/rec \ -e BREC_HTTP_BASIC_USER=用户名 \ -e BREC_HTTP_BASIC_PASS=密码 \ bililive/recorder:latest使用宿主机保存录播文件的路径替换/path/to/recordings如果你的容器能被外网访问，建议设置 http-basic-auth
容器运行后，浏览器打开录播姬运行的窗口，打开 设置-高级设置 进行配置，下面是我使用的一些配置，按自己需求修改。
mikufans 直播姬设置设置选项备注分段模式根据时间分段每 60 分保存为一个文件在flv中写入直播信息✔️保存直播信息到 mediainfo 中Webhook V2http://192.168.1.100:2356/recordWebHook这里使用的地址，用于上传插件的参数传递，稍后会提到Cookie********建议设置小号，稍后会提到其他设置默认。然后直接添加房间号就能开始录制了。
blrec项目地址
使用 Docker 部署 blrec1234567sudo docker run \ -v /etc/blrec:/cfg -v /var/log/blrec:/log -v ~/blrec:/rec \ -dp 2233:2233 acgnhiki/blrec \ -c /cfg/another_settings.toml \ --key-file path/to/key-file \ --cert-file path/to/cert-file \ --api-key bili2233--key-file 和 --cert-file 如果你需要 https 可以设置，否则在部署时应当去除。配置文件、日志、录播文件请自行设置到相应的路径中。
blrec 设置设置选项备注时长限制01:00:001 小时分割一个文件弹幕全关flv添加元数据✔️如果需要本地播放或者是剪辑需求，开启这个拖动进度条不会卡顿User AgentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36我直接 Copy 的我电脑浏览器的配置Cookie********建议配置小号，下面还会提到Webhookhttp://192.168.1.100:2356/recordWebHook全勾。这里使用的地址，用于上传插件的参数传递，稍后会提到其他设置默认。
mikufans 录播姬与 blrec 的简单比较mikufans 录播姬blrec界面UI界面较为简洁，详细数据界面基本没有排版房间列表就支持查看封面和实时下载信息，详细界面有一些图表等格式支持暂时只支持 flv 流，未来版本有 hls（咕咕咕？）支持 flv 和 hls 流通知不支持支持主流推送渠道web 文件管理器支持不支持API 接口REST API & GraphQL APIREST API主观网络体验添加房间后，经常会与弹幕服务器断开连接，导致无法及时开始录制首次启动就能加载房间信息的话，录制几乎没有问题。如果上级路由设置了透明代理，可能会导致获取房间失败为什么要设置 Cookies 以及 Cookies 的获取方法结论设置 Cookie 后相当于是以登录用户的身份录制直播，相比于游客录制限制更少，更稳定。
现阶段，b 站会对游客身份（无 Cookies）进行风控。具体表现在：
抓取弹幕时，用户名会被打码处理A****: 晚上好且无法获取头像和 uid 。
无法录制原画画质。
如果你有弹幕或者录制原画的需求，请务必设置 Cookies。
使用 Cookies 的账号可能会被b 站风控，后果可能有：被识别为机器人账号、大会员被冻结、封禁账号等。所以强烈建议使用小号的 Cookes ，切勿使用大号作死。Cookies 十分隐私，泄露 Cookies 相当于泄露账号和密码，所以请勿传播带有自己 Cookies 的日志、文件等。同时 Cookies 具有时效性，有一定的有效期，所以请定期获取新的 Cookies。
Cookies 的简单获取方法登录账号打开创作中心，右键点击查看网页源代码
按下F12-开发者工具，点击network-网络并刷新页面。
点击home，在标头中找到 Cookie ，复制其后面一大段文本原封不动的粘贴到录播姬的配置中。（blrec 支持 cookies 的检查。）
⬆️ 录像上传在我的工作流程中，我先将录像即时投稿到哔哩哔哩，在凌晨将原文件备份至 Onedrive 并释放本地磁盘空间。
上面1小时分段一次的好处就能体现出来，在一场直播下播时，已经有大部分文件已经上传到了哔哩哔哩的投稿系统，视频审核速度更快。
投稿哔哩哔哩在这里，我使用 biliup-for-java 投稿视频。在录播姬设置好 webhook 地址后，主播开播、下播时，相关参数都会被传输到 biliup 中，实现自动化投稿录像。
biliup-for-java项目地址
使用 Docker 部署
12345docker pull mwxmmy/biliupforjavadocker run -p 宿主机端口:80 -v 宿主机路径:/bilirecord /mnt:/mnt --name bup -d --restart always mwxmmy/biliupforjava# 为什么要把宿主机的 /mnt 映射到容器的 /mnt ?# 录播姬通过 webhook 传递过来的是录像文件路径，比如 /mnt/rec/123.flv ，如果不打通 /mnt 的话，biliup 会找不到录像文件导致上传失败。首先在bilibili 用户中登录你需要上传的账号。
然后就可以添加直播间了，在编辑中可以设置一些投稿相关的参数，这里主要着重讲一下文件后处理这个功能，它支持的选项有：
选项备注不删除需要手动整理上传完成后删除不推荐，投稿失败会导致录像丢失投稿成功后删除不推荐，未过审会导致无法补档审核通过后删除较为推荐 ，适合无需保留录像文件几天后删除适合临时使用录制结束几天后移动适合不投稿哔哩哔哩上传完成后移动一般推荐，但是投稿失败需要自行上传审核通过后移动非常推荐，适合投稿+保留文件录制结束后移动(无法上传)适合不投稿哔哩哔哩录制结束后复制复制一份到 NAS投稿成功后移动转码失败或未过审需要自行补投审核通过成功后复制复制一份到 NAS使用审核通过后移动选项，可以将过审的文件移动到另一个文件夹用于 rclone 上传到网盘。未过审的依然在原路径，待人工修复后，再次触发投稿，过审后，文件继续被移动到 rclone 的文件夹中等待上传网盘。
上传至网盘在上一步中，将过审后的录像文件移动到了另一个文件夹，在这里我们可以使用rclone或者rsync将该文件夹上传至远程路径。使用 crontab 在夜间创建上传任务，合理使用闲置的上传带宽。
rclone文档 rsync文档
☁️ 附加服务使用 alist 提供原文件的下载、在线播放。例如奶粉录播站
我自己录的玩意儿也许在这里：TaroREC
🚧 踩过的坑摸鱼中：
上传带宽限制
容器挂载的问题
录播姬与biliup的连接问题
关闭公网访问或者是加auth