V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

爱意满满的作品展示区。

这是一个创建于 3600 天前的主题，其中的信息可能已经有所发展或是发生改变。

[ACFUN/BILIBILI]

利用磁力链接网络，实现去中心的弹幕视频体验

（以及改装成聊天室、论坛、匿名版等等）？

最近国内著名弹幕网站ACFUN和BILIBILI都因为版权问题受到困扰。
因为其他网站需要独占，很多视频因此404，弹幕服务也自然unavailable。
缺少良好的整合的弹幕体验，对于弹幕上瘾的御宅一族来说是个不小的困扰。

在这个时候我又把箱子底的这个想法翻出来——分布式的弹幕服务。
把C-S模式的ACFUN与BILIBILI的弹幕中心服务器，打散分布到因特网上。
一方面弹幕本身是版权中性的，不应，一般也不会受到连坐；
另一方面一个个节点无从下手，版权方等等也难以破坏其服务。

以下是服务的协议概要，应该指出，这是一个高度模仿BT/Magnet协议的方案。
但弹幕内容是随时间延长的，这与一般BT资源的长度与哈希不变特点不同。
因此这个服务是应该是健壮和抗攻击的，但是对完整和及时性较宽容。
此外这个服务还可以进一步改造成为成为聊天室、论坛、匿名版等等。

我的联系方式： [email protected] ，欢迎联系我。
项目小组： https://github.com/OpenDanmaku/ ，欢迎加入。
里面有个早期项目OpenDanmaku，是个C-S模式的磁链弹幕服务器/客户端。
测试页面在opendanmaku.github.io上。

以下正文。

《分布式网络的弹幕通信协议概要》

这一协议试图实现一个分布式，去中心，持久化的弹幕广播系统。
以下是该弹幕网络实现的基本思路，未说明部分请参考现有P2P协议:

一、组网

任意磁链将其sha1经某双射函数f(x)变换，其结果(一条伪磁链)用作弹幕信道标识。

注：这个双射函数，也就是一一映射，是利用了sha1难以近似碰撞的特性。
难以构造sha1相似的资源的另一重意思是，正常情况下两个资源sha1相似更不可能出现。
因此我们可以使用一个恒x!=f(x)的函数，来为这个资源创造唯一的弹幕频道
这样的函数有很多，比如f(x)=x+Const，按位取反，等等
比如我验证过网上的2012年海盗湾存档，160万条里不存在只有最后一位不同的磁链。
因此完全可以对这个40位16进制数的最后一位做凯撒密码变换（比如0-E变成1-F，F变0）
每个资源磁链都可以构造15个弹幕信道，也完全可以根据弹幕信道名还原对应资源的磁链。

以伪磁链为标识，利用一般BT协议来联结支持弹幕扩展的客户端，组成弹幕通信网络。
因此，弹幕信道成功组网。扩展协议与BT协议高度相似，具有DHT/PEX网络的一切特性。

注：一般的BT/Magnet网络都能通过btih（种子的哈希）来搜索拥有相同资源的peers。
弹幕信道也是一种资源，其URN自然也可以通过普通的BT/Magnet协议搜索。
这一步不使用独立的协议是因为需要利用现有的巨大BT网络帮忙搜索，不然客户端太少难以组网。

二、发布

每条弹幕以其哈希值作为弹幕消息标识，弹幕应当封装随机用户UUID与发布时间戳用以除重。

注：也就是说弹幕由{用户生成的UUID自我标识,发布时用户本地机器的UTC时间，正文}组成
然后对这一条弹幕做哈希，生成的GUID是这一条弹幕的标识。

扩展协议以仿BT的HAVE报文宣告它发布了新弹幕，其中弹幕哈希代替了HAVE报文的片段下标。

注：一般BT协议HAVE报文是说，这个种子分成的###片之中，我已有了第$$$片。
但是弹幕池是不断延长的，而且网络分布化之后给每条弹幕排序会频繁出现不一致。
因此我们只用弹幕的GUID做标识，每当产生一条百余/数百字节的弹幕。
产生一条16字节的哈希（当然还可以截断使之更短，以节省网络流量）。
然后用与原始BT/Magnet协议相似的方式宣告自己HAVE这条弹幕。其他基本相同。

