如果设计一个新的弹幕文件格式，里面含有什么数据、用什么格式比较合理？

[Genteure]

目前在用python重写，也可以等我的python版本。

Originally posted by @hihkm in https://github.com/hihkm/DanmakuFactory/issues/64#issuecomment-1664284048

---

我一直想给录播姬设计一个新的弹幕文件格式，主要想解决现有格式的一些问题：

• 不记录原始数据可能有想要的数据项没存；记录原始数据的话，在 XML 里保存转义后的 JSON 文件体积膨胀太太多。
• 录制的视频和弹幕时间上有偏差，而且不好对齐，因为：
  • 不确定视频内容和弹幕到底偏差了多长时间（录播姬之后的版本 可能 会解决这个问题）；
  • 没有好用的工具调整文件里的数据，文件里的数据调整起来不方便等。
• 查看内容的体验较差。虽然现在录播姬输出的 XML 加了 stylesheet 可以在浏览器里直接打开，但新版 Chromium _好像_是对文件大小做了限制导致无法打开。

现在格式的优点：

• 内容上兼容多年之前B站主站曾经用过的 XML 格式，因此之前的各种弹幕相关工具可以直接用。

一直以来录播姬输出的弹幕文件很大一部分用户都是直接喂给 DanmakuFactory 转成 .ass 文件了，所以我在考虑现在格式的优点并不是特别重要。并且之后如果设计了一个新的文件格式，可以写个工具转换成原来的 XML 格式。

问题/讨论点：

如果设计一个新的弹幕文件格式，里面保存哪些数据？具体使用什么格式比较好？

我自己目前的考虑：

• 拓展性高：最好能支持以后新增的任意消息类型、以后增删的任意数据字段。
• 数据密度高：现在 XML 里存原始 JSON 转义字符特别多、XML 的转义字符又特别长，导致文件体积非常大。
• 方便查看内容：一个思路是把弹幕查看页面外置，做成一个前端应用。这就要求文件内容在前端解析方便。（因此 sqlite 可能就不能用了，或者用 https://github.com/tomayac/sqlite-wasm ？）

[sieveLau]

关于存储的数据，根据目前各个处理弹幕文件的repo的issue来看

1. uid和用户名似乎是多数用户想要的
2. 弹幕的类型也是常用的字段，特别是直播类弹幕非常需要区别普通、SC和礼物
3. 对于2，衍生出来的要求就是持续时间，毕竟immersive观看录播通常也会要求SC到期消失

以上三个是当前录播姬会输出的内容。剩下的就是（嘴炮）想法了，毕竟没有认真了解：弹幕的位置，就比如说是上下固定，还是左右移动的。

对于格式……其实我对于xml了解不多。现在貌似，比如说vscode，是喜欢用json来存数据的（为什么说这个呢，因为repo主说在用python重构，而python解析json那是相当的爽），存储各种数据都方便，而且增减字段影响不大……不过要考虑到文件大小的话，这个我没有把握说它就一定会比xml好多少。

[lengyanyu258]

感谢 Genteure 大大无比优秀的软件给大家带来了诸多便利！（手动打call）

在我看来，既然都录了几个 GiB 的视频文件了，还需要在乎几十上百 MiB 的弹幕数据大小吗？

当然目前的 XML 格式保存弹幕原始数据确实有一点不妥之处。

• 假如我是相关开发者，对于我来说记录全部且完整的原始数据是刚需，不可能会在未挖掘的宝藏里挑挑拣拣，先全部收入囊中可以不用，但等不知什么时候要用时却不能没有。所以既然接收到的是 JSON 数据，那么直接保存成 JSON 文件就行了，不需要再镶嵌进 XML 中而花费掉大量的转义字符。如果是 XML 文件的话，我个人觉得就不需要 raw 属性了，而是全部展开成 XML 元素的各个属性，当然对于嵌套形式的 JSON 数据又要做转义或其它额外的处理，这在 XML 里似乎不太优雅。
• 对于需要调整文件数据的需求，XML、JSON、SQLite 等格式都能满足，Python 中有实用的工具可以方便地调整。
• 新版 Chromium 确实做了限制，可能超过 10 MiB 就拒绝显示了 现在应该没有了大小限制，即使有，可以切换到 Firefox 浏览器上查看。

个人认为，兼容 B 站的弹幕就是 XML 格式存在的唯一优点。有人说，文件格式要么被设计成对机器友好、要么被设计成对人类友好，而 XML 格式两者都不占。那么用 XML 格式应该怎么存储弹幕数据呢？B 站已经给出了答案——

<d p="29.922,1,25,16777215,1595726203,0,a39f0744,36441903090630661">啊这。。。</d>

将 Danmaku 简化为 d，其他字段的值全部放进 property 简化后的 p 属性中——这样通过去掉所有的语义信息及空格做到了极致的压缩，使得 XML 格式弹幕文件为最小。也许这才是 XML 文件存储弹幕数据的正确方式。

目前通过 DanmakuFactory 转换生成的 ASS 文件大小大约是记录了原始数据的 XML 文件大小的 20%。对于开发者来说文件大小是无所谓，但对于使用者可能就比较敏感，毕竟自己只想要要 p 属性中的数据，又何必拖家带口地背负 raw 属性的累赘呢？如此想来，如果是导出为 XML 格式，那么数据内容必然只与 B 站主站的弹幕数据一致。

