为什么没有像 BitTorrent 这样的 P2P 流媒体协议?
我一直在想,是否有人知道为什么没有质量不错的大规模直播流媒体的 P2P 协议?具体来说,有哪些技术限制,还是主要是因为人们不想被媒体公司的律师毁掉?我已经搜索了一段时间,但我找不到可以处理数千人流媒体的类似协议。最接近的可能是 Webrtc,但它看起来只能处理 500~ 对等用户。
我在想,现在大多数人的上传速度至少为 30mbps,而 1080p 流媒体只需要 ~10mbps 和 720p 需要 ~5mbps。另外,我认为不一定非要直播,人们肯定不会介意一定程度的延迟。我认为,在网络中传播的数据包的大 O 值应该是 Log(N),因为如果一个主站在共享内容时连接了 10 个从站,那么这些从站又连接了另外 10 个主站,以此类推。
我能想到的另一个限制是确定谁先获得数据包的优先级,因为有很多人的连接速率都是 1gbs 或大于 10mbps 的。此外,还可以取消对偷听者的优先权,以免降低数据流的质量。
虽然在网站上很容易找到流媒体,但它们都是 360p 或几乎没有加载。我看到 bittorrent 的最初创建者在 10 多年前就在创建类似的东西,但现在看来这个项目已经夭折了。此外,这还忽略了编写这样的程序所需的大量时间。我想知道这在技术上是否可行。
你也许感兴趣的:
- Python 异步编程的 9 个级别
- Oracle:为后量子密码学做准备
- Websockets 的缺陷以及替代技术
- 您不应该再使用的 11 个过时 Python 模块
- 为什么人工智能公司的标志看起来像屁眼?
- Fedora 变革的目标是实现 99% 的软件包可重复性
- 我认识的最好的程序员
- Git 20 年,依然怪异,依然精彩
- chroot 技术–Linux 系统的瑞士军刀
- 最近人工智能模型的进步感觉就像胡说八道
比特洪流之所以运行良好,部分原因在于文件的下载顺序是随机的。它让每个人都能合作,同时还能抵御坏的同行、坏的网络连接、流失等。
如果你想进行高质量的实时流媒体传输,比特洪流之所以运行良好的原因就不复存在了。
延迟很重要。在比特洪流中,如果对等点消失了,没什么大不了的,只要在 5 分钟后用另一个对等点再试一次就可以了,你是按随机顺序下载的,谁会在乎一个片段延迟了 5 分钟。在直播流中,如果中断 5 分钟,你的应用程序就会坏掉。
在比特洪流中,每个人都可以分工合作–客户端尝试下载最少人拥有的那部分文件,文件的稀有部分很快就会到处传播。而在流媒体中,每个人都需要在同一时间下载同一部分文件。
比特洪流通过取消向自由下载的同行发送文件的优先级,来惩罚那些不作出贡献的人。它可以在个人层面上做到这一点。在 p2p 流媒体设置中,你可能会让一些同行获取源,然后发送给其他同行。这种关系不是接收关系,因此更难惩罚 “逍遥者”,因为在本地层面,你无法知道你发送数据的对等节点是否将数据推送给了其他节点。
我相信其中有些问题是可以解决的,但这些问题都很难令人满意地解决。
这篇文章评论的是 bittorrent 不能用于流媒体直播的原因,而不是 P2P 不能用于流媒体直播的原因。
> 延迟很重要。在比特洪流中,如果点对点消失了,没什么大不了的,只要在 5 分钟后用另一个点对点再试一次就可以了,你是按随机顺序下载的,谁会在乎一个片段延迟了 5 分钟。在直播流中,如果中断 5 分钟,你的应用程序就坏了。
首先,BitTorrent 客户端不会按随机顺序下载或等待 5 分钟。它们通常会先下载最稀有的区块,但也可以随时随地随心所欲地下载。
其次,标准 HLS 设置的标称片段大小为 6 秒(有些实现高达 10 秒),客户端通常会在播放前缓存多个片段(如 3 个)。这意味着在一个片段成为关键之前,您有 18 秒的时间。
这对于 P2P 网络来说并不难处理。你需要调整引入定时信息和管理跳数的方法,但每个客户端都可以保持与其他多个客户端的连接,并在连接失败时有足够的容量来填补片段。可以使用各种策略来分配负载,同时避免延迟惩罚。
低延迟 HLS 使用的网段要小得多,要求也更高,但并非无法管理。
> BitTorrent 惩罚不贡献的人
私人社区会惩罚这种行为,而 BitTorrent 客户端不会。大多数新的下载都会在很长一段时间内以自由下载者的身份出现,只有在远远超过下载时间的很长一段时间内,才会出现足够多的兼容播种机会,让他们做出实质性贡献。
网络并不需要每个人都来播种,它只需要足够多的人来播种。
> 首先,BitTorrent 客户端不会按随机顺序下载或等待 5 分钟。它们通常会先下载最稀有的区块,但可以在任何时候做任何想做的事情。
这里的问题是,BT 运行得如此之好,是因为客户端默认了 “好行为”(优先下载稀有内容),并阻止了 “坏行为”(蹭网/不上传)。
这在整体上保持了平衡,足以维持网络的健康。如果改变这些,就需要引入其他机制来维护网络的激励机制。
>这在整体上保持了平衡,足以维持网络的健康。如果改变这些,就需要引入其他机制来维护网络的激励机制。
这才是真正的关键点。在 P2P 大战中,只有 bittorrent 是赢家(尽管旧的网络仍然存在,而且你可以在其中找到有趣的东西……)。- 永恒的教训是,“水蛭 ”需要得到短处,而给予回报的人则需要得到奖金。这是人性的一个基本特征,类似于 “水蛭的悲剧 ”之类的说法。
在拥有千兆种子箱的时代,我们还把种子箱放在首位,这太愚蠢了。如今,成为种子用户的唯一途径就是在版本发布后的几微秒内拿到它,并在其他人拿到之前下载,这样你就可以上传给他们。然后,其他人就必须从你这里下载,但由于每个人只要稍稍参与其中,就会拥有一个千兆级对称种子箱,因此水蛭问题已经不再像拨号和 DSL 时代那样严重了。令人失望的是,网络文化并没有因此而进化,而是固守着这些过时的观念。我并不是说不应该激励人们回馈社会。水蛭很糟糕。但在这片富饶的土地上,却存在着无法播种的问题,因为有太多的播种者试图播种。
对于流媒体来说,服务提供商通常也控制着客户端,因此在客户端行为方面,他们应该会好得多。
在自带客户端的情况下,激励机制是完全一样的:客户端可能会默认良好的行为,因为网络健康等同于用户体验,而且与 BitTorrent 完全一样,如果某些客户端不服从,既不会受到惩罚,也没有必要惩罚。
> 与 BitTorrent 完全一样,如果某些客户不服从,既不会受到惩罚,也不需要惩罚。
“惩罚”(针锋相对的算法)是比特洪流的决定性特征之一,尤其是与之前的比特洪流相比。
这并不是一种 “惩罚”,而且客户端所要执行的惩罚也大不相同。
原始客户端的原始规范将其带宽的一部分分配给随机的对等点,而不是已知的好的/首选的对等点,因此如果你没有大块,你基本上就会受到带宽和/或对等点的限制。
如果把现在的 arch linux ISO 放到 aria2c 中,让它成为一个新的、未知的、没有数据提供的客户端,你会发现,虽然加入网络、获取元数据和连接到对等设备需要几秒钟时间,但你很快就会在没有上传任何字节的情况下让你的连接完全饱和。
如果你愿意,流媒体网络可以使用直接访问或低跳访问作为播种激励–通过播种获得稍低的内容延迟。当流媒体客户端由内容提供商控制时,很容易强制播种,拓扑结构也可以集中控制。
在视频流媒体中,客户端确实控制着一切……除非你拥有自己的客户端并自定义其行为。
你应该看看人们是如何尝试让 HLS 选择流媒体的。使用默认播放器是不可能的–客户端会这样做。
是的,这就是 HLS 的预期行为–内容提供商公布可用的流媒体和比特率,客户端根据当前流媒体的性能和自身能力选择使用哪个流媒体。
服务器可以通过向各个客户端发布定制的清单来控制流,不过这样做有点傻。HLS 的设计目的是极易进行负载分配,并将 CDN/缓存代理放在前面,而内容提供商在负载管理方面却如此糟糕,实在令人惋惜。
无论如何,这里的假设是,你会将使用 HLS 的客户端换成使用 P2P 协议的客户端,包括播种部分和网络健康管理。
我的 ADSL 连接速度相对较慢,在不上传任何东西的情况下,以 95% 的理论速度下载 100% 的文件是很正常的。如果网络有足够的上传能力,它真的需要我上传吗?(注意,如果有人需要罕见的区块,我的客户端仍然存在)
我记得大约在 2005 年左右,有些 Bittorrent 网络试图监控你,并惩罚你不贡献,这对我来说是一场灾难,因为我的上传量必然只是下载量的一小部分。我发现,即使双向连接良好,这种网络的性能似乎也很差。在我看来,如果每个人都被迫上传与下载同样多的内容,那么有能力上传多于下载的人就是这种网络无法利用的资源。
你不必立即播种,甚至不必播种相同的资产。除非规则发生了变化,否则通常只需要保持特定的最低种子寿命比即可,而这很容易通过闲置种子库来实现。
这样做的目的是通过一个简单易懂的指标来确保网络健康:你一直是一个有生产力的人。如果你没有播种,就必须由其他人来承担,而网络并没有因为你获得区块而受益。
社区本身也能从中获益,因为它为成员提供了带宽充足的保证,而不是纯粹依赖他人无偿的善意。
很少下载的东西是无法上传的。帮助网络的通常方法是下载一些你不需要的流行内容并将其作为种子。这可以减轻大种子商的压力,帮助他们播种其他你没有的东西。
但我个人认为,你不必在 Torrent 中做任何事情,尤其是在 adsl 中。我们的多百 U/d 比率可以满足您的需求。每个人都能诚实、舒适地参与进来就足够了,即使这意味着没有上传。只是不要在下载后出于不必要的原则而将其关闭。
做直播的人都不应该把 gop 设置为 6 秒。这太大了。我把我们的 gop 设置为 2 秒,这样可以让移动设备更快地适应带宽限制。
另外要注意的是,直播的视频片段通常设置为无缓存,vod 片段也是如此。CDN 会进行缓存。如果要倒带,客户端应保留片段,但这是客户端的事情。
我认为人们没有理解你所说的细微差别。你所说的大部分内容对于 Netflix 式的流媒体并不准确,它实际上更适合称为 “视频点播”,但对于体育赛事直播或新闻广播意义上的 “流媒体直播 ”却非常适用。
视频点播完全可以在 BitTorrent 上实现。正如你所说,你必须避免一些延迟隐患,但这并不是你不能自己解决的问题。
直播则是另一回事。正如你所说,直播的问题在于每个人都需要在同一时间获得相同的内容。如果我花了 200 毫秒下载下一个 500 毫秒的内容,那么就没有人可以与我分享,因为他们都花了 200 毫秒做同样的事情。BitTorrent 依靠的是我下载内容和你请求内容之间的时间差。如果你在我得到内容之前就提出请求,那么我就无法满足你的请求,只有我打算从别人那里得到内容的人才能满足你的请求。
如果你想实现这样的功能,你可能会选择一棵播种者树,在这棵树上,协议会选择一个可信节点子集,在允许它们播种之前,先将内容上传到这些子集,然后让它们递归地做同样的事情。
这显然会带来大量的复杂性和延迟,而且已经不再是 BitTorrent 了。
我不认为他是在说必须是 BitTorrent,而只是在应用其中的一些原则。
例如,你在美国和英国分别有一组人在通话。在大洋彼岸,Ping 时间为 100 毫秒或更长,会有一些随机数据包丢失,但在英国境内,Ping 时间最多为 15 毫秒左右。通过合作和共享,一个集群中的客户端可以从另一个集群填补丢失的数据包,这比从原始主机请求数据包要快得多。
一般来说,从更多本地来源请求丢失数据包的能力应能提高整体视频通话质量。这可能还是 “为时已晚”,因为要将延迟降到最低,你可能会选择在数据包到达后立即使用它们,甚至可能将失序的数据包视为丢失,而只是显示一个块状的视频,但如果客户端可以容忍更多的延迟(也许是一个可调整的设置,比如比最佳情况多 50 毫秒),那么理论上它应该比当前的系统更好用。
我自己过去也曾琢磨过一些这样的想法,但在我的 TODO 清单上从来没有排到足够靠前的位置来尝试任何东西。
> 通过合作和共享,一个集群中的客户机可以从另一个集群中填补丢失的数据包,其速度远远快于从发起主机请求数据包的速度。
这只有在假设节点按顺序运行的情况下才是正确的,而这种假设并不成立。如果节点彼此独立运行(由于节点之间不合作,所以它们会独立运行),它们都能在约 100 毫秒内获得响应(计算和信号传递时间在此可忽略不计),这比它们合作获得响应的速度要快,即使我们假定节点之间完全合作(第一个本地节点 100 毫秒 + 之后的 15 毫秒)也是如此。这就是并行性。从理论上讲,减少工作量似乎是件好事,但如果有能力同时做两次同样的工作,就能避免同步。
基本上,这属于我的 “树状系统 ”草图中的某个部分。在这种情况下,“可信 ”节点将根据 ping 时间聚类来选择,但基本的草图是一样的,即你选择一个节点子集作为本地节点,然后让这个结构递归运行。
你遇到的问题是延迟。没有一种好的方法可以为整个网络选择一个全局的延迟数字,因为它取决于你在树中的深度。随着网络树的深入,你最终不得不重新调整延迟。唯一的其他选择就是增加宽度,这时你就会遇到另一个线性增长问题,尽管斜率较低。
我基本同意,但一旦这样做,就会失去比特洪流之所以如此有效的大部分特性。
例如,如果将网络排列成树状,就需要确保所有节点在带宽、延迟、地理位置、连接节点数量等方面都匹配得当。现在,你必须以某种方式使网络拓扑结构在面对客户流失和不良同行时保持良好状态。突然间,一切都变得复杂起来,而且看起来也不像是 p2p。
也许可以用不同的协议来管理这一点,但我认为,P2P 协议在比特洪流之外没有太大发展是有原因的。
如果我没记错的话,PopcornTime 可以通过 BT 进行流媒体传输。你的说法大部分是对的,但我认为可以做出一些妥协,使 BT 客户端能够证明流媒体。例如
1. 本地随机化片段下载顺序
2. 创建更大的缓冲区
3. 优先处理来自较慢连接的片段
但这仍然只是流式传输静态文件。调整获取的片段是可行的,缓冲也是可行的,人们不会介意他们的电影在按下播放键几秒后才开始播放。
如果我是流式传输直播,我需要的是立即播放的画面,在我错过的画面之后再获取后面的画面并没有什么帮助。
从本质上讲,流媒体直播是一种 “一对多 ”的分发模式,即内容从单一来源实时流向众多观众。
而 BT 从根本上说是为 “多对多 ”分发而设计的,在这种分发模式下,同行之间会随着时间的推移相互分享内容片段。这不仅仅是一个调整协议的问题,而是一个根本不同的问题。除非你愿意在流媒体的即时性上妥协,否则使用 BT 进行真正的流媒体直播并不合适。
如果大家都同意延迟 10 秒呢?
对于体育赛事等伪直播流媒体来说,这完全没问题。人们可以有稍微不同步的流媒体,并有不同程度的延迟。
但如果有 10 秒的延迟,就无法直播与某人的对话。
对于体育赛事直播来说,延迟实际上是一个相当大的问题。
没人想在看到球队进球前 10 秒听到邻居家的欢呼声。
然而,这正是我们所拥有的!
问题是每个人都在同一时间观看文件的同一部分。偏移 10 秒并不能改变这一点。
时间偏移阻碍了观众通过聊天与流媒体进行互动的能力,而这正是很多人(包括我自己)观看直播而不是录制的全部原因。
定义 “直播”。
主要区别在于流媒体的实时性。现场直播要困难得多,宽容度也低得多。
我还记得当年测试 popcorn time 和其他点对点流媒体工具的情景。它们工作得 “还行”。是的,你无法获得 Netflix 的体验。但对于热门影片,你能获得 “足够好 ”的流媒体体验。你得等上 30 秒才能开始播放。
部分原因是你需要相当不错的连接速度,而且文件本身压缩得很厉害
我不太相信随机顺序的说法。如果大多数人会从一开始就进行流式传输,那么一开始就会有更多的种子选手?所以这一切都很好。
而且顺序是由客户端要求的,有些客户端会按顺序播放,比如 Deluge
随机顺序的好处在于,它迫使你实际保留所有数据包,从而提高了上传的可能性。而流式传输则允许你不存储整个文件,这就更有可能出现坏人。
当然,有些 BT 客户端可以流式传输数据,但默认情况下的数据流有很大不同。
人们在获得完整文件的那一刻就会关闭网络。随机性意味着最后一个数据包和第一个数据包一样可能存在。
你会想看一个没有结局的开头吗?那该有多令人沮丧?
> 人们一拿到完整的文件就会关掉。
也许吧,但下载的时间也是上传部分文件的时间,所以还是有好处的。如果按随机顺序排列,就能更均匀地分配能够访问文件不同部分的人。
对于流媒体,如果每个人都在同一时间下载相同的区块,“坏人 ”就会为了节省磁盘空间而把他们已经观看过的所有数据都转走,从而损害了稍后观看的潜在同行。
工作证明在这一点上存在问题,因为你(马洛里)可以受雇成为文件的三级持久存储库,并在被要求证明你拥有文件时,秘密地从爱丽丝或鲍勃那里获取文件。即使你对每个副本使用了不同的加密算法,但数据通常是公开的,这就意味着有人可以找出给定给 Alice 和 Bob 的加密算法,然后在你这样做之后转储你的副本。
除非你使用公钥加密法,但这种加密法非常昂贵,实际上没有人会用它来处理任意大的输入。
如果我们谈论的是实时流(而不是静态文件流),那么开始时种子数量再多也没有用。
mpeg 流/TS 文件类型/DVB-T/C/S 广播是静态文件,三者是相同的格式,这种格式可以解决您提出的所有问题……请下载规格书并自学。
流媒体音频也是如此,大块音频是静态文件,所以你过去 30 年打的每通电话都是静态文件。
问题不在于如何将比特分成数据包(或 “文件”),而在于如何分发/使用这些数据包。
很明显,归根结底,它就是一串字节,就像所有东西一样,我想说的区别在于数据使用和请求方式的不同。
这更像是一种社会差异,而不是技术差异。
bittorrent 没有理由不能按顺序发送/下载 3000 个 TS 块/3 小时电影的静态文件。
您的 MPV/VLC/PotPlayer 也没有理由不按顺序播放。
即使您只有前 2 个文件。
文件 “一词在这里起了很大的作用。
数据块的种类有什么区别?或者,对于受过大学教育的人来说–他把文件作为一个有用的抽象概念来介绍,所以我就用这个抽象概念来工作,如果你说这不是一个好的抽象概念,那就告诉他。(是的,有毒的讽刺)
这篇帖子比这里 90% 的评论都更符合 OP 的主题。
再说一遍,新闻、电影、喜剧、特朗普的关税,每天都在通过数字视频/电视/网络向数十亿人进行数字流传输。如果比特的排序/分块对你来说那么重要,那么这个已经在运行的系统在这个意义上对你就不好吗?
或者再解释一下,用一句话解释整个世界就像 K12 一样。
我说的 “静态文件 ”是指预先录制好的文件,即使用户按顺序观看,他们也可能在不同的时间开始观看,因此不同的用户会观看不同的部分。
相比之下,在直播流中,每个人都会在同一时间观看相同的部分,而一旦该部分结束,就不可能再有人观看旧的部分了。
这在网络设计方面有很大不同。
是的,所以是 “没有尽头 ”的文件(本质上是管道)还是一堆 TS 文件没有区别。
如果每个人都从头开始,那么当每个人都想要它的时候,它的种子就会非常稀少,而当没有人需要它的时候,它的种子就会非常充足。
“种子选手 “到底是什么意思?
如果我可以在拿到作品后立即向两个人发送 2 份拷贝,那么如果我的下载需要 20 毫秒,发送又需要 20 毫秒,那么在 50 毫秒后对这三个人来说是不是 “种子良好”?
要准确回答这个问题,需要做更多的数学计算,而我现在正值复活节假期,不愿意在这里做这些事情。你应该更多地把我的论点理解为一个证明的草图。
既然如此,我有一个小小的更正。如果你想将流媒体传输到两个对等体(即你有一个由 3 个完全连接的节点组成的网络,其中一个是流媒体的发起者),并且所有链路的延迟都是 20 毫秒,那么你到每个节点的最低延迟路径正好是 20 毫秒,因为发起节点可以简单地将内容发送到每个客户端。
不幸的是,假设您关心的是直播流媒体服务的最短延迟,那么 20 毫秒也是最佳流延迟。因此,客户端将在他们应该播放内容的时候收到内容,因此他们没有时间将内容转发给其他人,以免下游在他们应该播放内容之后收到内容。
在 50 毫秒内下载并重新上传部分文件是乐观的,而且这还只是三个人,而严肃的直播平台必须经常面对成千上万的观众,每隔一段时间还要面对上百万的观众。
只有当每个人都在同一时刻开始直播时,这才是真的。当然,现实并非如此,而且在实践中效果很好。
没错,BitTorrent – 连续下载也是如此。
人们似乎需要 0ms 的超低延迟流来观看电影……他们真是疯了。他们想成为非凡的高速交易者,但只想看电影而不是股票。
我想知道,如果采用类似 HLS 的协议,为每个对等点分配一个片段进行转码/缓存,是否能达到最佳效果。如果一个对等点掉线,该片段就会分配给另一个对等点。或者说,如果有 5 个对等点,那么下一个片段可以加倍,以增加完成的几率。
我只是好奇而已。
> 比特洪流之所以运行良好,部分原因在于文件是按随机顺序下载的。
这基本上只适用于一个客户端(传输),该客户端明确拒绝线性排序。大多数客户端都实现了这一点。
要启用线性排序,大约需要更改 3 次。
我讨厌那些不为用户着想的客户端。
>对于一个明确拒绝允许线性排序的客户端(传输)来说,这基本上是正确的。大多数客户端都能做到这一点。
传输允许你将某个文件(比方说一个系列中的第一个文件)设置为 “高优先级”,所以他们并不是不允许改变行为。
为了 “生态系统的利益 ”或其他愚蠢的事情,即使是微小的改动,他们也明确拒绝执行此功能。
我曾在一家名为 Livestation [0] 的公司担任过一段时间的首席技术官,正如维基百科上的文章所说,该公司 “最初是基于从微软研究院获得的点对点技术”。
这种 P2P 协议栈旨在实现低延迟视频流的大规模扩展,即使在世界上与原始内容源服务器的对等带宽有限的地区也是如此。正如大多数视频流协议一样,VC-1 格式陷入了法律泥潭,而当我在大约 2012 年时,整个协议栈都是 RTMP、RTSP、HDS 和 HLS,没有任何证据表明该 P2P 技术栈正在生产中,这充分说明了这一点。
我的主要职责是将摄取堆栈从 DC 搬到云上,同时还要处理无数导致问题的糟糕设计决策(没错,维基文章第一段中的 2013 年中断就是在我的眼皮底下发生的)。
没有人向我建议过,我们真正需要关注的是 P2P 流媒体,除了公司打造了一个 Periscope 版本(Twitter 的首款流媒体直播产品),并在他们之前几周或几个月推出,以及转向社交媒体平台之外,当时我决定去做其他事情。
技术和法律问题是真实存在的,在其他地方也有涉及。人们需要可靠的交付。即使是 Spotify、YouTube 和其他拥有授权内容、可以通过转用 DRM 化 P2P 节省大量成本的公司,也不会采用这种方式,这应该能说明其中的挑战。
我希望 P2P 技术能得到更广泛的应用,但遗憾的是,我不相信我们能很快在 AV 领域看到它。
[0] https://en.wikipedia.org/wiki/LiveStation
我时不时地会使用 LiveStation,为了好玩,我一直在研究它何时以及如何使用 P2P 协议。不用说,我从未在 LiveStation 中发现任何 P2P 的证据。现在我知道为什么了)
谢谢你唤起了我温暖的回忆,我以为我已经不再拥有这些回忆了。
感谢你支持一个曾经很酷的企业。当它进入消费者直播领域时,我就退出了,但有时我也想把它复活为一个质量更高的 OTT 应用程序,而不是充斥着绝对的垃圾和广告。该平台在阿拉伯之春期间所做的工作意义重大,而如今我还真找不出一个很好的现代替代品。
你说得很好。有趣的是,YouTube 至少没有为其非 DRM 内容提供 p2p 服务。
听起来很容易引起用户不满
“我的网速怎么这么慢?哦,YouTube 上传了一大堆内容给其他人”。
“我怎么已经达到了本月的带宽上限?哦,YouTube 正在……”
但 2025 年的带宽非常便宜,以至于我都不检查我的带宽使用情况,在过去 3 年里,我从未达到过每月 2TB 的带宽上限。
其次,P2P 系统将有利于大多数人观看的视频,即流行视频。这意味着,“热门 ”视频将有大量并发用户,他们将一小部分视频传输给另外 3 个同行,而这 3 个同行又将同样的部分传输给另外 3 个同行。
这样就减少了上传所需的带宽。
这些问题是具体实施问题
我不知道没有 p2p 部分如何实现 p2p。
我的意思是,例如,你可以选择不使用太多(或任何)额外上传带宽,而无需先征得用户同意。
这就好比说,你可以选择不运行一个网站。是的,你当然可以选择这样做,但如果你打算运行一个基于 p2p 的流媒体网站,那就不行了。
不一定要基于 p2p。这在实践中不太可能行得通。但可以择机采用 P2P 技术。
Splitcast Technology 公司于 2012 年建立了这一系统。该公司倒闭了(找不到收入,创始人也陷入困境),但在我的记忆中,这项技术是有效的。它仍然需要大量的播种节点,但很大一部分带宽是由 “观看者同行 ”提供的。
这项技术的关键在于它能在所有对等节点之间同步播放。例如,这对股市公告和体育赛事很有帮助。
https://web.archive.org/web/20131208173255/http://splitcast….
https://www.youtube.com/watch?v=R5UYu9jeQbY
https://www.crunchbase.com/organization/splitcast-technology
虽然有 peertube 和 webtorrent,但它们似乎无法吸引主流用户。
在我看来,NAT 和广泛的跟踪导致用户不信任分享自己的 IP 地址,这是它没有流行起来的原因。
试想一下,YouTube 使用 P2P 技术,可以节省大量缓存服务器的开支。
据我所知,Peertube 和 web torrent 并不提供直播流,而只是提供预先录制的视频流,这对于 P2P 来说仍然比随机顺序下载要难得多,但与直播流相比却不可同日而语。
> 想象一下,YouTube 使用 P2P 技术,就能节省大量用于缓存服务器的资金。
我认为这笔钱花得很值。
Peertube 支持实时流 https://framablog.org/2021/01/07/peertube-v3-its-a-live-a-li…
源和观众之间存在滞后现象,也许在过去 4 年中有所改善,但不确定。
有意思,我还真不知道。
我找不到太多关于其工作原理的文档,只有 https://docs.joinpeertube.org/contribute/architecture#live。
听起来他们把流媒体分成很小的片段,然后用比特洪流(?)发布每个片段,他们似乎声称延迟时间约为 30 秒,规模为数百而非数千。如果属实,这的确令人印象深刻,我没想到这种方法的规模会如此之大。当然,这与 twitch 还是有很大差距,但还是令人印象深刻。
您可以在这篇介绍压力测试结果的文章中找到更多信息: https://joinpeertube.org/news/stress-test-2023
如果所有对等网络都在同一个本地网络上,那么测试结果可能就不那么真实了。
真正的原因是,如果你知道自己在做什么,带宽是非常便宜的。
对于 “业余爱好者 ”来说,建立自己的流媒体基础设施比使用 YouTube 或 Twitch 要复杂得多。
而对于想要拥有它的媒体公司来说,他们只需购买自己的基础设施和网络,价格便宜得令人发指。HE.net 宣传的传输速率为 40GB/秒,价格为 2200 美元/月。我有点过于简单化了,廉价的传输确实会有问题,而且可能需要备份,尤其是在某些地区。但在业余爱好者和大型媒体公司之间并没有什么中间地带。
对于盗版(体育直播流),我曾读到过 https://en.wikipedia.org/wiki/Ace_Stream 被用于此目的。这已经是很久以前的事了,但我知道它曾一度有很大的影响力。
这基本上就是答案。
最小延迟广播形成了一棵 B 树。根据定义,树不是点对点的。每个节点的分支数是上传速度除以流的带宽。对于下载速度高、上传速度低的非对称住宅互联网来说,这种分支系数极低。
一旦在 P2P 网络中加入恶意对手或网络连接不畅,每个客户端就需要通过擦除编码一次性读取多个流,并在一个节点失去连接时进行切换。
这听起来像是一篇非常有趣的博文的素材。我会读一读的。
2008 年,Skype 创始人推出了 Joost。Skype 最初是 P2P,直到微软收购后才取消了这一法律上有问题的功能–需要喂饱老大哥(: Joost 筹集了约 5000 万美元。
我还记得它,因为它是少数采用 XUL(与 Mozilla 应用程序(火狐)相同的框架)构建的应用程序之一。
https://en.m.wikipedia.org/wiki/Joost
Joost/Sykpe 的 PriitK 也参与了最初的 Kazza。我以前讲过他参与 20 世纪 90 年代一款网络游戏飞船游戏的故事,他在该游戏中重新制作了最初的漏洞百出/充满作弊的客户端(Subspace),并发布了现在的标准替代版本(Continuum)。
我清楚地记得,我一个人住在第一间公寓里,试图像使用电视一样使用 Joost。那真是一次糟糕的经历。
我也来分享一下。我也曾使用过 Joost。它让我开始在平台上观看世界扑克巡回赛,并开始玩扑克和观看其他现场扑克。
人们曾试图构建 BitTorrent 客户端来实现这一功能。据我所知,他们从未成功过。最主要的问题是,经常会有一些人不愿意分享,或者他们的防火墙或其他连接不允许他们分享。因此,最终只能有几个人把所有东西都播出去。第二个问题是,要观看流媒体协议,必须按顺序传输。使用 BitTorrent 完全可以按照您想要的顺序请求区块,但您不一定能按照您想要的顺序得到它们。
一般来说,人们在观看流媒体内容时无法忍受延迟和转圈等现象。如果你不介意稍后再看,不妨把它排成队列,让整部影片下载下来,这样当你准备好的时候,它就已经准备好了。
Popcorn Time 就是这样做的,而且效果很好。开始播放 Torrent 并不是一瞬间的事,但一旦缓冲区建立起来,播放就会很流畅。
Popcorn Time 因为流行得太快而被严重关闭。
商业解决方案可以有一个种子服务器,该服务器经过优化,可以流式传输视频文件的最初片段,从而启动流式传输,让基本的洪流来处理流式传输的其余部分。
Popcorn Time 仍然有效,而且每个人都在使用。它只是不再那么受追捧了。
我看到的最大问题是浏览器中的网络限制–一个视频可能有数百个播种者,使用普通的流式激流视频播放器效果很好,但由于浏览器中的激流客户端需要使用 WebRTC / WebTorrent,可能只有 0-5 个播种者支持它。在广泛使用的标准 Bittorrent 客户端支持 WebTorrent 协议之前,我不认为 WebTorrent 会得到广泛采用。
如果滞后时间合理的话,比如 30-60 秒,会不会有很大的不同?另外,你认为在这样的协议中,有什么方法可以对播种者进行优先排序吗?比如某种算法,你分享的越多,就越能优先获得最新的数据包。
我认为它有用的主要原因是:1.流媒体网站似乎亏损严重;2.体育流媒体非常糟糕,甚至是付费流媒体。我有 dazn 和其他两个体育流媒体服务,但它们仍然滞后,而且只有 720p
> 你认为会有很大的不同,还是你认为它最终也会降级?
我认为你可能需要 10 分钟左右的时间才能真正有所改善。如果你能制作一个稳定的 p2p 实时流媒体应用程序,让数百个对等用户都能观看相同的流媒体,而且只有 30 秒的延迟,我会认为这已经非常了不起了。
> 另外,你认为有什么方法可以在这样的协议中为播种者设定优先级吗?比如某种算法,你分享的越多,就越能优先获得最新的数据包。
如果我们谈论的是实时流媒体(而不是 “Netflix ”类型的流媒体),那么我不认为播种者是个东西。你不可能给一个还未创建完成的文件播种。
如果你的意思是更普遍地惩罚自由流播者,我认为这在直播流中很难做到,因为一般来说,数据来自不同的对等网络,而不是你向外发送数据的对等网络,所以很难(也许不是不可能)知道谁行为不端。
显然,PeerTube 可以向数百(而非数千)名观众发送 10 秒延迟。
对于体育流媒体,你特别想要低延迟,不是吗?被隔壁欢呼(或不欢呼)的人搅了局可不好玩。
如果质量和可靠性更好,我不介意有一分钟的延迟。我每月为 dazn 支付 20 美元,但它仍然会出现滞后和缓冲现象。
https://github.com/johang/vlc-bittorrent/
stremio 很好用,而且很受欢迎。
它与爆米花时间类似,但爆米花时间是通过合法途径被扼杀的,所以我认为它们确实起飞了。
Stremio 聪明地避免了被扼杀的命运,因为它将盗版作为一个可选插件,你必须从另一个网站安装,这样他们就可以推诿责任。
它的效果很好,让我无需再订阅数千个插件。
我也想引用 stremio,它远非完美,但大多数时候都能正常工作。
唯一能使用这种系统的实体是主要的流媒体平台,以及试图在未经同意的情况下流播受版权保护内容的项目。
前者不想使用它,因为这会降低他们对内容的控制,而后者不想建立一个新的系统,因为建立在 Torrents 上的系统已经足够好了。
我曾在一家名为 Streamroot 的公司工作过,该公司出售的正是这种内容。我可以告诉你,你的第一段确实是正确的,但第二段却不正确:我在那里工作时,我们的客户是主要的流媒体平台(不是 Netflix 或 YouTube 这样的全球巨头,而是 Canal+ 或 Eurosport 这样的欧洲大公司),我们也有大量的垃圾网站(流媒体体育、动漫、色情等)。
我后来离开了,公司后来被 Level 3 收购,所以我不知道具体是如何发展的,但很可能是出于声誉原因,他们放弃了非法流媒体市场,坚持与大公司合作。
> 我后来离开了,公司后来被 Level 3 收购,所以我不知道具体是如何发展的。
我只是突然想到,可能有很多大型媒体公司都在使用各种专有的视频流产品进行分发,但我们却从未听说过,原因很简单,因为消费者无法使用这些技术。
媒体公司通常对自己的技术相当保密(Netflix 是个例外),所以这方面的信息并不多。盗版社区(因为,让我们实话实说吧)也不会对这样的非自由(言论和啤酒)流媒体解决方案感兴趣。因此,这可能就是公开信息很少的原因。
但如果你使用付费数字电视产品(Eurosport 就是一个很好的例子),那么你可能已经在使用各种你从未听说过的 P2P 流媒体协议了。
> 降低对内容的控制
加密(可用于共享)、签名、回退到 CDN。控制不是问题。
> Torrents 已经足够好了。
Torrents 无法满足大规模的直播市场需求,如体育赛事、赛季决赛或真人秀/新闻。这正是问题的关键所在。
> 唯一的实体
每个被 YouTube 踢出局的人,或者出于本意不想使用大公司的人,比如 Hacker Cons 或开源社区。
> 加密(可与共享一起使用)、签名、回退到 CDN。控制不是问题。
当然,如果加密密钥泄露,你也可以将其旋转。既然是流媒体,过去的内容就不那么重要了。
(话虽如此,我不认为这有什么帮助–任何 DRM 都能被破解,而且即使采用当前的集中式系统,也有很多在线电视流媒体网站)。
您可以流畅地观看昨天上映的大片。DRM 非常重要。
“Torrents 无法满足 livestream 的巨大市场需求”,Livestream 可以,我们为什么不使用 Torrents 并不是技术原因,而是因为大多数人只需支付 Apple TV / Netflix 的费用,无需在电脑上安装任何东西,而且用户界面要好上 10000 倍。
原因是这些人都在大电视上看,而他拍摄的内容是镜头前的大头,所以他们不喜欢 3 英尺的大头就在他们面前……大多数年轻人都在手机上看东西。
公海上有一些使用 webtorrent 的流媒体网站。有趣的是(至少对我来说是这样),它可以绕过基于防火墙的 IPS/检测,因为它全部是 https,所以可以检测到 bittorrent。人们在工作时用它来串流电影,我想这对他们来说是件好事。我想这对他们有好处。
AceStream 属于 P2P,但其主要用途是串流盗版体育直播。但查了一下,它似乎已经被 “区块链!”天才们感染了。
在没有任何区块链的情况下,它仍然可以运行,而且在 github 上有用于使用 CLI 的 dockerfiles 和镜像。它是闭源的,用户界面是 VLC 的分叉版本–它还被怀疑传播恶意软件–CLI 工具看起来还不错,但谁知道呢。
令人惊讶的是,如果只使用 mpegts 流,可用的频道效果非常好。
在过去的生活中,我曾在 VPS 上的 tvheadend 实例中添加过几个频道。在观看某些频道时,Kodi 可能会崩溃,我一直在想这是否只是流媒体断了,还是发生了什么更有趣的事情。
如果打开端口观看热门频道,带宽很容易就会达到饱和–没有限制。
后来我就不再用它了,因为它经常出现故障,虽然不是一无是处,但也够烦人的了。
它只支持 IPv4,而且似乎使用了自己的跟踪器,或者至少调用了一些 URL 来进行初始对等发现。
如果能开发出真正开源的类似软件就更好了,但我猜它的主要用途是非法流媒体。
要小心的是,它试图使用 upnp 打开路由器上的端口,即使只是查看列表也会让你上传片段。
这个工具还是很吸引人的。它越来越接近操作者想要的东西,但我认为它存在可扩展性问题,而且它的一切都有点阴暗和不透明。
阻碍 acestream 发展的主要原因之一可能是它大部分仍然是专有的。在第一代bittorrent实现之后,各种不同的bittorrent实现层出不穷,这迫使每个人都必须适当地进行标准化。
当 bittorrent-live 发布时,我还对它抱有希望,但不知为何他们也没有将其开源。
我是 Iroh ( https://github.com/n0-computer/iroh ) 的贡献者,这是一个开源库,用于在 NAT 后面的设备之间直接进行 QUIC 连接。
我们的库是通用库,可以在需要直接连接时使用,但在 Iroh 的基础上,我们还提供了 iroh-blobs,通过 QUIC 连接提供 BLAKE3 验证流。
Blobs 目前是一个提供低级基元和点对点流式传输的库(例如,请参阅 https://www.iroh.computer/sendme 作为示例/演示)。
目前,我们正在对 Blobs 进行扩展,以便于从多个提供商进行并发下载。我们还将提供可插拔的内容发现机制以及轻量级内容跟踪器实现。
这里有一个实验跟踪器:https://github.com/n0-computer/iroh-experiments/tree/main/co…
由于 BLAKE3 树状散列的特性,您甚至可以在完全下载之前就开始共享内容,因此 blobs 非常适合上述用例。
我们已经对 iroh 连接上的媒体流进行了一些探索,请参阅 https://www.youtube.com/watch?v=K3qqyu1mmGQ 。
与 bittorrent 相比,iroh 的最大优势在于,即使在不允许手动或自动端口映射的路由器(如许多运营商级 NAT 设置)后面,也能高效地共享内容。
与 bittorrent 协议相比,BLAKE3 的另一个优势是内容是逐步验证的。如果有人向你发送了错误的数据,你最多只能在 ~16 KiB 之后才会注意到。Bittorrent 也有以片段哈希值的形式进行的类似验证,但这种验证更为粗略。此外,BLAKE3 采用了非常友好的 SIMD 设计,因此速度非常快。
我们是 Bittorrent 的忠实拥趸,实际上我们的节点发现使用了 Bittorrent 的部分功能,即主线 DHT。
以下是去年的一篇演讲,详细介绍了 iroh 的工作原理:https://www.youtube.com/watch?v=uj-7Y_7p4Dg,还简要介绍了 blobs 协议。
BitTorrent v2 通过梅克尔树实现了增量哈希。效果出奇的好。我在这里实现了它们 https://github.com/anacrolix/torrent/issues/175#issuecomment…
这项技术已经开发了好几次,但最终 CDN 现在已经便宜到 P2P 毫无意义的地步。你不能忽视开发成本,因为在这种情况下,开发成本主导了所有其他成本。
如果 CDN 如此便宜,为什么 YouTube 还坚持要为带宽付费?我已经为我的带宽付过钱了,而且我很乐意把它用在像 YouTube 这样的地方。
真正的原因是集中式架构给了他们控制权和收取租金的能力。
你说得对。这是关于控制和金钱。
> 为什么 YouTube 坚持要为其带宽付费?
你在说什么?
YouTube 的成本远不止带宽。而且很多广告和高级会员收入都归创作者所有。
https://en.wikipedia.org/wiki/PeerTube ?
看起来很有趣!很惊讶这样的东西从未流行起来。我基本上在寻找类似 Twitch 的东西。它的质量非常好,而且是实时的。但很明显,Twitch 正在亏损,而且占用了亚马逊的所有资源,所以我想看看是否有更可持续的 p2p 方式。
你说从未流行起来是什么意思?它已经在 https://joinpeertube.org/ 上 “上线”,你可以访问 https://joinpeertube.org/browse-content 并在搜索表单中输入内容,或者将搜索范围限制在 https://joinpeertube.org/instances 下的特定 “实例 ”中。
或者回到你最初的问题:https://docs.joinpeertube.org/use/create-upload-video
编辑:你并不局限于这些地址,首先还有其他的实例,其次,如果你喜欢的话,还可以自己托管。
从技术上讲,这是许多可能的解决方案之一,现在 “已准备就绪”。
补充: 关于可持续发展,以及谁是幕后推手,也许你会对 https://framasoft.org/en/ 感兴趣?
从那里链接到 https://framablog.org/2024/12/17/peertube-v7-offer-a-complet…
和
https://framablog.org/2025/04/10/2025-peertube-roadmap/
谢谢!我会去看看的。
我的意思是说,它还没有流行起来,但看起来它正在崛起。
是的,这是典型的 “鸡生蛋,蛋生鸡 ”的问题。我时不时会去那里看看,甚至还发现了一些 YT 上根本没有的东西(独立恍惚/环境/Goa 音乐)!虽然选择有限,但与 YT 或其他网站相比,它的算法较少,正因为如此,如果你没有商业利益,对广告不屑一顾,你就不会被迫使用最夸张的龇牙咧嘴的表情或点击率极高的标题。
如果这是你的事情。而且你在其他地方也有一定的网络存在,那么你就可以链接到 peertube,不管是哪个网站,还是自建网站,都没有问题。
这就是为什么我指给你看。如果你需要/想要最大规模的受众,因为平台熟悉度/网络效应,那么可能不行。至少不是现在。但总得有人开始:)
对于大规模视频传播而言,被一家拥有 “无限带宽 ”的公司收购是可持续的方法。
协调 p2p 实时视频分发会遇到很多问题,而在被收购之前花风险投资的钱则要容易得多。
以下是你将面临的一小部分挑战:
你需要有一个很好的分发网络,来处理那些无法通过 p2p 连接的用户。
在不引起用户不满的情况下,确定可以使用的用户带宽;很多互联网账户都有带宽配额,尤其是移动账户。
设法让用户与用户之间的连接传输延迟最小,以减少整体延迟。在跨洋连接不可避免的延迟、缓冲区膨胀的可能性以及合理的抖动缓冲区之间,很快就会出现严重的延迟和潜在的拒绝。
带宽限制/层级切换将是一个巨大的挑战;如果服务器可以推送客户端可以管理的最佳数据流,那是一回事,但如果你从一个对等设备上传输数据流,而数据流太大,对等设备可能没有更小的数据流可以切换,而且没有好的方法知道带宽限制在哪里……也许你应该切换到别人的相同数据流,也许你应该切换到更小的数据流。你能从一个对等设备获取偶数数据包,从另一个对等设备获取奇数数据包吗……你应该这样做吗?
iroh.computer可以使用中继/直接进行NAT打孔。
他们使用 bao 哈希算法,这是我通过他们发现的(我记得),非常不错。
可以创建这样一个协议,尽管 bittorrent/ipfs 也不错。
我曾经想创建一个静态网站。
我曾想创建一个网站,但它只是一个静态网站,我使用一些 ipfs 网关用浏览器推送它,然后就得到了一个静态网站的链接,而且是匿名的。
真是太棒了。
可惜的是,它被那些想把它当钱用的加密兄弟们滥用了。
还有其他真正有用的加密货币项目(比如保护隐私的 Monero,我不喜欢智能合约的想法)
我真想告诉你一个事实:大多数加密货币都是骗局。这些人首先进入了加密货币领域,现在我看到了如此多的加密货币+人工智能。
作为一个真正从技术(去中心化角度)对加密货币感兴趣的人
我认为交易只是副产品,而不是最终结果。
另外,加密货币并不安全。我只是觉得像现在这样,把它作为科技股更好,虽然 99% 的时间都是在骗人,所以绝对更糟糕。
技术仍然很吸引人。但技术吸引人并不意味着它有价值。很多人都在过度推销自己的东西。
话虽如此,我实际上已经设法用加密货币创建了一个永久存储空间(类似于 ipfs,但它会强制永久存储),所以我认为这可以用在需要匿名/去中心化的地方。但是,在这个过程中也可以不包括货币,而且加密货币仍然不像人们想象的那样去中心化。
> 可惜它被加密货币兄弟们滥用了,他们想把它当成货币。
这里是 Iroh 投稿人。我不知道你在说什么。Iroh 只是一个库,用于提供设备间的直接 QUIC 连接,即使它们位于 NAT 后面。我们没有任何区块链或 ICO 或类似的计划。
我不知道任何名为 Iroh 的项目是骗局,如果有,请提供链接。不是我们。
我知道一年前有一些骗子试图制造 BLAKE3 硬币什么的。
其实我指的不是 iroh,而是我提到的 ipfs / stratos 的事情。
我目前对 iroh 唯一的不满是,它的浏览器对我来说感觉太多了/我不想学习 rust。
因此,我实际上想构建一个需要连接的东西,并使用了 nostr,因为 nostr 非常适合做网站,而且不骗你,它也很棒(但 nostr 也充斥着加密兄弟:( )
我最近没有用过Nostr,但它不是和比特币玩家而不是加密兄弟联系在一起的吗?至少以前是这样的。
好的,谢谢你的澄清。
我原则上不反对加密货币,但我真的不希望 Iroh 与加密货币骗局联系在一起。
Iroh 只是一个用于 p2p 连接的库。你可以用它来进行加密,但我想说的是,我们的大多数用户都是非加密(货币)用户。
我们会努力让wasm版本更容易使用,但如果nostr对你来说很好用,那就用它吧!不过,如果你想避开加密货币兄弟,这里就不合适了:-)
这是一个东西。
对于直播,有一个基于 BitTorrent 的 AceStream,但我认为它是闭源的。他们确实有一些 SDK,但我从未研究过。它主要被 IPTV 盗版者使用。我用过几次,效果时好时坏,但效果好的时候,我就能以高清/全高清观看直播,而且没有断点。不过延迟总是很严重。
还有一些基于网络的视频点播,如 PeerTube(FOSS)和 BitChute?遗憾的是,webtorrent 的功能非常有限。
Tribler 通过 BitTorrent 提供视频流媒体服务已经有不到二十年的历史了。https://www.tribler.org/StreamingExperiment/。
共享 3 种方法:
1. 混合架构(CDN+P2P):–使用 CDN 处理主干流量,边缘节点通过 P2P 进行分发,以减轻中心服务器的压力(如 LivePeer 尝试将区块链和 P2P 结合起来)。- 优酷等平台已经尝试过此类解决方案,但需要权衡成本和效果。
2. 协议优化: – 分片传输: 将流媒体分成小块,通过多路径传输提高效率。- 动态优先级: 根据节点带宽和延迟动态调整数据分配策略。- 缓冲和预加载: 允许用户容忍更高的延迟,以换取更稳定的传输(如 HLS/DASH 协议思路)。
3. 去中心化网络探索:- IPFS 和 BitTorrent Live 等项目尝试过实时流媒体,但受限于技术成熟度和生态支持。- Web3 项目(如 Theta Network)结合代币激励机制,鼓励节点贡献带宽,这可能会促进发展。
这个软件曾在 2008 年出现过,而且非常完美。它叫 Joost,是这样工作的: – P2P 流媒体–你会看到一个大的频道标志菜单–你点击一个频道,它就会开始播放该频道随机选择的剧集的第一集,或者从你离开的地方继续播放–可能还有一个 “zap ”功能?我不太确定–图形用户界面非常漂亮而且大,如果你把 Wii 遥控器连接到电脑上,你就能在沙发上获得最佳的电视体验: 只需按下按钮调出菜单,瞄准你想切换的频道,大功告成。
可惜的是,它失败了,之后的产品都无法与之相媲美。
已经试过几次了。瓶颈仍然存在于网络的最后一英里。用户根本没有足够好的设备来可靠地处理如此大量的流媒体数据。
是的,现实世界中的 HLS/DASH 解决方案在很大程度上依赖于边缘缓存;你并不太在意你的基础设施是否位于正确的区域,但 POP 就是一切。
Netflix 为互联网服务提供商提供了一个著名的设备。
问题之一是,即使是 “对称 ”连接,通常也根本不对称(这里说的显然是住宅连接,而不是 DIA)。
问题是,如果你是盗版,为什么要在可以方便地下载和观看的情况下进行流媒体播放?
如果你为流媒体付费,为什么还要把带宽捐给他们?你会得到折扣吗?
“如果你是盗版,为什么要在方便的时候下载和观看流媒体?
直播活动,如体育比赛?
“你为什么要把带宽捐给他们?”
我不知道,但人们会为 Torrents 捐献带宽,也许这对他们来说是’免费’的?
还有呢?如果你喜欢,你已经为这些付费了。让他们为带宽付费吧。
“如果你喜欢,你已经为这些付费了”
我相信盗版被认为是 “花钱 ”的另一种选择?
我观看大多数体育直播都要花钱。
有些公司也在做类似的事情(StreamShark、Quanteec、Eyevinn;甚至是 Cloudflare 和 WHEP)。在我工作过的一家公司,他们在用户超过 10 万的活动中使用了 Eyevinn;但仍然存在性能问题。
除了带宽问题(因为你不能百分之百地依赖远程连接),任何 P2P 解决方案都意味着同一片段将在客户端之间共享多次;而 CDN 网络已经解决了这个问题(只需提供内容,而不是处理信号)。
BitTorrent 已经是一个可流式传输的 P2P 协议。你只需要一个能按顺序优先下载文件部分的客户端。
这就是问题所在。
但如果不进行修改,它就不能用于直播流媒体。
有道理。
对于流媒体直播,有 WebRTC。这也是一个问题。
但它并不是原作者所说的真正的 p2p(因为它不是一个覆盖网络)。它是 tcp/ip 意义上的 p2p,而不是比特洪流意义上的 p2p。
https://github.com/johang/vlc-bittorrent/
我相信 Popcorn Time 也是这样工作的,但我可能弄错了。我从未深入研究过。
的确如此。
不过这一切都始于 webtorrent 项目。最早的演示之一就是在流式传输不完整的实时 ISO 映像的同时启动 Ubuntu,这在当时给人留下了深刻印象。
对于媒体文件而言,这是一项伟大的技术。目前比其他任何技术都要好。但如果使用这种技术,这些媒体文件就很容易被重新分发,而要改变这一点又不能失去 P2P 的好处。
如果 Popcorn Time 拥有同步的多分辨率目录、带宽敏感的自动切换功能和一些付费的种子服务器,那么它将比其他任何流媒体服务都更好(从技术上讲)。
问得好–我也想过这个问题。从技术上讲,大规模 P2P 流媒体是可能的,尤其是在当今的上传速度和树状分布(log(N) 结构)的情况下。但存在很大的障碍:
流失和可靠性: 对等点来来去去,使稳定的流媒体变得棘手。延迟: BitTorrent 式协议并非为实时传输而设计。激励机制: 如果没有奖励,太多的用户就会流失。WebRTC:它很快就会达到极限,而且通常依赖于集中式中继。法律风险: 媒体公司对去中心化分发不感兴趣。
布拉姆-科恩曾尝试过 BitTorrent Live,但最终不了了之。我们很希望看到有人利用现代技术重振这一项目–感觉其潜力仍有待开发。
几年前,我就做了一个概念验证[0]。代码库无人维护,演示网站也关闭了一小段时间,但基本上就是这个想法。唯一的问题是,建立 WebRTC 连接的开销很大,所以它并不轻量级……
0: https://github.com/pldubouilh/live-torrent
据我所知,P2P 需要信息共享,因此当分发网络扩大时,这最终会成为性能瓶颈。你还需要相当复杂的缓解措施来防止分发网络中的不良行为者,比如节点会转发不良数据包,而不是分发它们收到和收到请求的好数据包。
你可能需要研究一下 Discord 决定采用的折衷方案,https://discord.com/blog/how-discord-handles-two-and-half-mi….。
这里有一些自己开发的模板,https://blog.swmansion.com/building-a-globally-distributed-w….。
理论上,你可以从 P2P 架构中获得弹性,但你必须牺牲一定程度的实时性,即让渲染客户端拥有相对较大的缓冲区,以处理抖动、网络问题、敌对节点等问题。
实时和 p2p 的一个问题是延迟。
这意味着什么?
在服务器端,直播的步骤非常简单(假设使用 HLS):
1. 流式传输到编码器,最好比特率高于转码比特率。
2. 对视频进行编码和转码,最好是 540/720/1080p 30fps。每种分辨率都有自己的比特率,因此可能分别为 2/3.5/5.5。假设片段长度为 2 秒钟,片长为 10 秒钟。因此,在任何给定的时间内,您都有 5 个片段(不过通常会有更多的片段)。
3. 将最新的 3 个片段存储起来,并用新的片段 URL 重写四个清单。(是否需要重写顶层清单?我想是的,但我记不清了)。
4. 删除旧网段(可选
因此,当客户端请求清单(m3u8)时,它会获取三个子清单(忘了术语)并选择适当的分辨率。它还会开始加载片段。理想情况下,它会查看清单并获取最新的片段,因此它的开始时间会更接近 “现在”。
然后,客户端会偶尔重新获取清单,以获得新的片段(清单被标记为实时;VoD 清单不需要重新加载)。获取时间可能必须小于片段持续时间,而片段持续时间就在清单的某处。
所有这些都需要时间。服务器编码需要时间,编码器放入文件需要时间,客户端获取清单需要时间,客户端获取视频片段也需要时间。
从上述顺序来看,客户端一般会比其他人慢 0-10 秒,这取决于客户端的行为方式。这比 “直播 ”要慢几秒,因为接收、编码和放置文件都需要时间。
那么,你能进行 p2p 实时传输吗?只要放宽对 “实时 ”含义的限制,就可以。你可以想象,一个网段经过的同行越多,传输链就越长。而该网段的真正有效时间只有 2 秒(如果客户端不小心,则最长可达 10 秒)。如果实时的意思是 “从现在开始最多 20 秒”,那么是的,你肯定能做到。时间窗口越紧,你就越不可能做到。使用带宽较低的数据流或许可以做到,但即使是 TLS 协商也需要时间。你的客户端不使用 TLS 吗?这样可以节省时间。
很多评论都提到,在互联网的短暂历史中,它一直以各种形式存在。有趣的问题是,为什么它没有起飞–尤其是在技术已经存在的情况下。
正如你所提到的,一种可能性是授权。在 P2P 流媒体模式中,“权利 ”持有者希望从内容分发中收取版税。除了废除版权,我不知道还有什么办法能让他们觉得这是合法的,但如果你能建立一种公平收取版税的方法,我不知道你是否能在执法者面前取得进展。但总的来说,这个问题似乎已经通过广告和订阅费解决了。
另一个数据点是,巨头们决定以数字方式提供内容。Netflix 和 Spotify 出现了。一般人下载音乐的原因是,除了 CD 换碟机之外,要想在你的……Zune 上收听大的歌曲播放列表,就必须拥有一个数字图书馆。或 iPod。这个问题已经不存在了,所以需求也就枯竭了。以前也有发烧友,但随着苹果无损压缩技术的出现,需求也随之减少。
最后,由于人们在真正解决问题,我们也在考虑大手笔的解决方案,以减少对网络的压力。如果你使用 P2P 流媒体,你的数据包就会占用慢车道。Netflix 和其他内容提供商与最后一英里的互联网服务提供商建立了硬件连接,这样内容分发的效率甚至比 P2P 模式更高。
简而言之:视频传输已成为一个真正的 “产业”。创新者和资本家投入了大量的时间和金钱来解决这个问题。流媒体平台应运而生,有好有坏。今天,我们又站在了重蹈覆辙的边缘,因为目光短浅的商业巨头们为用户数量建立了独占内容库,将用户的访问权限分隔开来。
流媒体需要良好的延迟,洪流可以达到不错的速度,但延迟总是很糟糕。
现代流媒体协议有时会不惜一切代价避免过多的跳转,以便尽快获得数据……torrent 要经过多次跳转和协商才能获得实际文件。这有利于去中心化,但去中心化和效率是相悖的。
问得好!我不太确定。但我经常在想,为什么随着速度和技术的提高,P2P 没有变得更强大呢?就像实时服务游戏一样……感觉可以有强大的 P2P 实现,可以促进很多失败的多人游戏。
我认为,削减实时服务(美元)和 SaaS 在其中扮演了重要角色。
在流媒体方面,CDN 难以匹敌,因为跳转次数很少。基本上,任何 p2p 技术都必须照搬现有直播的工作方式;本地连接良好的对等网络从较远的地方获取直播,然后转播给本地对等网络。其他任何方式都会带来延迟或浪费广域网带宽。对等设备也很少有中等的下游和特殊的(本地)上游。
IPv6 组播可能是直播的发展方向,但我并没有真正跟上最近的发展。理论上,互联网服务提供商可以选择动态注册组播地址,为客户订阅和路由。
在流媒体环境中,跳数和一般延迟在最初几秒后并不重要,因为最初几秒是连接到可能存在也可能不存在的对等网络的瓶颈。
(不是批评你/你的文章)
在我看来,人们需要收看像 LinusTechTips 这样的有毒频道的现场直播,回味几个星期前的有毒营销虚假信息,并且需要 0ms 的延迟,这简直是疯了… XD
为什么每个人都需要低延迟的单向流?
但我同意你的观点,如果公司已经忘记了 IPv4 的存在,互联网将变得更简单、更快速、更可用。
Peertube 为静态视频和现场直播提供 P2P 服务:https://docs.joinpeertube.org/。
但现实情况是,对于 99% 的人来说,Youtube 和 Twitch 都能正常使用。
此外,大多数住宅互联网服务提供商的上传速度都很差,而且数据上限非常严格。
我认为这里缺少的部分是,为什么我们首先需要 P2P 实时流媒体。
如果目标是削减成本–比如供应商试图避免 AWS/CDN 账单–那就与构建抗审查或弹性的问题大相径庭了。
如果没有明确的 “原因”,就很难证明权衡利弊(延迟、同行流失、不可预测的带宽)的合理性。集中式信息基础设施虽然枯燥,但却可靠–也许这对 99% 的使用案例来说已经足够了。
有趣的问题是:在哪个利基市场中,痛苦大到足以让 P2P 值得一试?
> 此外,我认为不一定非要直播,人们肯定不会介意一定程度的延迟。
我从事低延迟和直播工作。任何视频流的适当延迟时间都是整个视频流的持续时间。不过似乎没有人赞同我的观点。
> 我认为现在大多数人的上传速度至少为 30Mbps。
由于互联网服务提供商的垄断和繁文缛节,即使像纽约市这样的 “现代化 ”城市,上行速率最大也只能达到 30Mbps。
虽然情况有所改善,但 Spectrum 仍然是许多城市居民唯一可用的 ISP,而且他们提供的服务非常不均衡,最高端的套餐高达 980/30。
没错。如果你使用了这 980Mbps 的大部分流量,你的 IP 开销会很乐意占用这 30Mbps,留给你的空间几乎为零。
Octoshape 开发了这项技术,我相信它已经卖给了一些美国电视网络。
我想还有 acestream,但我不认为它能容纳 1000 名用户。它是我当年观看体育直播的首选,我现在不看体育节目了,所以不再关注它。
很久以前,有一个 peercast[0]。项目停滞。
0. https://ja.wikipedia.org/wiki/PeerCast
(除了像 HN 这样的小众圈子)现在已经没人用电脑了。没人会用手机播种。
另外,与其说一百万人都想看《蜘蛛侠 2》,不如说这一百万人有无限多的短视频或其他视频可看。观看特定视频的欲望已今非昔比。
时代变了,P2P 作为一种常见的分享方式,对普通人来说已经过时了。
技术方面的讨论很多,但真正的答案是,除了少数铁杆用户外,其他所有用户都被 Netflix 取代了 bittorrent/P2P。再加上法律威胁,以及 P2P 需要一定的数量/规模才能良好运行,这意味着临界质量的消亡。我们,互联网的用户,集体将比特流换成了流媒体公司,这是可悲的一天。
还有
* 网络链接不对称,上传速度慢,尤其是在手机上
* 流量包限制,DL 和 UL 都要计算在内
* 一些互联网服务提供商非常反对 p2p,有时这是政府政策(中国禁止 “住宅 CDNs”)。
* NAT
你查看过 webtorrents 吗?你可以按顺序从 P2P 网络下载电影,然后边下载边观看。
BitTorrent Live 也有这个功能:
https://www.bittorrent.com/blog/2016/05/17/bittorrent-live-m…
是的,我很惊讶竟然没有人提到布拉姆-科恩的名字。这是我首先想到的。另请参见 https://wiki.p2pfoundation.net/BitTorrent_Live
十年前,我还记得中国制造的 PPLive 软件,它通过你的点对点客户端软件传播盗版电视流。https://en.wikipedia.org/wiki/PPTV
有很多。问题是这样做毫无意义,效果也差得多。集中式服务器效果很好。在过去 20 年里,我们发现使用 P2P 的唯一可行理由似乎就是非法活动。其他人使用普通服务器就可以了。
建立这个系统的难度是 2001 年电影《反垄断》的前提,这部电影拍摄于微软邪恶的年代。这部电影是最早使用 Linux 桌面和合理正确的 shell 脚本及代码进行截图的电影之一。
要实现这一点,唯一的办法就是广泛采用类似于 Tailscale 设计的互联网覆盖网络。幸运或不幸取决于你如何看待它,Tailscale 受限于第 3 层,因此组播无法工作(它依赖于 IGMP 正常工作)。
为什么是 Tailscale?你知道 IPv6 吗?
从目前的情况来看,互联网上的 IPv6 组播已基本失效。互联网服务提供商似乎因为其潜在的 DDoS 而阻止它。当然,他们自己也在使用(对于在私人 VLAN 上串流直播电视非常有用),但作为局外人,你必须说服每个 ISP 和骨干网提供商信任你的组播流,而他们可能不会这么做。
Tailscale(或任何其他 P2P 叠加网络)可以通过重新启用被大多数 ISP 屏蔽的组播支持来解决这个问题。这并不是一个糟糕的主意。
编辑:其他地方的一条评论链接了 https://www.librecast.net/librecast.html,似乎正是在做这件事。
ISP 之间的转接和对等协议通常不包括组播,这意味着数据包会在网络边界被丢弃。
你为什么这么认为?
您可以安装 Qbittorrent 客户端,加载 torrent 文件/磁盘链接后,右键单击该 torrent 并按顺序单击 “下载”。
torrent PROTOCOL 并不要求按随机顺序下载随机文件。
只有 bittorrent, inc. 公司发布的以 “Utorrent ”和 “Bittorent ”命名的应用程序/程序不想引起媒体/音乐公司的法律纠纷。因为 “串流 ”比 “下载 ”更合法。torrent 协议没有其他理由不按顺序传送文件。
如果您需要即时的纳秒级延迟流,那么这种流在任何地方都不存在,即使是广播电台、电视台的广播也是延迟的,因此它们都是同步传输的。
我认为,你之所以要传输随机块,而不是从一开始就传输,其实是有原因的:如果一个节点可以上传不同的块,却需要多次向网络上传相同的块,这会造成资源浪费。
> 如果需要即时纳秒延迟流
我相信没有人这么建议。
通常的下载策略是按随机顺序先请求最稀有的片段。当蜂群/可用性超过一定规模时,大多数现代客户端会优先选择较早的片段。
“超级种子 “是一个不同的功能,种子不会上传更多的片段到一个对等点,除非先前上传的片段已先分发到另一个对等点。
什么时候传输什么数据块在技术上并不重要(在程序上是可以做到的,但我不知道如何正确调用)。
只有当您需要避免用户(SWARM)在下载完 torrent 后关闭 torrent 客户端应用程序而不向下一位用户发送数据块时,这才是最重要的。
但是每个人都说这是流,必须即时显示图片/视频。
所以我不明白,如果我们确实有成千上万的人在观看,而且每个人都说有大量的人在观看,但为什么其他评论中的所有这些人都在关心蜂群的状态,却仍然在关心蜂群?
(在 BitTorrent 的正常使用情况下,群组是很重要的,但对于流媒体来说则无关紧要)。
我明白他们在说什么,但他们不明白他们在说胡话。
OP 中的 “流媒体直播 ”是指 “广播”,如 “直播活动”。
> 我一直在想,是否有人知道为什么没有质量不错的 P2P 协议来传输大量直播流媒体内容?
也许 20 年前我们就有了 torrent 客户端/流媒体视频播放器。
> 有谁知道为什么现在还没有?
它是个东西,看来你没做过研究。
如果你去看的话,网上到处都是相关文章,例如
https://www.makeuseof.com/best-torrent-streaming-apps/
看来你忽略了 “直播 ”这部分。
有一些流媒体平台建立在 BitTorrent 的基础上,如带有 Torrents 插件的 Streamio。
这不就是多播的目的吗?
组播在互联网上不起作用。
您可以看看 Librecast [0],这是一个由 Horizons Europe NGI0 计划通过 NLnet 资助的研发项目,旨在将组播引入当前的单播互联网,并使采用组播的项目顺利过渡。布莱特-谢菲尔德(Brett Sheffield)在 2020 年 LinuxConfAU 上发表了题为 “组播的隐私和去中心化 ”的演讲,对组播和 Librecast 做了很好的介绍,该演讲可在 Peertube [1] 上获取。
> 要在单播互联网上实现组播,我们首先要利用参与节点之间的点对点链接建立一个加密的叠加网络。一旦建立,我们的叠加网络就可以运行我们所需的任何协议,不受路由器和中间件的阻碍,并能抵御拦截、干扰和网障。
[0] https://www.librecast.net/librecast-strategy-2025.html
[1] https://spectra.video/w/9cBGzMceGAjVfw4eFV78D2
该协议似乎是个很好的主意,但网站文字的黑色 #3365a3 是我见过的最糟糕的开源项目网站设计之一。
离题了,但我对 NLNet 资助了这么多潜在的革命性项目印象深刻。
https://en.wikipedia.org/wiki/Mbone
Mbone 是假的组播(如今你最好使用 CDN),我不知道它是否还在运营。
我在大学时有一位老师,他相当确信某种智能组播是解决这一问题的方法。
但在 ISP 工作一段时间后,我意识到问题在于让 ISP 使用很酷的协议是不可能的,一切都必须建立在更高的层面上。
我想是的,但我想的是像 bittorrent 那样的多播共享,只是实时共享。
因此,一个类似于多播的衍生工具,可以感知同行,并能在本地重新分配任何可用的部分–这就需要某种缓存,而缓存可能会破坏版权等…… 也许这就是为什么什么都不存在的原因。o/
与此相关的一件事:PopcornTime 不是在使用 bitorent 流媒体播放电影吗?它与 Bittorent 有什么明显的区别或明显的问题/缺点吗?我从未使用过它,但当时它听起来像是一件大事。
你可以利用带有主种子的 webtorrents,在理论上获得非常高的内容下载缩放比例,因为你可以在下载者的同时缩放同行者。在上面添加一个协调服务器来同步时间,这样就可以了。
这种方法已经发明过很多次了,但每次有人发明了真正有效的人对人文件传输方法时,它就会被用于盗版,遭到封杀和避之唯恐不及。
与 BitTorrent 无法运行的原因相同:提供服务需要花钱,而如果无法收钱,就无法提供服务。
集中式架构更容易控制人。
Bittorrent 在流媒体方面已经运行得很好了:
https://github.com/johang/vlc-bittorrent/
您可以通过 Bittorrent 进行流媒体传输… 我经常这么做,开始下载,设置为按顺序下载,然后就可以开始观看了。
构建它。使用 Go。也许用 nknorg/nnet 进行 P2P。签署 HLS 片段。Go 还能通过 WASM Web Worker 为网络前端提供服务。公共节点可以运行在带有自动认证域的轻量级 VPS/服务器上。观看者通过 WASM 浏览器加入群集–这样人们只需键入一个网址,用户使用起来非常方便,但域实际上无需提供任何数据。我只想用一个可信的公钥来签署 P2P 更新,这样节点就能阻止不听话的 IP 地址。这样就能获得非常友好的用户体验、简易的节点部署、相当低的延迟以及比特流级别的法律弹性。
PeerTube 是做什么的?
如果说 CG-NAT 的崛起为 P2P 视频流和相关共享的发展又钉上了一颗钉子,我也不会感到惊讶。
我有一个有趣的想法,就是将高清视频分割成 4 和/或 16 和/或 64 个低分辨率视频。对于 1/4 视频,视频 1、2、3 和 4 的像素可以这样排列。
例如,您可以使用一个高清数据流,然后只分发 [例如] 3 个较低分辨率的数据流。如果连接中断或图形处理跟不上,您不必跳帧,但可以逐渐降低图像质量。也可以有不同的帧频,只要它们的组合合理即可。
如果您以 120 帧/秒的速度录制了 640 MB 的视频,您只需要以 30 帧/秒的速度成功接收 2.5 MB 的视频,就可以观看整个视频。如果播放稍有延迟,您甚至可以从一个子频道跳到另一个子频道。
它还可以离线工作。人们可以在大显示屏上看到最先进的清晰分辨率,也可以在破旧的笔记本电脑上观看同样的内容。(以及两者之间的一切)
为了好玩,有一次我把一个 3.5 小时的讲座转换成了 75 MB,结果让我大吃一惊,原来还可以这么看。
这不就是 PeerTube 吗?
Peertube就是这样做的(或者他们计划这样做)
PeerTube 就是你要找的东西。
至少有两个类似的观看动漫的项目。我不会在这个论坛上说出它们的名字,但如果你去找的话,它们确实存在。
这不就是 https://webtorrent.io/ 吗?
有点像,但我认为那是针对文件的。我特别想到的是直播内容,比如 twitch
Trystero 可以做到这一点:https://github.com/dmotz/trystero?tab=readme-ov-file#audio-a…
你需要为它制作一个用户界面
登陆页面上的第一个演示是从同行那里流式传输一部电影。
https://webtorrent.io/
延迟。
Twitch 流媒体似乎可以接受 Twitch 增加的 10-60 秒延迟,这取决于他们的网络性能有多差。每个行业的要求会有所不同,但我不认为延迟一定是杀手。
Twitch 不会增加 10-60 秒的延迟。默认 OBS 设置下的平均延迟为 3-6 秒。
资料来源 我在 Twitch 视频系统上工作了 6 年。
Pears.com
Peertube?
好像没有直播?
有,webRTC 做了这个。
soulseek
popcorntime 不是将比特洪流作为流媒体协议,优先播放下一个要播放的片段吗?
嗯……这有点像 “先做后停”。Skype 是点对点的,这让我对松弛的技术大跌眼镜,它怎么会比松弛的技术更好呢?市场营销啊。
我认为最简单的方法就是对 m4u 格式进行一些改编,将 URL 改为视频 URL,将 URL 改为 torrent/magnet。
我能想到的一个问题是,每个部分都会独立发现对等文件,而之前部分的大多数对等文件应该也会有这些文件。
第二个想法是以这种方式使用 ipfs,而不是 torrent。这样可能更容易在各部分之间重复使用同行发现功能,而且还能解决何时停止播种的问题,因为这已经包含在协议中了。
我想在 ipfs 基础上创建分布式 twitch 是可行的,但不确定有多少人愿意在使用之前安装 ipfs 节点。这有点像鸡和蛋的问题,在这个系统开始真正运行之前,你需要很多人,但要引起人们的兴趣,它又需要真正运行良好,这样人们才会从类似 twitch 的服务中迁移出来。
当然,您可以使用公共网关。
我认为最简单的方法是不使用 Torrents,因为 Torrents 有固定的顶级哈希值。取而代之的是,创建一个类似于 bittorrent 但流式传输的新协议。