支持弹幕扩展的客户端有义务接收并储存新的弹幕，接收完毕后也应发布新弹幕的HAVE报文。
客户端有义务接受没有的弹幕，应当定时宣告HAVE所有所存弹幕，应当频繁宣告近期弹幕HAVE。

注：事实上如果有专门的peer做日志服务器，普通客户端的储存和分享义务是低必要性的。
但是为了弹幕网络的健壮性可抗攻击性，这个义务必须至少声明出来。
在具体实现上，可以允许客户端判断，在网络环境良好，用户多且活跃的情况下，
根据时间的久远性，通过协商或者随机的方式，删除自己储存的部分历史弹幕。
这一过程称为风化。尽管有吸血之嫌，但是可以降低普通客户端的存储与带宽压力。

因此，以上流程保证经过充足的时间，每一条弹幕都能知会到每一个在线时间足够长的客户端。

注：也就是说，有的弹幕只有部分人收到，并且这些人关机之后再也没有人收到。
因此这一条弹幕最终没有保存在弹幕网络之中，这一现象称做湮灭。
还有的弹幕很晚才被每个人收到。不过因为对于完整和及时性较宽容，这两点其实无所谓。

三、传送

拥有弹幕的客户端接到请求有义务传送匹配的弹幕，弹幕可以用任何协议加密(鼓励)或不加密。

注：除非弹幕有触发网关的关键词或者个人信息，否则加密意义不大，毕竟是公开发布的。
但是这里仍然鼓励使用普通、多样、安全的协议传输，目的是增强P2P健壮性。

为了防止长度扩展攻击，弹幕在封装的正文之后，应当有统一、明确、长度恰当的结尾标识符。
为了混淆，必要时发送方可以在结尾标识符后面添加随机字符，但没有明确必要时不应这么做。
为了防止一般碰撞攻击，接收方应当检查接收消息的哈希是否匹配，并从结尾标识符处截断。

注：据说SHA1是扩展攻击不安全的，即在正文之后可以添加某些特殊字符串而不影响SHA1
另一方面应对网关过滤哈希，那么定义一个EOF也不算全无意义的。

因此，以上流程保证，弹幕能够安全、准确、可靠地传达到请求者的手中。

注：这是说，只有客户端知悉这一弹幕的存在并请求，才能确实获得无错的正文。

四、弹幕

一般情况下，弹幕正文应当用json封装，包括播放时间、显示位置、特效类型、显示文本四要素。

注：也就是类ACFUN弹幕，不过uid和timestamp已经提到正文之外（与正文地位并列）了。
这一点不需要重复造轮子，只要是ACFUN/CommentCoreLibrary兼容格式就好。

但是弹幕也可以封装其他信息，标准应当容许二次扩展，比如适用于漫画的页数、坐标、字号要素。

注：例如有妖气、微漫画的按页漫画吐槽，轻小说文库按行轻小说吐槽，还有纯音乐弹幕等

同一视频有多个磁链对应不同压制和字幕，可封装对其他弹幕池的引用，各分镜片段时间偏移量。

注：这是用来对付同一视频，但来自不同录制源，不同字幕组，压制不同，视频合集等情况。
因为以上原因，同一视频不但哈希不同，还可能出现起始点差数秒，插入广告等时间轴问题。
解决方案是，不同视频先进行文件地址引用：<btih1[:filename1]>:<btih2[:filename2]>
接下来指出共同的片段：<video1_time01,video2_time01,duration01>,...,
这些片段中的弹幕由两视频共享，注意尽管片段结束了，共通弹幕可能还在书写中，可予宽限

注2：关于共同的片段，当然可以人工设定，但也可以由软件识别产生。
事实上可以通过对视频进行分镜切割，并记录每个首帧哈希（比如SURF，SIFT专利没过期）
将这个序列作为视频内容标识码，作为匹配同源视频的模糊搜索凭藉。
不过如何实现和怎样提高识别率比较复杂，大概需要单独开一贴讨论，这里就不谈了。

弹幕可以用作对其他弹幕表示支持/反对，这时应当封装对方弹幕哈希、对应用户的UUID及态度。