如果想用新的文件格式保存弹幕数据，为满足不同的要求，个人认为不至于造个新的格式（增加使用者的负担），在已有的格式中按用途选取即可。比如原始数据保留为 JSON，有 XML 使用需求的再自动导出大幅缩减的 XML 格式，若不想占用太大空间，那么可以将原始数据保存为 SQLite（当然也不至于为节省汉字存储空间而将 UTF-8 编码改为 GB18030 编码），它既方便数据字段的扩展也方便导出为 JSON、XML 等其他格式的文件。

综上所述，个人愚见：

1. 保存所有数据；
2. 如果采用 XML 格式，则将所有数据字段展开存储，比如

   {
       "background_bottom_color": "#E2B52B",
       "background_color": "#FFF1C5",
       "gift": {
           "gift_name": "醒目留言",
           "num": 1
       },
       "message": "统一冰红茶，真柠檬，真青春！",
       "message_font_color": "#72110E",
       "price": 100,
       "rate": 1000,
       "time": 300,
       "ts": 1690032220,
       "uid": 99452737,
       "user_info": {
           "uname": "miaomiaomiao来啦",
           "user_level": 10
       }
   }

   展开存储为

   <sc uid="99452737" ts="1690032220" time="300" rate="1000", price="100" message_font_color="#72110E" message="统一冰红茶，真柠檬，真青春！" background_color="#FFF1C5" background_bottom_color="#E2B52B">
     <user_info user_level="10" uname="miaomiaomiao来啦" />
     <gift num="1" gift_name="醒目留言" />
   </sc>

   （改得我有点恶心）由于数据格式进行了修改，许多依照以前格式解析的工具可能也要进行相应的改动。

3. 如果是 JSON 储存，则直接原样保存即可。
   • 当然为了与之前的生态进行兼容，可能需要提供自动导出 XML 格式的功能（XML 格式的存在仍是刚需）；
   • 十多年前 B 站选择了主流的 XML 格式作为数据交换的媒介，这有着当年的时代特征。假如 B 站今年才成立，在新时代下它会选择什么格式呢？我想应该会是 JSON。
4. 如果采用 SQLite 存储，则需要提供相关的工具：
   • 自动导出生成与 B 站主站弹幕一致的 XML 格式文件的开关选项；
   • 自动导出保存着原始 JSON 格式文件的开关选项；
   • 软件内提供方便扩展数据字段的工具，比如给所有弹幕添加某个属性，或给某个 UID 所发送弹幕的某个属性设置为某个值（也许不能指望大伙儿再自行下载 SQLite 数据库软件学习 SQL 相关知识进行读写操作？）；
   • sqlite-wasm 确实不错，但需要做到开箱即用可能比之前的 XML 直接打开要麻烦一点：
     • 将相关库文件保存在软件源目录中；
     • 每个录制的目录下生成 index.html 文件读取当前录制的弹幕数据库？
     • 通过软件打开前端界面，拖动弹幕数据库文件以读取显示相关文档数据？
     • 优点是界面可以变得更华丽好看，还能添加直播流水统计等功能。
   • 怎么处理视频文件的分段？
     • XML 与 JSON 格式可以很直观且方便地进行分段与合并，danmaku_tools 是一个很方便对 XML 数据格式进行处理的工具。
     • SQLite 有必要随着视频分段吗？
     • 分段后再进行合并又会比前两者稍麻烦一点。

暂时考虑这么多，非常感谢 Genteure 大大在软件功能上的开发工作！

[hihkm]

大大好，上面两位大佬的方案我觉得已经是很完美了~

• 如果要考虑保留原始数据，而且不考虑向前兼容性的话，我认为直接用json，接口给啥存啥，只保留原始数据就可以了（可以适当剔除一些无用的字段)，官方的格式这么久了并没有什么大改，直接使用我觉得很合适。
• 如果要追求数据密度，或许可以考虑一下protobuf~但是可读性几乎就没有了。
• 对于查看和调整内容，想不出什么比较好的方案，做成一个前端应用或者直接集成在录播姬里面也可以说是很方便的了~
• 又或许... csv?

[Genteure]

最近也和其他人在各种群里有一些讨论，暂定的是用 JSONL 作为文件格式，即每行一个 JSON 文本。可能会选一个自定义的文件后缀（而不是直接 .jsonl）。 也有人提出用 CBOR，如果后续觉得有需要的话也可以作为另外一个选项，数据结构和 JSONL 的保持一致即可。

讨论后感觉使用文本格式、保持“记事本可读性”还是挺重要的一个点。要数据密度的话可能流式 gzip 输出成 弹幕.xxx.gz 文件更合理一些。不过之前录播姬导出的 FLV 数据文件出现过 gz 文件无法正常解压的情况，等实际实现的时候还需要多测试测试。

我目前考虑的是每个弹幕都记录发送的绝对时间，比如 unix 时间戳。在文件最后记录参照时间点，弹幕的时间减去参照时间点就是弹幕在视频中应该出现的时间。主要是方便对齐弹幕和视频内容，因为弹幕写入到文件的时候可能还不能确定与视频的时间关系，需要事后再计算。如果在内存中缓存弹幕数据等到得出结论再写入，又有可能使用过多的内存。

[Genteure]

更新：现在B站直播的弹幕连接加了风控，弹幕数据不全也不可靠了，设计新格式这个事应该就不做了。。