Genteure

话说，如果OCR能支持绝大部分语言，而不是只有英文中文的话。。应该会更实用些？ 毕竟通常情况下，使用OCR都是在不能/不方便打字的情况下。

你好，我是 [录播姬](https://github.com/Bililive/BililiveRecorder) 的作者。 录播姬是解析了 FLV 数据结构，在发现解码参数变动的时候切分了一个文件的。 关于录播姬这个功能的介绍可以看这里: https://bililiverecorder.github.io/website/dev/repair/ （链接只在近期有效，新网站做好之后会移到 rec.danmuji.org ） 具体到这一个问题的修复规则是 [BililiveRecorder.Flv/Pipeline/Rules/HandleNewHeaderRule.cs@10adc77](https://github.com/Bililive/BililiveRecorder/blob/10adc77f9eed6844a199dedae617a49e4cb9f6da/BililiveRecorder.Flv/Pipeline/Rules/HandleNewHeaderRule.cs) 录播姬有提供命令行工具，可以修复已经写入到硬盘上的B站录播文件。 另外一个有自己实现类似功能的项目是 [blrec](https://github.com/acgnhiki/blrec)，是用 python 写的，也可以参考。

连麦的时候主播一侧会断开原推流，重新用声网SDK推流。结束连麦的时候会断开重新推直播姬自己编码出来的数据。 因为编码器不同、编码参数不同，直播流里视频的解码参数也不同，比如最明显的视频分辨率，除了视频分辨率以外还有其他的参数也会变。 如果断开重连足够快，直播服务器会把两个不同的直播流拼到一起发给播放端。数据都是完整的，但是直播服务器与播放端的连接没有断开，于是两段不同解码参数的直播流就拼接到一起了。 ``` 解码参数1 数据 ... 数据 数据 解码参数2 数据 数据 数据 ... ``` 因为各种播放器和 ffmpeg 都只会使用文件最开头的那一组解码参数，播放到连麦部分的时候会用正常直播部分的解码参数去解码连麦部分的视频数据，导致花屏绿屏等问题。 如果有直播服务器给的没有处理过的原始数据的话，可以用我写的录播姬里工具箱的录播修复功能自动修。 可以自动在检测到新的 header 以及参数变动的位置把文件切开，每个文件都可以单独正常播放。 - https://github.com/Bililive/BililiveRecorder - https://rec.danmuji.org/ 我看这个项目好像是用 ffmpeg 录播的，因为 ffmpeg...

能稳定复现吗？是 FLV 文件没有释放？

我复现不了 步骤： 1. `./brec r --bind http://127.0.0.1:2356 .` 2. 添加直播间，点击开始录制 3. `lsof 2>/dev/null | grep flv` - 有输出 5. 结束录制 6. `lsof 2>/dev/null | grep flv` - 无输出

像现在这样全部发送也没有什么太大的缺点吧？接收方反正都要判断一下事件类型，不需要的事件直接忽略就可以了。录播姬一侧实现起来也更简单。

related: https://github.com/hardcodet/wpf-notifyicon/issues/65

直播画质设置的是图里这个选项   它确实不是码率 —— 不是设置 10000 就输出 10000kbps 的文件。 它也不是分辨率 —— 写 1920x1080 进去不会输出 1080P 的文件。 它也不是帧率 —— 写 60 进去不会输出 60 FPS。 它是B站设置的各个画质的 ID。 每个画质对应数字以后有可能会变动，以网站上最新的为准。

因为不同画质它的参数就是不一样的啊，要是都一样那不就没有区分不同画质的意义了 

各个画质的压制参数是B站控制的