注：即云屏蔽。和弹幕池引用一样都是不可见弹幕。用来给弹幕和弹幕池引用做好评、差评。
弹幕正文中，特效类型可以给不可见弹幕保留一个标志，然后在显示文本里记录这些信息。

普通弹幕被支持可放大字号改变颜色，被反对则可缩小及屏蔽，弹幕池引用如广受支持可自动开启。

注：受到反对的弹幕会缩小字号、甚至屏蔽。差评越多越小。客户端可连坐此作者的其他弹幕
也可对支持的弹幕给予好评，不过放大字号可能影响该弹幕视觉效果，由客户端自己决定方式
对恰当的弹幕池引用应当给予好评，这样其他人能够默认开启这个弹幕池引用，看到更多弹幕
在观看时，弹幕池引用被全程使用的，客户端可以自动生成好评,因为用户可能不会主动评价。
对于捣乱的弹幕池引用，差评多于好评的当然关闭。客户端可设定关闭好评不够多的引用。

改装成聊天室、论坛、匿名版相比容易的多，不赘述。

第 1 条附言 · 2015-02-11 14:39:06 +08:00

QQ群417216334
欢迎讨论

幕

弹

协议

40 条回复 • 2021-05-08 23:10:23 +08:00

cnbeining

2015-02-11 13:38:26 +08:00

也就是弹弹play的模式，但是准备做开源。

意义很重大。。。

yanke

2015-02-11 13:39:21 +08:00

想到一块了！

schezuk

2015-02-11 13:49:24 +08:00

@cnbeining Long time no see! 谢谢你的帮助！

Dandan Play其实蛮好，就是担心C/S架构容易吃亏。

schezuk

2015-02-11 13:49:59 +08:00

@yanke 有意合作吗？Contact me, please!

ZombieMisaka

2015-02-11 13:59:26 +08:00

昨天就在想这事！！但是想想，必须开源，去中心化，这就导致弹幕管理难度加大。。。

schezuk

2015-02-11 14:05:35 +08:00

@ZombieMisaka 这里设计了一个弹幕举报机制（以前的C/S版本还有注册限制，举报禁言和硬直时间）
现在这个模式勉强对付争吵辱骂，对付广告和spam暂时想不出好办法……能分享一下你的点子吗？

plqws

2015-02-11 14:28:32 +08:00

很早就有类似的想法了；对于提高弹幕质量，其实更重要的是提高门槛，过滤掉质量差的用户。靠举报什么的要投入人力什么的实在是不值得。弹幕数量其实是无所谓的，最重要的还是质量。
建议楼主建立个QQ群还是什么的，这样方便集中讨论。

Moefun

2015-02-11 14:28:47 +08:00

@cnbeining 原来你也在这里=-=

schezuk

2015-02-11 14:41:03 +08:00

@plqws QQ群417216334
能分享你的“去中心化的前提下，提高用户质量”的点子吗？

cnbeining

2015-02-11 14:41:18 +08:00

@schezuk

没回邮件真是抱歉，天天忘记。。。

谁来做中心，为什么要做中心，是个问题。

例如，我倒是不在乎再捐个服务器用。但是怎么保证稳定是个问题。

要是看300K的弹幕先得下载100M文件这就没得玩了。

弹幕管理不必说了，除非我们就不准备做弹幕管理，让UP自己处理。反正也是个办法。

@Moefun 好多年了。。。

schezuk

2015-02-11 14:48:52 +08:00

@cnbeining P2P文件分享没有管理者，没有UP主。P2P弹幕分享大概也不会出现管理者和UP主。
当然客户端不喜欢的弹幕可以不转发出去（拒绝声明自己收到这一消息）。可以有一点用处。
服务器被设计为无必要，但是优化了的、适合同时处理多磁链的、专职储存弹幕的客户端可以起到代替作用。

swordfeng

2015-02-11 15:01:08 +08:00 via Android

(/ω＼)这里不也就那么些人
我倒是觉得这个协议设计得越安全就越危险啊毕竟改改就成了不受控的twitter

个人觉得，中心由p2p网络自主产生，像gnutella那样就行了嘛

caiych

2015-02-11 15:36:15 +08:00

