流媒体使用的带宽是否与下载相同?

ste*_*mie 75 download streaming data-transfer

假设内容具有相同的质量(其他条件不变),流媒体(即视频、音频)是否使用与下载相同的带宽?

假设我要从亚马逊下载高清电影或流式传输它,是否会等效使用带宽?

Jon*_*fer 44

它通常不是等价的。

流媒体提供商使用DASH等协议根据用户的带宽可用性和质量需求动态调整电影质量。然后服务器可能会限制您的连接速率,以便您可以缓冲一定数量(例如 10 秒,可能是 30 或一整分钟),然后您只能获得实时获取内容所需的带宽量。从提供商的角度来看,这是一个明显的优化,因为它在用户之间更平等地分配带宽,此外还避免了数据的徒劳传输(例如,当用户观看 480p 电影 10 分钟时,没有速率限制和使用共同的下行链路,很可能已经下载了更多,但如果用户停止观看视频则浪费了)。

传输的数据量是相同的。但是流媒体可能需要更长的时间,因为提供商可能会将数据传输速率限制为以给定质量实时交付内容所需的速率。

Dailymotion 是限制连接速率的提供商之一。从具有至少 100?Mbit/s 对称连接的服务器,我们看到以下行为¹:

youtube-dl http://www.dailymotion.com/video/xhc3zz_long-distance-calling-into-the-black-wide-open_music
[dailymotion] xhc3zz: Downloading webpage 
[dailymotion] xhc3zz: Extracting information 
[dailymotion] xhc3zz: Downloading embed page 
[download] Destination: LONG DISTANCE CALLING - ' Into The Black Wide Open '-xhc3zz.mp4 
[download]   5.8% of 51.99MiB at 203.89KiB/s ETA 04:06
Run Code Online (Sandbox Code Playgroud)

费率远低于可能的水平(并且是通过其他提供商实现的)。此外,如果您尝试不同的材料,您会发现该速率高度依赖于单个视频:全高清视频可以轻松下载 > 1?MiB/s,而诸如此类的音乐视频保持在 200?KiB 左右或以下/秒。

总结一下并澄清一些可能的误解:一些提供商可能会在流式传输时限制您的下载速率,通过他们的客户端应用程序(例如带有 html5 或 Flash 视频播放器的 youtube)或通过服务器方式。如果他们不通过服务器方式对您进行速率限制,那么下载将消耗更多带宽,因为客户端应用程序在流式传输期间可能应用的速率限制不会发生。这是消耗的带宽与原始问题不同的主要情况。


  1. 我知道这是一种轶事证据——然而,我一直观察到这种行为。

  • 如果我有足够的代表,我会否决这个答案:它_不_回答问题,关键短语是“相同的质量”。当提供商降低质量时,这不是_其他条件不变_。 (7认同)
  • @Psycogeek Youtube 是使用 DASH 的示例之一(如果此评论对您没有意义,请阅读我链接的文章的介绍部分)。这意味着客户端使用的播放器无论如何都必须请求视频的连续块。如果玩家没有运行,则从那里开始停止请求更多块是很自然的。诸如“youtube-dl”之类的下载器将继续请求更多块,直到视频完全下载。因此,使用 DASH 进行流式传输会产生更多的开销,但这可能是值得的(对于用户和提供商而言)并且可以忽略不计。 (3认同)
  • @dsollen:除非 UDP 发送方只是让数据包流动而不关心预期的接收方是否仍然存在,否则 UDP 和 TCP 都将需要定期确认;在任何一种情况下,确认都将代表总流量的很小一部分。此外,以即使没有接收到前一个数据包也可以理解每个数据包的方式格式化数据通常意味着超出TCP所需的级别开销。 (2认同)

use*_*274 20

假设我们谈论的是相同的质量(即没有节流、跳帧或较低质量的流),那么流最多将占用与下载相同的带宽量,尽管它可以按一定的时间/速率完成更方便供应商。根据视频的压缩方式,它还可能需要更多带宽 - 大多数情况下,不会发送整个图像,而只是发送帧之间的变化(或增量)。这意味着历史记录越多(即使用 Y 帧中像素 X 的蓝色色调),需要发送的历史记录就越少。这通常不会弹出太多,但是当一个流因任何原因暂停/中断时,这个“历史”就会丢失,需要重新传输,从而增加带宽,而通过下载,它可以恢复在“休息”时,并假设接收者已经有了这个信息。同样可以用于音频,尤其是在没有固定速率的情况下(即 FLAC 而不是 mp3)

跳来跳去(跳过、重绕等)也可能影响使用 - 向前越过缓冲区会减少流使用的带宽量,但任何重绕都会增加它。还会有一个中断,这将导致使用量增加(见上文),并且任何类型的“缩略图预览”(例如 youtube 和 netflix 使用的内容)也会略微增加带宽。

最后一点:压缩:这可以用于下载,但不能用于流 - 需要注意的是大多数视频已经被压缩,所以这里不会有太大的收获(尽管在超-高分辨率/质量部门)。


小智 7

流媒体将使用较少的带宽,尤其是在网络条件较差的情况下,但这是有代价的

问题在于需要发送的数据。在下载模型中,无论如何,所有数据都必须以正确的顺序到达客户手中。如果网络状况不佳并且某些数据位无法到达客户端,则必须重新发送它们,这会增加带宽使用量。如果某些数据无序到达那里,则必须在呈现之前将其重新整理好,这会降低响应速度。

在流模型中,如果某些数据没有到达客户端也没关系。如果您正在流式传输电影并且没有帧到达那里,您可以跳过它并继续前进,这样您就不会在重新发送时使用额外的带宽。如果某些帧出现乱序,则播放前进的那些;一时的昙花一现无关紧要,因此这会提高响应能力。但是,这也意味着您不一定会获得完整的数据:您所看到的都是第一次拍摄时获得的数据。

如果您必须在模型之间进行选择,请根据您想对数据执行的操作进行选择。如果您想存档它和/或可能多次查看它,请下载它,以便您确保获得所有内容。如果您不打算存档,或者只打算查看一次数据,请继续流式传输;您可能不会在单次观看时注意到差异,如果网络条件差到您确实注意到,那么下载会更糟。


mb2*_*b21 5

如果您真的要求“带宽”(字节/秒)而不是“总数据”(字节),那么关键的问题是:在什么时间段内?如果我们假设用户观看整个视频并返回相同的编解码器/质量等,并忽略流请求/响应的小开销,则返回的总数据是相等的。

现在,带宽是多少?有两种方法可以理解您的问题:

  1. 下载完成前所需时间的带宽。对于流媒体,您应该会看到高带宽峰值(当请求下一个块时),当您观看该块时,该峰值会回到零,直到您接近该块的末尾,并且带宽再次出现峰值。对于下载,您应该会看到非常高的带宽,例如 10 分钟,一旦整个视频下载完毕,带宽就会下降到零。如果你现在停止实验,下载带宽显然更高,因为它会最大限度地使用你的下行链路,直到它完成。

  2. 观看视频期间的带宽。观看视频的时间对于流媒体和下载是相同的,假设两者都立即开始观看。总数据大小也相同。由于带宽是单位时间的数据,因此这两种情况是相同的。

在下面的示例中,总下载了 40 个(数据单位)。但是对于“下载”,它在第一个时间单位中是 40,而对于“流媒体”,它在第一个时间单位内是 20(以获得一个大的初始块),然后是另外两个块的两倍 10。请注意,虽然带宽绘制在 y 轴上,但两个图形中的每一个下方的区域对应于数据(字节)——如果随着时间的推移对字节/时间进行积分,则会得到字节。