用于向客户端设备分发视听内容的系统和方法
【专利说明】用于向客户端设备分发视听内容的系统和方法
[0001]本发明大体上涉及向客户端设备分发视听内容，互连第一网络与第二网络的互连设备，连接至第二网络的客户端设备，以及连接至第一网络的适于提供视听内容的仪器。
[0002]自适应比特率流传输(ABS)是一种流行的HTTP流传输技术，其用于在计算机网络和HLS( “HTTP实时流传输”)上的流传输多媒体中，其中HLS是基于HTTP( “超文本传输协议”，如规范文件RFC2616中所定义的)且由苹果公司开发的媒体流传输通信协议。HLS按照以下方式工作:将整个AV流分成一系列基于HTTP的小文件下载，每个文件下载包含整个可能无界的传输流的一个短块。当播放流时，解码AV流的客户端设备可从包含以不同比特率编码的相同材料的多个不同可替代性流中选择，从而允许流传输会话适于可用网络资源和/或客户端设备的处理资源。在流传输会话开始时，客户端设备下载具有M3U或m3u8文件扩展的文本文件形式的播放列表。该文本文件包括可用于相关AV内容的各种流的元数据。对应于各比特率的各种流也称作层。
[0003]通过平滑流传输实现类似的ABS方法，平滑传输是互联网信息服务(IIS)媒体服务的特征，是由微软公司提供的集成的基于HTTP的媒体分发平台。与HLS不同(其中，在HLS中，AV流切割成多个包含具有播放列表的块的文件)，平滑流传输依靠切割成块的单个AV文件，每块文件包含描述符，其指示在AV内容中的参考时间以及相关层。然而，协议基础和益处是等同的。
[0004]类似地，人们可考虑Adobe系统的HTTP动态流传输(HDS)以及HTTP上的动态自适应流传输，一种由运动图像专家组开发的多媒体流传输技术并被称作MPEG DASH,其与HDS、HLS以及平滑流传输相关。
[0005]基于HTTP的流传输技术非常便利，因为HTTP允许穿过防火墙并依靠TCP( “传输控制协议”，如规范文件RFC793定义的)保证数据完整性。然而，在ABS背景中HTTP的单播性质正在给内容分发网络(CDN)运营商造成巨大的可扩展性问题，该可扩展性问题阻止运营商对于实时流传输采用ABS。另外，TCP可能引入延迟并且数据转发过程中的连接丢失严重影响用户角度的体验质量(QoE)。
[0006]为了以可扩展方式对于实时流传输执行ABS，需要网络服务运营商解决由多个用户同时观看相同频道导致多个并发单播会话而造成的可扩展性问题。
[0007]应注意，无论传输视听内容的流的比特率是自适应的或是固定的，在更一般性的基于单播会话的视听内容分发背景中，存在这种可扩展性问题。
[0008]在更一般性的方法中，当CDN运营商提供或设想提供新设施或服务而客户端设备依赖现有机制时，会出现问题。由于客户端设备由其他厂商而不是CDN运营商开发，所以升级客户端设备以采用新设施和/或新服务可能很难设置。实际上，与网关不同，这种客户端设备例如是由独立于CDN运营商的公司开发、运行在智能手机、平板电脑、PC(个人计算机)游戏机、连接的TV等上的应用软件以及在市场上存在的许多应用或播放器，这将需要昂贵的集成和验证过程以允许所有应用或播放器兼容于新设施或新服务。
[0009]根据第一方面，这种新设施或服务旨在以对客户端设备透明的方式克服上述与CDN背景中现有内容分发机制的单播本质相关的可扩展性问题。
[0010]根据第二方面，这种新设施或服务旨在以对客户端设备透明的方式提供从用户的角度来看增强的QoE。例如，这种新设施或服务旨在克服AV内容分发期间连接丢失对QoE的影响。
[0011]期望的是克服现有技术的上述缺陷。
[0012]具体地，期望的是提供这样的解决方案，其允许以对客户端设备透明的方式在视听内容分发背景中采用新设施或服务。
[0013]此外，期望的是提供这样的解决方案，其允许以对客户端设备透明的方式在视听内容分发背景中降低网络带宽消耗。
[0014]还期望提供这样的解决方案，其允许以对客户端设备透明的方式在另外的自适应比特率背景中降低网络带宽消耗。
[0015]此外，期望提供这样的解决方案，其允许以对客户端设备透明的方式从用户的角度来看提尚QoE0
[0016]还期望提供这样的解决方案，其允许限制隐含在视听内容分发中的设备的处理资源消耗。
[0017]为此，本发明涉及用于向客户端设备分发视听内容的方法，其中，互连设备互连第一网络至第二网络，客户端设备连接至第二网络，适合于提供视听内容的仪器连接至第一网络。该方法是这样的，使得所述仪器执行:从客户端设备接收请求接收视听内容的第一请求；将重定向消息发送至客户端设备，该重定向消息将客户端设备重定向至在互连设备中实现的代理。该方法还是这样的，以使得代理执行:从客户端设备接收请求接收视听内容的第二请求；以及用作仪器和客户端设备之间的中继器。
[0018]因此，由于朝向互连设备中的代理重定向，所以能够以对客户端设备透明的方式且更容易地采用新设施或服务。实际上，当需要时，对于CDN运营商来说，执行互连设备的升级通常比升级客户端设备更容易，因为与所述客户端设备不同，这种互连设备(例如家庭网关)通常由运营商管理。
[0019]根据具体特征，第一请求和第二请求是请求接收成单播流形式的视听内容的请求，上述仪器适于在实时流传输中提供视听内容，当视听内容可通过仪器以至少一个多播流的形式得到时，上述仪器将重定向消息发送至客户端设备，以及当用作中继器时，代理执行:加入上述至少一个多播流；以及将以至少一个多播流的形式接收的数据转换成单播流形式的数据。
[0020]因此，降低了第一网络的带宽消耗，并且限制了互连设备的处理资源消耗。实际上，由于代理不需要监听大量消息交换以确保客户端设备受益于在整个第一网络中建立多播传输，所以限制了处理资源消耗。
[0021]根据具体特征，重定向消息包括用于通知至少一个多播地址以及至少一个关联端口的参数，并且请求接收成单播流形式的视听内容的请求包括用于通知至少一个多播地址和至少一个关联端口的上述参数。方法还使得代理加入与至少一个多播地址和至少一个关联端口对应的至少一个多播流。
[0022]因此，独立于仪器的实现和有效定位，该方法是灵活且可扩展的。
[0023]根据具体特征，重定向消息包括用于通知可用于成至少一个多播流形式的视听内容的层数的参数，并且请求接收成单播流形式的视听内容的请求包括该通知层数的参数。此外，代理根据层数确定至少一个多播地址和/或至少一个关联端口。
[0024]因此，整个第一网络上的多播传输以及自适应比特率流传输的原理可共同适用于视听内容的分发。
[0025]根据具体特征，重定向消息包括用于通知一个多播地址和一个关联端口以及用于通知上述层数的参数，并且请求接收成单播流形式的视听内容的请求包括上述用于通知一个多播地址和一个关联端口以及用于通知层数的参数。此外，代理根据包括于上述请求中的一个多播地址和一个关联端口以及层数来确定一个关联端口并为每层确定一个多播地址。
[0026]根据具体特征，重定向消息包括用于通知一个多播地址和一个关联端口以及用于通知上述层数的参数，并且请求接收成单播流形式的视听内容的请求包括上述用于通知一个多播地址和一个关联端口以及用于通知层数的参数。此外，代理根据包括于上述请求中的一个多播地址和一个关联端口以及层数为所有层确定一个多播地址以及并为每层确定一个关联端口。
[0027]因此，上文的两个具体特征允许限制包括于重定向消息中的数据量。
[0028]根据具体特征，在多个层可用于成至少一个多播流形式的视听内容并且仪器适于使用超文本传输协议实时流传输提供视听内容的情况下:重定向消息包括代表与视听内容的播放列表相关的统一资源定位符的参数；请求接收成单播流形式的视听内容的请求包括表示统一资源定位符的上述参数。此外，上述代理执行:基于上述统一资源定位符请求上述播放列表；接收上述播放列表；对所述播放列表执行解析，以确定与每个层相关联的一个层播放列表；从每个加入的多播流接收一个层播放列表；发送一个或多个上述接收的播放列表至客户端设备；从客户端设备接收请求，其中该请求指示与一个层相关联的播放列表或者指示与一个层相关联的播放列表的文件；以及根据指示的与一个层相关联的播放列表或者根据指示的上述文件选择多播流。
[0029]因此，在HLS背景中，降低了第一网络的带宽消耗，并且限制了互连设备的处理资源消耗。
[0030]根据具体特征，在多个层可用于成至少一个多播流形式的视听内容并且代理已加入与一个层对应的一个多播流的情况下，上述代理执行:检测客户端设备需要从该一个层切换至另一层的需求；加入与上述另一层对应的多播流；离开与该一个层对应的多播流。
[0031]因