我想过的类似的事情不是完全的无中心，是视频的无中心。
大概就是同一个视频从优酷看和从爱奇艺看是一个弹幕池（如果不是独家的话）
形式上也许是浏览器插件
有个有中心的用户注册也不是什么大不了的事情吧…

schezuk

2015-02-11 16:02:05 +08:00

@caiych 你要的是DandanPlay~~~的说

caiych

2015-02-11 16:15:46 +08:00

@schezuk
大概是这东西的web版本……

schezuk

2015-02-11 16:19:55 +08:00

@caiych 那就是我的旧版opendanmaku了

schezuk

2015-02-11 16:26:18 +08:00

@swordfeng
不受控twitter有什么不好~~~求教
gnutella是洪水请求，有TTL，适合内容不变的资源，我觉得对付这种随时间自增长的资源会出问题。
中心由p2p网络自主产生这点没听明白~~~

momo5269

2015-02-11 16:30:32 +08:00

弹幕质量这事，就好比你建了个广场，允许所有人来说话，但是又想收集和过滤谈话内容一样不现实。除非一开始就建成酒吧之类的相对可控场所。也就是7L的看法。

schezuk

2015-02-11 16:33:21 +08:00

@momo5269 收集所有人应该没有问题吧~~~
关于过滤，目前的想法是转存转发的自我规制。不过要实用化也要费些事。

kawaiiushio

2015-02-11 17:08:10 +08:00

海盗湾弹幕版

q84629462

2015-02-12 03:08:02 +08:00 via Android

看了这个贴才知道有个叫dandanplay的实现了我的想法

Eleutherios

2015-02-12 07:18:51 +08:00

@schezuk 不考虑下Bitmessage一类的机制么?

虽然说加密匿名什么的对弹幕没那么重要, 但是Bitmessage有个很有意思的设定: 发信息需要"做功", 这样可以大幅削弱机器人制造的垃圾弹幕数量.

@cnbeining 如果换个做法呢? 想要使用这一去中心化服务, 你需要提供300M硬盘及相应流量.

Eleutherios

2015-02-12 07:21:18 +08:00

@schezuk 另外, 关于不停增长弹幕什么的, 何不设置一个弹幕"有效期"?

schezuk

2015-02-12 07:55:20 +08:00

@Eleutherios 求加群417216334
群里正在讨论一个根服务器认证树的邀请升级机制，看到你提到的这个方案我觉得也许需要重大修改

swordfeng

2015-02-12 09:43:36 +08:00 via Android

@schezuk
1会被查水表
2说gnutella是指它的组网方式
3就是会逐渐形成一些相互信任的客户端网络，这样的网络可能有多个

Eleutherios

2015-02-12 13:08:35 +08:00

@schezuk 请允许我加群不说话+QQ群什么的, 实在不是什么靠谱的选择, 甚至不如maillist.

我反对根服务器.

我大概的想法类似于BT Sync + Bitmessage.
每个视频的弹幕对应一个文件夹, 每个弹幕对应一个文件 (最好做成数据库以防碎片)
有一个只读密钥A 用于读取弹幕, 比如视频名称/ID/whatever
有一个读写密钥B 用于发布弹幕, 形式上类似于两步验证, 根据时间变化, 且需要"做功"(如CPU运算1s)才能解开.

弹幕存活期在发布时设为1000, 每次播放时, 被成功放出则+1, 被轮空则不变, 被屏蔽则-1. 更改存活期同样需要做功以获取密钥C, 且每次只能+1/-1 (由密码学保证, 而非程序代码), 每1个弹幕需做功 1/100.

轮空: 字幕无需被全部播出, 载入多少播放多少
屏蔽: 只要屏蔽=做功, 我其实不大在意屏蔽规则是什么

Eleutherios

2015-02-12 13:12:53 +08:00

话说, 国内不是在从ISP层面上打压 self-host 应用么?
即便是Bitmessage什么的, 也至少需要一个公网IP上的端口才能作为完整的节点, 但现在的家用宽带未必还有公网IP吧...

jabbany

2015-02-12 15:11:37 +08:00

CommentCoreLibrary开发者路过，说一下个人看法：

