用于接收多媒体内容的方法和客户端的制作方法
【技术领域】
[0001]本发明一般地涉及基于例如但不限于HTTP(超文本传输协议)的自适应串流(streaming)技术领域，具体地涉及由客户端对分成分段的多媒体内容的接收。
[0002]本公开特别适于接收采用串流形式的直播事件。
【背景技术】
[0003]本部分旨在向读者介绍本领域的多个方面，这些方面可能涉及下文所述和/或所要求保护的本发明的多个方面。这些讨论将有助于向读者提供背景知识，以便于更好地理解本发明的各个方面。从而，应该理解的是，将从这一角度来解读这些叙述，但并不意味着将承认其为现有技术。
[0004]基于HTTP的自适应串流(还被称为多比特率切换或HAS)正快速成为用于多媒体内容分发的主要技术。在已经使用的多种HTTP自适应串流协议中，最有名的当属苹果(Apple)的 HTTP 直播串流(HLS)、微软(Microsoft)的 Silverlight 平滑串流(SSS)、Adobe的HTTP动态串流(HDS)、3GPP和MPED研发的基于HTTP的动态自适应串流(DASH)(标准化为 IS0/IEC 23009-1:2012)。
[0005]当客户端希望播放采用自适应串流的视听内容(或A/V内容)时，其首先必须获得描述如何可以获得该A/V内容的文档。这一般通过借助HTTP协议从URL (统一资源符)获得描述文档(所谓的清单文件)来实现，同样可以通过其它方式(例如广播、电子邮件、SMS等)来实现。清单文件(其是提前生成的，并由远程服务器递送给客户端)基本上列出这一 A/V内容的可用代表(representat1n)(还称为例示或版本)(根据比特率、分辨率和其它属性)。代表与给定的质量级别(比特率)相关联。
[0006]每个代表的整个数据流被分成具有相等持续时间的分段(还被称为组块)(可通过不同的URL访问)，使得客户端可以在两个分段之间从一个质量级别平滑地切换到另一质量级别。结果，视频质量在播放期间可变化但极少会中断(还被称为冻结)。
[0007]在客户端侧，基于对传输路径的可用带宽的测量来选择分段。具体地，客户端通常请求对应于比特率编码并从而对应于与所测带宽兼容的质量的分段的代表。可用带宽(在本说明书中还被称为网络带宽或带宽)指的是网络吞吐量，其单位为比特/秒。
[0008]清染(rendering)所述内容的客户端从而必须对可实现的吞吐量自己进行估计，并选择代表，以使得能够足够快地下载所述分段，以在其呈现时间进行渲染，并同时尝试最佳化质量。
[0009]根据HTTP自适应串流技术，客户端必须连续地评估可用于内容接收的带宽，以及在请求分段的代表之前确定适当的吞吐量，从而最佳化视频质量，并同时最小化接收分段过晚不能供连续显示的风险。
[0010]然而，由于当远程服务器和客户端之间的传输路径发生变化时可用带宽会发生改变(互联网吞吐量不稳定)，所以这并不是简单的折衷。
[0011]更具体地，当带宽下降时，所请求的用来下载对应于特定比特率编码的分段代表的时间会增加，并会导致在A/V内容的渲染过程中发生中断。
[0012]作为示例，在传输的开始，考虑10秒的分段持续时间、200、400、600、1200、1800、2500、4500、6500和8500kbit/s (Apple针对HLS推荐的数字)的分段代表、以及8.5Mbit/s的稳定带宽。客户端可以每10秒请求一个8500kbit/s的分段代表。假定带宽突然被除以2(4250kbit/s)。如果这一带宽下降刚好发生在针对8500kbit/s的分段代表的请求之后，则该代表将在20秒内被下载，从而晚了一个分段。
[0013]为了解决内容渲染期间的冻结的问题，因此有可能使用其中已提前下载了若干分段的缓冲器，以使得在带宽下降时有更多的余量可用于加载新的分段。
[0014]然而，长的缓冲器向端用户引入延迟。在直播事件的情况中，这些延迟是不期望的，从而优选地使用短的缓冲器。
[0015]此外，一旦已经通过HTTP协议将用于接收分段的请求发送给服务器，则中断该接收的唯一途径是关闭下层的TCP连接。
[0016]然而，这种连接关闭需要重新启动新的TCP会话，这是低效且耗时的。
[0017]由于互联网吞吐量是不稳定的并且可能在短时内发生变化，所以已经提出了对所感觉到的带宽进行某种平均，以避免对局部变化产生过于强烈的反应。于是，如果在分段的末端附近发生带宽下降时，其对所计算的平均的影响较小。
[0018]然而，基于该平均，客户端仍将选择高于新带宽的代表。如果带宽不回到较高的级另IJ，则该决定将通过所述分段累积下载延迟，这再次需要大缓冲器来进行抵御。
[0019]本公开克服了上述缺陷中的至少一个。
【发明内容】
[0020]本公开涉及用于由客户端从至少一个服务器接收多媒体内容的方法，其中所述多媒体内容被分成至少两个具有第一持续时间的连续分段，以及其中分段与至少两个代表相关耳关。
[0021 ] 根据本公开的一个实施例，所述方法包括:
[0022]〇接收分段(segment)的第一代表的至少一个片段(fragment)，所述分段的每个代表被分成至少两个具有第二持续时间的连续片段；
[0023]〇通过考虑沿客户端和所述至少一个服务器之一之间的传输路径的可用带宽，确定
[0024]■所述分段的第一代表的所有后续片段的预计递送时间，以及
[0025]■所述分段的至少一个备选代表的所有片段的预计递送时间；
[0026]〇通过考虑所述预计递送时间，在以下两种情况之间进行选择:
[0027]■接收所述分段的第一代表的至少一个后续片段；或
[0028]■接收所述分段的第二代表的至少第一片段，所述第二代表属于所述至少一个备选代表。
[0029]本公开从而提出了一种用于接收多媒体内容的新的技术，其中多媒体内容被分成分段，且其中客户端可以请求分段的一部分(或者分段的代表的一部分)，(例如以字节为单位)，而不是整个分段。
[0030]结果，根据本公开的方法提出加载分段的代表的片段，而不是分段的整个代表，以便在可用带宽增大或减少的情况下决定加载分段的同一代表的其它片段是否更好，或加载分段的最高或最低比特率的另一代表是否更好。
[0031]事实上，以上所提及的一些缺陷归因于关于接收代表的决定是针对整个分段持续时间做出的，而沿传输路径的带宽可能在非常短的时间段内发生变化。从而，如果带宽过窄，则客户端需要针对分段的接收给予长的延迟，而如果带宽过大，则客户端不能针对分段的接收最优化比特率。
[0032]因此，在与现有方法相比，根据本公开的实施例的方法可以使得客户端能够在更小的时间基础上工作。结果，当检测到带宽的减小(或增加)时，可以决定“中止”对分段的当前代表的下载，并且开始加载分段的具有较低(或较高)比特率的新代表，这与不进行任何改变的情况相比将使得分段更快地准备好(或具有更高的质量)。
[0033]具体地，根据本公开的方法可包括:为了接收所述至少一个片段，向所述至少一个服务器发送至少一个字节范围请求。
[0034]这可以利用当前的HTTP实现(尤其是HTTP/1.1选项)，通过请求字节范围而不是请求完整的分段，来完成(例如将片段的预计加载时间减少到500ms)。
[0035]应该注意的是，可以对所述字节范围请求中的至少一个进行流水线处理(pipelining)。由于针对分段的片段的请求的数量(与针对分段的一个请求相比)意味着累积延迟达到RTT的N倍(N是每分段中的片段的数量)，而不是RTT的一倍，所以这一流水线处理可以是有用的。
[0036]根据本公开的一个实施例，所述方法可以包括:以对应于所述第二持续时间的时间尺度确定对所述可用带宽的估计。
[0037]换言之，可在片段级别上估计可用带宽。
[0038]根据本公开的另一实施例，所述方法包括:以对应于所述第一持续时间的时间尺度确定对所述可用带宽的估计。
[0039]换言之，可在分段级别上估计可用带宽。
[0040]具体地，可以确定两个带宽估计，一个在片段级别，而另一个在分段级别。然后，在分段的开始处，可根据更为平均的估计来选择代表，并同时在加载分段的片段时，客户端可以考虑短期变化。
[0041]具体地，所述估计中的每一个可以是周期性地确定的，或在接收到至少一个片段后确定的，或在接收到至少一个分段后确定的，或在检测到所述传输路径中的改变之后确定的。
[0042]根据第一示例，如果所述可用带宽减少，则所述第二代表与第二比特率相关联，所述第二比特率小于与第一代表相关联的第一比特率。
[0043]本公开从而使得能够改善带宽严重下降时的鲁棒性。
[0044]根据第二示例，如果所述