首先这个想法很好，毕竟现在版权视频多了，像以前B站那样一站式的简单弹幕服务越来越难找到了。要么投身下载党放弃弹幕，要么就忍受服务商的纠结（以及海外IP限制）。总之*高度整合*的平台越来越少了。

不过现阶段设计让这个系统绑在分布式协议上，我觉得对其前景有所限制。很多地方（公司学校海外）对BT等分布式协议限制的比较严，绑定到哈希值上感觉不是很好的方案。另外若干不同的视频可能都希望挂同一个/一些弹幕流，把弹幕这样分散至和文件绑定的话，势必会不天然的增加弹幕转流成本。

回过头来，我觉得现在最缺乏的是高度整合的一套弹幕解决方案来解决这些问题：

- 给一个视频怎么判定这个视频所拥有的弹幕和弹幕池，怎么获得它们并显示出来
- 如何有效的实现视频源，视频源Meta信息的非依赖性（可简单的换视频源）
- 如何有效的实现弹幕源，弹幕Meta信息的非依赖性（可简单的换弹幕源）
- 把界面和跨平台做好

比起一个分布式的弹幕机制，我觉得应该着手与一种抗打击的元数据目录和可拆卸的格式上的兼容性插件。至于弹幕，我觉得比起分散化，拆分为小型“频道”，用户通过目录订阅的方式可能会更有效的控制弹幕质量。比起零散的小弹幕服务器或者巨大的弹幕Hash（类似Bitcoin中每个节点都保存几乎所有的交易记录），一些小的，低能但是专业的服务器会好很多（考虑Hentai@Home）。

这个模式和E-Hentai的运营类似。

-----
作为另一个思路的参考，CCL的一个弹幕“Tracker”实现：
https://github.com/OpenDanmakuConsortium/akagi

设计思想就是服务器纯粹负责Meta信息，用户可以自由建立“弹幕池”，池内可以保存弹幕。（类比E-Hentai的Gallery）

这些“弹幕池”有任意自带的Meta信息，同时弹幕池之间的联系通过Tag建立。Tag是由建立弹幕池的用户（类似UP主）自选的，但是也可以被其他的用户添加和 vote tag。这样可以在一定程度上通过社区控制弹幕池本身的质量，某个池的某个 tag 被vote高，搜索那个tag的时候就会出现的靠前。tag 被 vote的低这个tag搜索里面出现这个池就会靠后。（类比E-Hentai的Tag）

使用的时候用户通过tag搜索到被标这个tag的弹幕池，tag可能范tag（“新番”，“自制”，“自Host”，“舰娘系列”等等广义不能定位视频的tag）或者准tag（“[XXX字幕组][XXX]YYYYY”，”sha1=xxxxxxxxx...“，“magnet:?xxx”，“http://xxxxxxx”）。这样用户既可以通过TAG搜资源和弹幕，也可以通过资源搜弹幕。甚至可以通过资源搜资源。

播放视频的时候，客户端可以在用户的指导或自主搜索下选择一些弹幕池来订阅。用户可以屏蔽单弹幕或者一个弹幕池或者一个弹幕池作者。用户也可以屏蔽Tag，比如某些tag出现了/评分达到某个值了，就不选取弹幕池（或者只有某些Tag达到数值才选弹幕池）。

用户还可以选择一个或多个弹幕池发送弹幕，客户端在合并弹幕池的时候自然会处理冗余弹幕。不过实操中只要选一个池就OK了。由于只存储meta信息，不但信息流小，总数据量也不大，加之协议兼容性的话，可以放置若干这种目录服务器（Tracker），客户端订阅几个就可以访问绝大多数资源的绝大多数弹幕。

全实现只要K-V数据库就可。

至于服务器成本，应该可以在免费的云服务上搭建。同时可以继续学E-Hentai，比如限制用户的搜索频率，搜索结果数量，让日常绝大多数使用都免费，但是爬资源肯定会撞墙，高频搜索的话超过Quota要花积分。可以对用户的Tag能力做一些优化，类似Stackoverflow的Reputation/Karma策略，甚至是V2EX积分策略。万一服务器运营不下去倒台，导出数据也灰常简单。
------

以上。供参考。

当然最重要的还是作好一个客户端。参考 DanDanPlay