数据流式传输系统和方法

文档序号:7891218阅读:206来源:国知局
专利名称:数据流式传输系统和方法
技术领域
本发明涉及一种适于在IP(网际协议)网络上流式传输音频和视频内容的系统和方法。具体来说,本发明适用于其中可用比特率固有地会由于物理网络特性和/或与其他通信量进行争用而变化的情况。例如,本发明适用于通过GPRS(通用分组无线业务)或3G网络到移动手持终端(如PDA(个人数字助理))的多媒体流式传输。
背景技术
诸如电缆调制解调器和ADSL(非对称数字用户线)调制解调器的新的数据网络接入技术以及压缩技术的发展和免费客户端软件的供应驱动着因特网上视频流式传输的增长。该技术的使用正在以极快的速度增长,几乎每六个月翻一番,据估计在2000年的使用量为5亿个流。然而,由于拥塞和较大的启动延迟,使用户对于因特网流式传输仍存在误解。
目前的IP网络并不能很好地适合于视频内容的流式传输,因为这些IP网络存在丢包(packet loss)、延迟和抖动(延迟改变),以及变化的最大吞吐量,所有这些都破坏了最终用户对多媒体内容的享受。
实时视频应用需要所有分组及时到达。如果分组丢失,则会破坏编码器和解码器之间的同步,并且差错会在再现视频中蔓延一段时间。如果分组过度延迟,则对于必须实时工作的解码器,这些分组会变得无用,并被当作丢失。在预测视频编码系统(如H.263)中,丢包及其对于再现视频的视觉影响尤其显著。通过在视频流中引入差错保护,可以减小但不能消除丢包的影响。研究表明这种复原技术只可以最小化而不能消除丢包的影响。
在持续丢包(其表示吞吐量的长期降低)的情况下,需要流式传输系统能够降低其长期需求。这通常意味着必须降低流式传输媒体的比特率。
可以对诸如H.263和MPEG-4的标准压缩技术进行管理以提供一种能够动态地改变其编码率的多媒体源。本文将具有这种属性的视频源描述为弹性源,即,能够适应网络吞吐量的长期变化的视频源。这通常是通过提供连续的自适应视频比特率来实现的。这是可能的,因为与音频编解码器不同,视频压缩标准并没有指定绝对的工作比特率。
可以将视频流式传输系统设计成提供具有变化比特率的编码流,其中比特率响应于客户端的反馈而即时地适应可用网络带宽。通过控制传输速率,使得其在丢包的情况下快速降低并且在其它时候缓慢增加,可使该系统做到网络友好。
然而,有两个原因使这个方案不可实现。第一,实时视频编码通常需要大量的处理能力,这样就使该方案不能支持很多用户。第二,最终用户对整体质量的感觉将会因瞬时质量的快速变化而受到负面影响。
对于单向流式传输应用,发送器与接收器之间的延迟只在启动的时候可感知。因此一般技术以延迟为代价来弥补丢包和抖动。倘若视频流的平均吞吐量需求符合平均可用带宽,那么可以将接收器缓冲区的大小设计为涵盖所预期的延迟变化。
市场上的主导流式传输系统被认为是使用了有效的客户端缓冲来降低因特网上可能遇到的抖动的影响。虽然这是有帮助的,但当填充缓冲区时也会产生较大的启动延迟,通常在5到30秒之间。这些系统还包括使客户端适应可用带宽的变化的技术。尽管这些技术的细节并不是公开的,但可猜想这些技术都在单个文件中使用了多数据率编码(SNR可伸缩性),并采用智能传输技术(例如视频画面速率的服务器侧降低)以保持音频的质量。可以想到,这些大量的缓冲允许相当大部分分组重发,虽然重传本身会遇到相同的网络特性。是否重发丢失数据的决定取决于这个因素和其它几个因素。这些技术一般只应用于单播传输。一般通过前向纠错或者基于接收端的可伸缩性来优化多播传输系统的性能,例如可参见RLM and RLC.S.McCanne,“Receiver driven layered multicast”,Proceedings of SIGCOMM 96,Stanford.CA.August 1996,以及L.Vicisano,L.rizzo and J.Crowcroft,’TCP-like congestion control for layered multicastdata transfer’,Infocom’98。
上述缓冲区的使用使系统能够克服丢包和抖动。然而它并不能克服网络上无足够可用比特率的问题。如果视频资料的长期平均比特率需求超过了网络上的可用平均比特率,那么客户端缓冲区将最终耗尽,并且视频的再现将会停止直到缓冲区被重新填满。网络可用比特率与对内容进行编码的速率之间的不匹配程度决定了暂停以重新填充缓冲区的频度。
如上所述,大部分视频压缩算法,包括H.263和MPEG-4,都可以实现为提供连续的自适应比特率。然而一旦对视频和音频进行了压缩,它们就变得没有弹性,并且需要按编码比特率传输。
虽然网络抖动和网络吞吐量的短期变化可以通过操作接收端缓冲区来吸收,但是只有在能够吸收网络吞吐量的长期变化时,才能够实现弹性。
分层编码是一种用于创建弹性视频源的公知技术。分层视频压缩使用层级编码方案,其中通过接收顺序地添加在基本表示(representation)上的多个较高层并进行解码,来提高接收端的质量。无论何时,各个客户端都可以根据其与视频源的当前网络连接性来接收任何数量的这些视频层。在最简单的实现方案中,提供了在多播情况下有利的对于网络状况的粗粒度自适应。已经将分层视频压缩与用户端缓冲相结合来增加对于网络状况的细粒度自适应。然而,已经表明,分层编码技术效率比较低,并且其一般需要在客户端进行更多处理,对于移动设备(其处理容量可能较低)这将导致一些问题。
译码(transcoding)是另外一种用于创建弹性视频源的公知技术。已经表明可以将视频译码设计为具有比视频编码低得多的计算复杂度。然而,并不能由此忽略计算复杂度,所以并不能产生可伸缩的视频流式传输结构。

发明内容
根据本发明的一个方面,提供了一种包括服务器的数据流式传输系统,该服务器被配置成向客户端流式传输多个编码数据流中的一个,所述多个数据流中的每个数据流都是按与所述多个数据流中的其它数据流不同的分辨率编码的公共数据源的独立表示,所述服务器包括一发送器和一第一缓冲区,所述发送器被配置成通过所述第一缓冲区向所述客户端传输所述编码数据流的数据分组,其中,所述发送器被配置成,对所述第一缓冲区的内容进行监控,并且在从所述第一缓冲区中检测到预定准则的情况下,进行切换以传输所述多个数据流中的另一个数据流。
整个系统的一些关键特性是●按网络友好的方式来改变传输速率;●将传输速率与媒体编码速率解耦;●在不引起启动延迟的条件下在客户端处构造数据缓冲区;●通过利用客户端缓存来平滑网络吞吐量的短期变化;●通过在按不同比特率编码的多个多媒体流之间进行切换来调节长期平均带宽需求,以匹配网络中的可用资源;以及,●通过利用客户端缓存,在不影响用户感觉到的质量的前提下,通过选择性地重新传输丢失的分组来为丢包提供恢复。
本发明可以根据网络状况的变化来改变压缩视频的传输比特率。
在本发明中,不必按单一固定的比特率来传输所产生的音频-视频流,这样就使得可以按网络瞬时支持的任何速率来进行传输。通过在接收器中建立数据缓冲区来提供对传输损失的恢复,使得在需要丢失数据以进行解码和放映之前有时间重新传输丢失数据。
在任一时刻,只将这种流的层级中的一个视频流和一个音频流传输给客户端。这是以所谓的用于粗粒度自适应性的“联播切换”和用于细粒度自适应性的传输速率变化的组合的形式来实现的。
本系统在GPRS网络上运行表现很好,有效地利用了可用网络带宽,以提供满意的多媒体质量。
已经将本系统设计成可以克服IP网络,尤其是移动IP网络的特性,以向用户提供具有最小启动延迟的一致质量的多媒体。
所述发送器可以配置成根据所述第一缓冲区的内容来确定在客户端处缓存的数据量,其中,所述预定准则包括一确定要在所述客户端处缓存的数据的预定级。在客户端确认接收到数据分组时,可以将该数据分组从所述第一缓冲区中删除。所述发送器可以配置成,根据从所述第一缓冲区中删除的最近的数据分组和由所述客户端所解码的分组数目的估计,来确定在所述客户端处缓存的数据量。
所述第一缓冲区可以包括一镜像缓冲区,其用于存储关于所述第一缓冲区中的分组的数据,所述发送器被配置成,利用该镜像缓冲区中的数据来监控所述第一缓冲区的内容。
可以利用扩展TPKT协议来向所述客户端传输数据分组,该数据分组包括一报头,该报头包含一解码时标(timestamp)和一数据流标号。
本系统还包括多个发送器,每个发送器通过相应的第一缓冲区与相应的客户端进行通信,以传输依据相应的预定准则所确定的所述多个数据流中的一个。
所述数据流可以是编码视频数据。
所述发送器可以被配置成在数据分组的传输中对音频分组和视频分组进行多路传输。相邻的音频分组和视频分组可以表示用于在基本上相同时刻表示的音频和视频信息。
所述数据流可以是编码音频数据。
所述分辨率可以是数据的编码比特率。
所述服务器可以包括一编码器,其被配置成接受馈送的数据并且将所馈送的数据编码成所述多个编码数据流。
所述系统还可以包括多个缓冲区,其中,所述编码器被配置成将每个编码数据流输出到所述多个缓冲区中的相应缓冲区中,所述发送器被配置成从所述多个缓冲区中的相应缓冲区中获得用于各数据流的数据分组。
所述服务器可以包括一用于存储所述多个编码数据流的文件源。
根据本发明的另一方面,提出了一种数据流式传输系统,其包括客户端和服务器,所述服务器被配置成向所述客户端流式传输多个编码数据流中的一个,所述多个数据流中的每个数据流是按与所述多个数据流中的其它数据流不同的分辨率编码的公共数据源的独立表示,所述服务器包括发送器和第一缓冲区,而所述客户端包括接收缓冲区,其中,所述发送器被配置成通过所述第一缓冲区向所述客户端传输所述编码数据流的数据分组,其中,所述客户端被配置成将所接收到的数据分组存储在所述接收缓冲区中,并向所述服务器确认已接收,其中,所述发送器被配置成当接收到接收确认时从所述第一缓冲区中删除分组,所述服务器被配置成在预定准则得到满足的情况下切换到所述多个数据流中的另一个数据流,所述预定准则包括对所述第一缓冲区的内容的分析。
所述分组可以包括分组序列数据,所述客户端被配置成基于该序列数据来请求重新传输未接收到的分组,所述服务器被配置成在接收到一重新传输请求时从所述第一缓冲区重新传输分组。
根据本发明的又一方面,提供了一种用于向客户端流式传输多个编码数据流中的一个的方法,所述多个数据流中的每个数据流都是按与所述多个数据流中的其它数据流不同的分辨率编码的公共数据源的独立表示,该方法包括以下步骤通过第一缓冲区向所述客户端传输所述编码数据流的数据分组;对所述第一缓冲区的内容进行监控;以及在从所述第一缓冲区检测到预定准则的情况下,进行切换以传输所述多个数据流中的另一数据流。
所述多个数据流可以被各按不同的比特率进行编码,所述方法还包括以下步骤最初时传输最低比特率数据流的数据分组。
所述预定准则可以包括确定要在客户端缓存的数据量。
所述预定准则可以包括一个或更多个网络吞吐量阈值。
可以通过以下步骤来计算网络吞吐量对传入所述第一缓冲区的字节数进行计数;将所述第一缓冲区的大小减去所计数的字节数;以及将所述结果除以自传输开始起的时间。
所述方法还可以包括以下步骤在一个以上的时间间隔中测量网络吞吐量以确定吞吐量变化。
所述预定准则可以包括确定足以维持所述多个数据流中的其它数据流的网络吞吐量。
所述方法还可以包括以下步骤不考虑在客户端处缓存的数据量而以最大速率传输数据,其中所述预定准则包括按该最大速率确定的网络吞吐量。
所述数据流可被编码成根据该数据流中的先前画面而预测编码的多个画面的画面序列,所述数据流包括分布在所述画面序列中的预定时段中的量化源入口画面(access picture),其中,所述量化源入口画面的编码方法包括以下步骤将画面编码成预测画面;以及如果在所编码的预测画面中没有指示关于画面面积的信息,那么当编码成量化源入口画面时,将量化器指数设置为细量化值。


下面参照附图详细说明本发明的示例,其中图1是根据本发明实施例的音频-视频数据流式传输系统的示意图;图2是图1的系统中所使用的视频编码层级的示意图;图3是允许实现视频流之间的无失配切换的视频编码结构的示意图;图4是适用于图1的系统的客户端-服务器结构的示意图;图5a和图5b分别是示出标准TKPT传送分组结构和为本发明实现的对该结构的变型的示意图;以及图6a-6c是示出包括适于存储用于本发明的数据的音频-视频数据流的数据结构的各个方面的示意图。
具体实施例方式
图1是根据本发明实施例的音频-视频数据流式传输系统的示意图。
服务器10直接从编码器20或者从文件30接收编码多媒体内容,并且把这些内容提供给一个或更多客户端40-60。服务器10执行少量处理(即选择要向前传输的分组)来支持独立访问多个内容的多个客户端40-60。在服务器10中不执行媒体的编码或者译码。
原理上,服务器10对于来自编码器20的实时播送流(live stream)和来自文件30的预编码流都以相同的方式进行操作。在此具体实施例中,说明了实时播送媒体的流式传输。在随后的实施例中讨论流式传输媒体与预编码文件的不同。
服务器10包括多个环形缓冲区70-90。对于各个客户端40-60,有一个分组发送器100的实例。分组发送器100确定何时以及从缓冲区70-90中的哪一个读取下一个分组,读取所选分组并通过网络连接110将其发送到各个客户端。
需要从服务器10到各个客户端40-60建立半可靠网络连接110来确保几乎所有发送分组都能接收到,由此使对于用户感觉质量的干扰最小。因此在网络连接110的各个终端中使用缓冲区(120,130)以使得可以重传丢失的分组。还希望网络连接110是网络友好的,即,当没有发生拥塞时可以提高所使用的比特率,并且当发生拥塞时大幅度降低所使用的比特率。
虽然将系统组件示例并说明为集成和分立组件的组合,但是应意识到也可以使用不同的结构。例如,可以使用外部编码器20和/或文件存储器30。同样地,缓冲区130可以与客户端设备40-60形成一体。
图2是图1的系统中使用的视频编码层级结构的示意图。编码器20将实时播送或者存储的多媒体内容编码成弹性编码表示。将音频按低比特率编码成单个编码比特流,因此该音频本身是非弹性的。然而,由于音频所需的比特率一般比视频的低,因而如果以弹性方式对视频进行编码,那么可以将音频和视频的混合编码视为弹性的。
使用AMR(自适应多速率)编码器按4.8kbit/s对音频进行编码。将视频编码成弹性表示。编码器20以类似于分层的方式创建独立视频流的层级结构。此层级结构不是通过使各个流依赖于层级结构内所有较低的流来创建的,而是对各个流进行独立编码。这种层级结构是公知的,被称为“联播(simulcast)”。
虽然只说明了使用低比特率AMR方案来编码音频数据,但是也支持其它AMR编码速率和其它编码标准,如MP3。可以按与下面对于视频所述方式类似的方式将不同速率下的编码音频组织成独立流的层级结构,但是由于各个音频帧一般是独立编码的,所以编码表示之间的切换得到简化。
使用对ITU-T标准H.263的扩展所创建的视频层级结构包括帧内流(intra stream)200,允许随机访问视频流;和一个或更多个播放流(playstream)210a、210b,用于内容的正常观看。以不同比特率对各个播放流210a、210b进行编码,由此使给定客户端40-60可以按适合于其与服务器10的当前网络连接110的速率接收这些播放流。该层级结构还包含切换流(switching stream)220、230、240,其允许从帧内流200到最低速率播放流210a的切换以及播放流之间的切换。
由于编码算法采用运动补偿预测,因而在播放流中的任意点处进行比特流间切换即便是可能的,也将由于不同比特流的相同时刻的重构帧之间的不匹配而导致视觉缺陷。这些视觉缺陷还将在一段时间中蔓延。
在当前的视频编码标准中,只有在将来帧/区域不使用当前切换位置(即,在入口画面处)之前的任何信息的位置处,才可以进行比特流之间的完美(无失配)切换。此外,通过以固定(如1秒)间隔放置入口画面,可获得VCR功能,例如用于流式传输视频内容的随机访问或者“快进”和“快退”(增加的回放速率)。用户可以跳过一部分视频并且在任何入口画面位置重新开始播放。类似地,通过只传输入口画面可以获得增加的回放速率,即快进。
然而,公知的是,入口画面所需要的比特比运动补偿预测帧的要多。因此,使用帧内流200和切换流220、230、240。切换流的主要属性是,即使使用不同的参考帧也可以获得相同的画面。
层级结构的主要用途是使服务器10将播放流210a或210b传输到客户端40-60,以实现以下两种操作之间的最佳平衡,第一种操作是在客户端40-60处构建接收数据的缓冲区以提供对分组丢失和网络吞吐量的突然下降的弹性应变,第二种操作是根据网络连接110瞬时支持的最高比特率将最佳播放流210a或210b提供给客户端40-60。
帧内流200是一系列帧内编码画面(201,202),其用于提供随机访问和从严重差错状况的恢复。播放流210a、210b包括预测编码画面(211a,212a,213a,214a,215a;211b,212b,213b,214b,215b),这些预测编码画面可以是双向预测的,并且可以根据多个参考画面来预测。播放流210a、210b还包括定期入口画面216a、217a;216b,217b。切换流220,230,240包括一系列链接画面(221,222;231,232;241,242)。
为各个流类型指定环形缓冲区70-92,为各条内容的各个帧内流(70)、播放流(80,85)和切换流(90,91,92)各指定一个缓冲区。
当客户端40首先与服务器10连接时,服务器10从存储帧内流的环形缓冲区70中找出合适的帧内画面(例如,帧内画面201),并将该画面发送到客户端40。然后服务器10选择链接画面(221)以从帧内流220切换到具有最低编码比特率的播放流210a,随后从该播放流开始提供服务(从213a开始)。
将分组传输到客户端40是一个独立的过程,其传输速率取决于网络状态和所使用的传输协议。然而,希望最初时传输速率大于具有最低编码比特率的播放流210a的编码比特率。这将使客户端40可以在接收到数据并进行解码的时刻立即开始解码并将媒体呈现给用户,同时使客户端40可以在其解码缓冲区中积累超出的压缩媒体数据。
在入口画面(例如以上示例中的入口画面217a)处,(例如,由于网络容量增加或减小)客户端40和/或服务器10可以确定更为合适的不同播放流。在上面的示例中,通过服务器10传输链接画面232而非入口画面217a来完成从低速率的播放流210a到较高速率的播放流210b的切换。链接画面232链接到较高速率播放流210b的播放流画面215b,以使客户端40接收该播放流。以类似的方式完成向比特率降低的播放流的切换。
已经研究出三种对链接画面进行编码的方法。各种方法提供了下面三者之间的不同折衷由于切换而引起的偏移累积、实际切换的比特率方面的成本,以及由于对允许无偏移低比特率切换的常规类型画面进行编码而产生的对于单个播放流的质量的影响。
1、预测编码链接画面在第一种方法中,将链接画面生成为预测画面。按如下方式对这些画面进行编码在重构时,其与目的播放流中的同步入口画面的重构是相似的,例如,具有很小的均方差。可以将入口画面编码为预测画面。用于对链接画面进行编码的比特数确定了重构的链接画面与重构的入口画面之间的匹配度,并且由此确定了由于切换而产生的偏移量。然而,每次切换产生的偏移都将累积。
2、帧内编码链接画面在第二种方法中,将链接画面生成为帧内画面。按如下方式对这些画面进行编码在重构时,其与目的播放流中的同步入口画面的重构是相似的,例如,具有很小的均方差。可以将入口画面编码为预测画面。用于对链接画面进行编码的比特数确定了重构的链接画面与重构的入口画面之间的匹配度,并且由此确定了由于切换而产生的偏移量。然而,对于给定的不匹配量,帧内编码链接画面通常比预测编码链接画面需要更多比特数。对于链接画面使用帧内编码防止了偏移的累积。
3、量化源编码链接画面在第三种方法中,通过基于以下文献中所述概念的技术对链接画面进行编码VCEG-L27,A proposal for SP-frames,submitted by Marta,Karczewicz and Ragip Kurceren at the ITU-TelecommunicationsStandardization Sector Video Coding Experts Group’s Twelfth MeetingEibsee,Germany,9-12 January,2001,可在ftp://standard.pictel.com/video-site/处获得,本文将其称为量化源画面。
在图3中示出了用于量化源画面的编码结构。分别在步骤300和310中以相同的量化指数对源画面和运动补偿预测独立地进行量化,在步骤320中相减之前对它们进行转换,并在步骤330中对它们进行可变长度编码。通过在步骤340中将减法器320的输出与量化和转换310中的输出相加,并将在步骤350中对该结果进行逆变换和反量化来形成重构画面。将重构画面存储在画面存储器360中。结果,重构画面就是量化源画面,并且该重构画面不依赖于运动补偿预测。因此,当根据不同参考画面进行预测时,可以同样地重构给定的源画面,并由此可以实现无偏移切换。运动补偿预测不是非相关的,其减少了待进行可变长度编码的信号的熵,并且由此减小了由对画面进行编码而产生的比特数。
把入口画面也编码成量化源画面,并选择与链接画面相同的编码模式(帧内编码或帧间编码)选择和量化器选择。这确保了在目的端播放流中,该链接画面的重构与同步入口画面的重构一样。
对链接画面进行编码所需的比特数由对应的入口画面的编码来确定。用于对入口画面进行编码的比特数是根据如何进行量化来确定的,但是通常大于用于对预测画面进行编码的比特数并小于对帧内画面进行编码的比特数。这是因为使用了预测,该编码比帧内编码更为高效,但预测误差的量化使得其没有一般预测有效。由此,量化源画面的使用使得能够进行无偏移切换,但是代价是播放流的编码效率的降低。
通过与预测画面相同的H.263语法来编码量化源画面,但通过将MPPTYPE的前三位设置为保留值“110”来与预测画面相区别。
量化源画面的周期性编码可以导致画面的静态区域中的跳动效果(beating effect)。下面对其进行说明。在一般的预测编码中,不对已经编码为源画面的合理表示的画面静态区域进行修改。在编码量化源画面的这些区域时,必须对预测进行量化,并且如果通过用于画面的非静态区域的量化指数进行量化,则使区域发生变化,可能使其更糟,但是无论在什么情况下,都会使其产生变化。这种变化即为跳动效果。
通过下面的方式克服该跳动效果当对于画面的一个区域的预测提供了足够好的源表示时,不需要传输信息,并且由此不会改变该区域。所以当把入口画面编码成量化源画面时,进行测试以确定如果画面已经编码成预测画面而不是量化源画面,是否要传输关于该区域的信息。如果不传输信息,则将步骤300和310的量化和步骤350的反量化所使用的量化指数设定为较小的值,将减法器320的输出(通常称为预测误差)设定为零,由此该新重构画面的该区域等于利用细量化器进行了量化的先前重构画面的对应区域。在H.263和其它标准中,量化指数的范围从1(细量化)到31(粗量化)。较小的指数一般是指小于或等于8的值。这使重构画面的非必要变化最小,同时也使必须传输的信息量最小。然而,需要以对应链接画面中的比特率为代价,其中预测误差不可能为零,而且必须使用相同的细量化器。
图4是适于在图1的系统中使用的客户端-服务器结构的示意图。
客户端40包括网络缓冲区130、解码缓冲区41和解码器42。服务器10包括上述环形缓冲区70、80、90;以及用于各个客户端的分组发送器100和网络缓冲区120。
客户端40将解码缓冲区41中的信息量和其接收数据的速率通知给服务器10。服务器10使用此信息来确定何时进行播放流之间的切换。例如,如果客户端40积累了一个阈值以上的数据,比方说解码缓冲区41中有15秒数据,而客户端40以大于或等于层级结构中的下一个更高速率播放流的编码速率的速率接收数据,则服务器10可以在下一个链接画面处将客户端的分组发送器100切换到下一个更高的播放流。
类似地,当由客户端40在其编码缓冲区41中所积累的数据量小于阈值时,服务器10可以在下一个链接画面处将客户端的分组发送器100切换到下一个较低的播放流。
总体效果为,根据网络的拥塞状态,传输速率以网络友好的方式变化,但是由于客户端解码缓冲区41中积累的数据,用户察觉不到因传输速率的短期改变造成的质量变化。通过切换到具有不同编码速率的流来应付传输速率的长期变化,从而当网络容许时提高质量,并当网络吞吐量下降时降低质量,而不必停止放映或者将破坏的媒体放映给用户。
客户端的解码缓冲区41用于降低网络性能变化对放映给用户的媒体质量的影响。将缓冲区所处理的网络特性分为三类分组抖动、丢包和可变吞吐量。实际中这三种网络特性不是独立的,都与网络拥塞相关,并且在移动网络的情况下,与物理层的性能降低相关。
通过将传输速率与媒体编码率分开,当网络状况较好时可以填充客户端的解码缓冲区41,从而当网络状况不太好时提供复原时间。
解码缓冲区41中的数十秒数据的积累向用户掩盖了相同量级的分组抖动(延迟变化)。实际中,由于将更大的抖动分类为暂时连接中断(由下面的差错恢复处理来应对),所以这种数据积累将屏蔽掉所有的分组抖动。
通过在解码缓冲区41中积累数据,为在需要对丢失的分组进行解码之前重传丢失分组提供了时间。同样地,通过设计解码器缓冲区41的大小来使其包含的数据可多于多个往返延迟所传输的数据,为少量重传提供时间以从丢包状态中恢复。这使得能够从大部分丢包情况恢复,而不影响已解码的媒体质量,并使连接具有半可靠性。
最后,同样通过在解码缓冲区41中积累数据,当接收比特率小于编码比特率时或者当接收速率降为零时,客户端40可以使媒体质量在一段时间内保持一致。
由于以独立于编码速率的速率将数据流式传输到客户端40并存储在解码缓冲区41中,所以有必要对数据解码进行正确定时,而不是简单地解码并尽快放映。为此目的使用时标,该时标也可用于音频和视频的同步。
由于网络变化,以字节为单位测量的客户端的解码缓冲区41中的数据量可能随时间变化。另外,根据数据量所表示的媒体放映时间的长度所测量的解码缓冲区41中的数据量也会随时间变化。对于实时播送内容的流式传输这意味着如果将第一数据以最小延迟(从捕获该第一数据并对其编码的时刻起算)发送到客户端40,则数据不可能填充解码缓冲区41。因此,发送到客户端40的第一数据必须为旧数据,即,该数据代表客户端40与服务器10相连之前的某一时间所发生的事件。然后随着解码缓冲区41的填充,该缓冲区41中的最新数据变得越来越新,同时放映给用户的媒体根据事件发生的实际时间保持固定延迟。
在编码之后,服务器将编码数据在其环形缓冲区70、80、90中缓冲一段固定的时间,以使得当客户端40与服务器10相连时,可以将‘旧’数据传输给客户端40。随着客户端解码缓冲区41的填充,从环形缓冲区70、80、90中读出数据的点越来越接近这些缓冲区中的最新数据。
优选地,环形缓冲区70、80、90以及客户端解码缓冲区41的最佳大小使得各个缓冲区可以包含相同的数据量(以该数据所表示的媒体放映时间来测量)。
实现半可靠数据连接的传输协议使用分别在服务器10和客户端40中的网络缓冲区120、130。通常,数据被保留在服务器的网络缓冲区120中,直到确认客户端40已经接收到该数据和之前的所有数据。类似地,当该数据和之前的所有数据已经被接收并被传送到解码缓冲区41时,从客户端的网络缓冲130中删除该数据。从而,服务器10在单向传输延迟限定的时间中获知保留在其自己的网络缓冲区120中的数据,从而获知哪些数据已被客户端40成功地接收。
这意味着不需要为服务器10提供超出传输协议本身需要的从客户端40到服务器10的反馈,服务器10即可获知客户端40接收了多少数据,从而可以确定播放流之间的切换。
客户端的解码缓冲区41中的数据积累能够恢复一些网络故障,例如抖动、丢包和可变吞吐量。显而易见,不可能从所有网络故障中恢复,除非将解码缓冲区41设计为包含整个媒体内容并且直到接收了所有数据时才开始放映。由于这种情况不是流式传输,而是下载,所以需要一种从严重网络故障中得到恢复的策略。
当网络吞吐量下降,并在相当长的时间内低于最低速率播放流的编码速率时,解码缓冲41中的数据量将降低,并且最终变为零。此时,将停止向用户的放映。然而,在服务器10中将继续填充环形缓冲区。结果,当网络恢复到可以重新传输最低速率的播放流时,客户端40所需的下一个数据很可能已不在服务器的环形缓冲70、80、90中,因为该数据可能已被更新的数据所覆盖。
为了从这种情况中恢复,服务器10必须重新开始流式传输,就像从客户端建立了一个新的连接一样服务器10必须找到帧内流中的一点,并从该点开始流式传输,然后通过链接流切换到最低速率播放流。对于用户的影响为漏失了从解码缓冲区41变为空到当服务器开始传送该帧内流时这段时间内的媒体。
因为服务器10知道客户端何时开始解码以及已经成功接收了多少数据,其将获知客户端的解码缓冲区41是否变空。因此,可以在帧内流画面处重新开始,而不需从客户端获得特殊的消息。然而,为了进行系统复原,例如从服务器和客户端的不同时钟速率中恢复,在这种情况下从客户端40向服务器10发送控制消息。
原理上,从文件的流式传输与实时播送流式传输相同。实际上,前者更为简单。由于当需要时可以从文件中读取数据,所以不需要设立环形缓冲70、80、90。然而,服务器10使用相同的技术来填充客户端40的解码缓冲区41并在播放流之间切换。在解码缓冲区41变空的情况下,不需要在与带有帧内流画面的内容中的随后点重新开始,因为当网络吞吐量重新变得充分时可以继续放映用户只会在一段时间内察觉到没有媒体放映。
使用帧内流可以实现多种技巧模式,如快进、快退和随机访问。
通过在覆盖环形缓冲区70、80、90中的‘旧数据’之前将其写入文件,由于总可以得到用于流式传输到客户端的数据(只能从文件而不是从环形缓冲区70、80、90中读取),因而可以避免上述的解码缓冲区41变空、用户漏失利用帧内流画面进行恢复之前的内容的问题。
该功能还使得客户端可以暂停所放映媒体一段不确定的时间,并随后继续流式传输。这还使得用户可以在该暂停之后进行快进以跟上实时播送流。
上述客户端-服务器结构中所测试的传输协议的实现是基于ISO TCP传输协议TPKT的,该协议在由Y.Pouffary所著的RFC-2126“ISOTransport Service on top of TCP(ITOT)”中有详细说明。
标准TPKT协议定义了如图5a所示的报头,随后是净荷。分组长度表示以八位字节为单位的报头和净荷的组合长度。
在用于本发明的实现中,扩展了TPKT的报头(在图5b中示出了该报头的示例),随后为净荷。分组长度表示以八位字节为单位的报头、时标(如果存在)和净荷的组合长度。T为表示是否存在时标的位,M为表示净荷是否包含音频或视频信息的位。
如上所述,需要时标来进行数据解码的正确定时。嵌入分组报头的信息包括分组长度、分组中数据的时标和流标号。
设置流标号以使得可将音频和视频复用到单个TCP连接中。这确保了音频和视频传输的同步。如果使用分立的多个TCP连接,则可能这些连接对于网络特性的响应略有不同,并且将产生不同的吞吐量,这将最终导致客户端解码缓冲区中的数据量(以放映时间来测量)的极大不同。虽然可以对这些不同进行管理,但是通过使用单个TCP连接并将同一放映时间的音频和视频复用在相邻分组中可完全避免该问题。事实上,向只有视频的系统中添加音频只需要与关联的视频同时发送音频分组不需要另外的控制。
服务器10试图尽可能快地发送分组。最初时,一个接一个地发送多个分组而不考虑网络容量,因为这些分组只是填充服务器的网络缓冲区120。当网络缓冲区120变满时,因对套接字发送功能的调用受到阻塞而限制了传输处理,分组发送到网络缓冲区120的速率与网络上的传输速率相一致。
当存储在客户端的数据量到达一个阈值(例如30秒)时也可以限制传输速率。当客户端的解码缓冲区41具有此数据量时,服务器10限制传输速率以保持此充满程度。
通过对已经发送到网络缓冲区120的字节进行计数、从该计数中减去网络缓冲区的大小、并除以从开始传输起经过的时间,来估算网络吞吐量。使用所传输字节的两次计数以及发送这些字节所需时间的两次测量、根据一对数据计算吞吐量、然后周期性地将不再使用的对重设为零,并在其间切换,来计算网络吞吐量的短期估算。例如,如果每200秒进行一次重新设置,则在从重设之后的200秒到再次重设之前的40秒这个范围之内变化的一个时间段上估计网络的吞吐量。
如果服务器10想要尽快地进行流式传输则该技术的效果是令人满意的。但是如上所述,当解码缓冲区41中的数据量超过阈值时,服务器10限制其传输速率以保持恒定的缓冲区充满状态。在这种情况下,将网络吞吐量估计为当前播放流的编码比特率。当在此状态中时,网络能够传输比当前流式传输的播放流速率更高的播放流,但是因为服务器10由于其自身的速率限制不能对网络吞吐量进行真实估计,所以服务器10不能进行切换。为了避开此状态,服务器定期地忽略客户端解码缓冲区的充满阈值,并在给定的时间段内或者对于给定的数据量以全速率进行流式传输。从网络缓冲区120变满时起,服务器10记录发送到网络缓冲区120的字节数和所用的时间,该时间由发送函数的阻塞调用来检测。然后服务器10估算可实现的吞吐量,并使用该吞吐量来确定是否要切换到更高速率的播放流。
如前所述,通过获知保存在网络缓冲区120中的数据,服务器10能够间接获知客户端40接收了哪些数据,以及哪些数据被传送到其解码缓冲区41中。然后使用此信息来确定何时在播放流之间进行切换,以及何时激活差错恢复过程。然而,在大多数套接字实现中并不支持服务器的网络缓冲区120的内容和充满度的可见性。为了监控网络缓冲120的内容,采用了镜像(mirror)缓冲区120a。镜像缓冲区120a不存储发送到网络缓冲区120的实际数据,而只存储所发送的字节数和数据的时标。在已知网络缓冲区120的大小并假设其始终充满的情况下,服务器10通过镜像缓冲区120a来访问网络缓冲区120中的最旧数据的时标,该时标与客户端的解码缓冲区41中的最新数据的时标相同。
在测试中,已发现服务器10的网络缓冲区120始终充满这一假设在大部分时候是正确的。这是因为对传输过程进行了控制以尽快发送到网络缓冲区120。如果网络缓冲区120变得不再充满,则影响为低估客户端40的数据量,该影响大部分情况下是安全的,这是因为主要问题是客户端40的数据用尽,而不是溢出。实际上,可以将解码缓冲区41设计得比需要存储的最大数据流还要大。无论在什么情况下,如果解码缓冲区41变满,则客户端40停止从网络缓冲区130读取数据,这将反过来阻止服务器网络缓冲区120变空,并停止传输。
为了确定客户端解码缓冲区41中的确切数据量,服务器还需要获知客户端当前正在解码和放映的数据分组的时标。服务器10基于两个假设来计算确切数据量第一,客户端40在服务器10发送第一个分组之后立即开始解码;第二,在流式传输期间客户端的时钟与服务器的时钟无显著偏差。
实际上两个假设都是有效的。将客户端40设计为一旦接收到数据立即开始解码,从而关于服务器所估算的放映时间的任何错误都将导致对解码缓冲区41中的数据量的低估,如上所述这并不是问题。与被缓冲的数据量相比,在一般流式传输会话过程中的客户端和服务器时钟之间的偏移是可以忽略的。例如,假如偏差为百万分之100的差别,则要花10000秒或者接近三个小时才能发生一秒钟偏移。在累积了大量偏移的极少数情况下,客户端40可以通过使用控制消息,如前述所发送的用于解码缓冲区下溢的消息,来向服务器10告警。
服务器10最初以最低比特率对播放流进行流式传输,以使客户端40解码并立即向用户放映媒体,同时还增加了解码缓冲区41中的数据量以从网络故障中恢复。如果网络具有足够能力来支持更高速率的播放流的传输,则服务器10应该在适当的时刻切换到更高速率的播放流来进行流式传输。
有很多种可能的策略可用于确定何时切换到更高速率的播放流。优选地,客户端40应当在其解码缓冲区41中具有足够的数据以能够在预定时间(例如15秒)内继续解码和放映媒体。优选地,例如在最近60秒中测量的最近达到的网络吞吐量应该足以维持要切换到的播放流的流式传输;即,最近达到的网络吞吐量速率应该大于或等于播放流的比特率。目的是避免流之间的频繁切换,因为对于用户而言该切换可能比较低速率的恒定质量更为令人讨厌。
为了实现此目的,优选地,向下切换(switching down)决定包括与向上切换(switching up)决定成比例的滞后。例如,当客户端40在其解码缓冲区41中不再具有足够的数据以将解码和媒体放映持续一段时间(例如8秒)时,可能触发向下一个更低速率的播放流的向下切换。在具有三个或者更多个播放流的结构中,并且当前流传输的播放流为第三或者甚至更高的速率播放流,此策略不会导致立即降到层级底层,因为入口画面只是定期发生的,并且希望在第一次向下切换之后恢复到解码缓冲区的充满状态,从而不必进行第二次切换。
图6a-6c是示出用于存储适用于本发明的音频-视频数据源的数据结构的各个方面的示意图。
图6a所示的主数据结构使得可以在单个文件中存储多个音频播放流、一个帧内视频流、和多个视频播放和切换流。
由于本发明中所创建和使用的音频视频数据源具有可一次传输到客户端的多个编码流,所以不可能在传统的顺序文件中进行存储。例如,对于视频,可以在各个播放流中对具体的源画面进行编码,并且还可以在帧内流和一些或者全部切换流中进行编码。
该文件包含一种数据结构,在图6a中示出了该数据结构的示例,随后是流数据。该数据结构包括报头600,其包含关于流(音频、视频、切换等)的数目和类型的信息。对于各种类型的流的第一个和最后一个实例,该数据结构还包括指向各个流的报头的指针610-680(以相对于文件起始位置的偏移量表示)。
每个指针620-680指向包括流报头700的流数据结构,该流报头700包含指向同一类型的下一流报头的指针710、分别指向流的第一个和最后一个分组的指针720、730。每个流类型使用特定的流报头类型,然而对于所有流报头类型某些元素是相同的流标号705、指向相同类型的下一流报头的指针710、以及分别指向该流的第一个和最后一个分组的指针720、730。在图6b中示出了只包含这些共同元素的示例流报头。播放和音频流报头还包含该流的编码比特率。切换流报头包含该切换流可以切换自的播放流的流标号和可以切换到的播放流的流标号。
每个流包括一个分组序列,各个分组由分组数据结构表示,该分组数据结构的示例示出在图6c中。每个分组数据结构包括分组报头800和净荷810。报头包括的数据包括指向流中下一分组的指针801、时标802、分组序号803、分组大小804、以及帧号805(即,该分组(可能和其它分组一起)表示的视频画面或者音频帧的序号)。切换分组另外还包含“from”播放流和“to”播放流(切换分组在两者之间进行比特率切换)中的分组序号。切换流分组报头有效地限定了切换点,并且包含切换前要从“from”流播放的最后一个分组的序号以及切换后来自“to”流的要播放的第一个分组的序号。序号从0开始,并且不为负。在切换时,可以使用指针来支持流之间的引导,不过在本特定实施例中没有采用此方法。
在向文件中添加时,指向最后一个流数据结构和最后一个分组的指针是很有用的,因为利用这些指针可以迅速访问文件要进行扩展的点,而不需要搜索整个文件。
数据结构的复杂度取决于相互交织的可能很多流中的分组,以及支持切换和恢复的需要。需要通过指针来从一个分组导向另一分组,因为在流中连续的分组通常在文件中并不是连续存储的。切换和恢复分组的写入操作需要被记录的源和目的分组的精确细节。回放过程中流间的切换首先需要识别下一可用切换分组的标识,紧随其后是“from”流中的剩余分组的回放,切换分组的回放,然后是从适当的点开始回放“to”流中的分组。此外当进行流间切换时必须没有可感知的延迟。
在测试中,使用BTCellnetTMGPRS网络对基于文件的流和实时播送流的情况进行了研究。使用台式奔腾(Pentium)PC来运行解码器和服务器。客户端为通过红外线与Motorola TimeportTMGPRS移动电话相连的Compaq iPaqTM。
在只有视频的结构中,使用两种切换流,其比特率分别为6kbit/s和12kbit/s。
该系统如所期望地运行。从帧内流开始传输,然后切换到6kbit/s播放流,在该播放流停留一段时间,因实际传输速率大于6kbit/s,因而在客户端积累了数据。然后当积累了足够的数据时,并且短期平均接收速率大于12kbit/s时,切换到更高速率的播放流。
在长期会话过程中,有时会由于网络吞吐量的下降而切换回较低速率的播放流。并且极少会由于相当一段时间内网络不能向客户端发送数据而中断媒体放映。
对于大部分会话都具有此整体效果,用户可以观看连续的媒体放映,偶尔有质量变化,但是没有通常与误码和丢包相关联的失真。只有极少情况下,才会由于严重的网络故障和吞吐量的降低而使媒体放映完全暂停。
权利要求
1.一种数据流式传输系统,包括服务器(10),其被配置成向客户端(40,50,60)流式传输多个编码数据流中的一个,所述多个数据流中的每个数据流都是按与所述多个数据流中的其它数据流不同的分辨率编码的公共数据源的独立表示,所述服务器(10)包括一发送器(100)和一第一缓冲区(120),所述发送器(100)被配置成通过所述第一缓冲区(120)向所述客户端(40,50,60)传输所述编码数据流的数据分组,其中,所述发送器(100)被配置成,对所述第一缓冲区(120)的内容进行监控,并且在从所述第一缓冲区(120)中检测到预定准则的情况下,进行切换以传输所述多个数据流中的另一数据流。
2.如权利要求1所述的系统,其中,所述发送器(100)被配置成根据所述第一缓冲区(120)的内容来确定在所述客户端(40,50,60)处缓存的数据量,其中,所述预定准则包括确定要在所述客户端处缓存的数据的预定级。
3.如权利要求2所述的系统,其中,在所述客户端(40,50,60)确认接收到数据分组时,将该数据分组从所述第一缓冲区(120)中删除。
4.如权利要求3所述的系统,其中,所述发送器(100)被配置成,根据从所述第一缓冲区(120)中删除的最近的数据分组和对由所述客户端(40,50,60)所解码的分组数目的估计,来确定在所述客户端(40,50,60)处缓存的数据量。
5.如前述任一权利要求所述的系统,其中,所述第一缓冲区(120)包括一镜像缓冲区(120a),其用于存储关于所述第一缓冲区(120)中的分组的数据,所述发送器(100)被配置成,利用该镜像缓冲区(120a)中的数据来监控所述第一缓冲区(120)的内容。
6.如前述任一权利要求所述的系统,其中,利用扩展TPKT协议来向所述客户端(40,50,60)传输数据分组,该数据分组包括一报头,该报头包含一解码时标和一数据流标号。
7.如前述任一权利要求所述的系统,还包括多个发送器(100),每个发送器(100)通过相应的第一缓冲区(120)与相应的客户端(40,50,60)进行通信,以传输依据相应的预定准则所确定的所述多个数据流中的一个。
8.如前述任一权利要求所述的系统,其中,所述数据流是编码视频数据。
9.如权利要求8所述的系统,其中,所述发送器(100)被配置成在数据分组的传输中对音频分组和视频分组进行多路传输。
10.如权利要求9所述的系统,其中,相邻的音频分组和视频分组表示用于在基本上相同时刻表示的音频和视频信息。
11.如权利要求1到7中的任何一项所述的系统,其中,所述数据流是编码音频数据。
12.如前述任一权利要求所述的系统,其中,所述分辨率是所述数据的编码比特率。
13.如前述任一权利要求所述的系统,其中,所述服务器(10)包括一编码器(20),其被配置成接受馈送的数据并且将所馈送的数据编码成多个编码数据流。
14.如权利要求13所述的系统,还包括多个缓冲区(70,80,90),其中,所述编码器(20)被配置成将每个编码数据流输出到所述多个缓冲区(70,80,90)中的相应缓冲区中,所述发送器(100)被配置成从所述多个缓冲区中的相应缓冲区中获得用于各数据流的数据分组。
15.如前述任一权利要求所述的系统,其中,所述服务器(10)包括一用于存储所述多个编码数据流的文件源(30)。
16.一种数据流式传输系统,包括客户端和服务器,所述服务器(10)被配置成向所述客户端(40,50,60)流式传输多个编码数据流中的一个,所述多个数据流中的每个数据流是按与所述多个数据流中的其它数据流不同的分辨率编码的公共数据源的独立表示,所述服务器(10)包括一发送器(100)和一第一缓冲区(120),而所述客户端(40,50,60)包括一接收缓冲区(130),其中,所述发送器(100)被配置成通过所述第一缓冲区(120)向所述客户端(40,50,60)传输所述编码数据流的数据分组,其中,所述客户端(40,50,60)被配置成将所接收到的数据分组存储在所述接收缓冲区(130)中,并向所述服务器(10)确认已接收,其中,所述发送器(100)被配置成在接收到接收确认时从所述第一缓冲区(120)中删除分组,所述发送器(100)被配置成在预定准则得到满足的情况下切换到所述多个数据流中的另一数据流,所述预定准则包括对所述第一缓冲区(120)的内容的分析。
17.如权利要求16所述的系统,其中,所述分组包括分组序列数据,所述客户端(40,50,60)被配置成基于该序列数据来请求重新传输未接收到的分组,所述服务器(10)被配置成在接收到一重新传输请求时从所述第一缓冲区(120)重新传输分组。
18.一种用于向客户端流式传输多个编码数据流中的一个的方法,所述多个数据流中的每个数据流都是按与所述多个数据流中的其它数据流不同的分辨率编码的公共数据源的独立表示,该方法包括以下步骤通过第一缓冲区向所述客户端传输所述编码数据流的数据分组;对所述第一缓冲区的内容进行监控;以及在从所述第一缓冲区检测到预定准则的情况下,进行切换以传输所述多个数据流中的另一数据流。
19.如权利要求18所述的方法,其中,所述多个数据流被各按不同的比特率进行编码,所述方法还包括以下步骤最初时传输最低比特率数据流的数据分组。
20.如权利要求18或19所述的方法,其中,所述预定准则包括确定要在客户端缓存的数据量。
21.如权利要求18、19或20所述的方法,其中,所述预定准则包括一个或更多个网络吞吐量阈值。
22.如权利要求21所述的方法,其中,通过以下步骤来计算网络吞吐量对传入所述第一缓冲区的字节数进行计数;将所述第一缓冲区的大小减去所计数的字节数;以及将所述结果除以自传输开始起的时间。
23.如权利要求22所述的方法,还包括以下步骤在一个以上的时间间隔中测量网络吞吐量以确定吞吐量变化。
24.如权利要求22或23所述的方法,其中,所述预定准则包括确定足以维持所述多个数据流中的其它数据流的网络吞吐量。
25.如权利要求22到24中的任何一项所述的方法,还包括以下步骤不考虑在客户端处缓存的数据量而以最大速率传输数据,其中所述预定准则包括按该最大速率确定的网络吞吐量。
26.如权利要求18到25中的任何一项所述的方法,其中,所述数据流被编码成根据该数据流中的先前画面而预测编码的多个画面的画面序列,所述数据流包括分布在所述画面序列中的预定时段中的量化源入口画面,其中,所述量化源入口画面的编码方法包括以下步骤将画面编码成预测画面;以及如果在所编码的预测画面中没有指示关于画面面积的信息,那么当编码成量化源入口画面时,将量化器指数设置为细量化值。
27.一种计算机程序,包括计算机程序代码装置,其用于当在计算机上运行时,执行权利要求17到24中的任何一项的步骤。
28.如权利要求27所述的计算机程序,其被具体实现在计算机可读介质上。
全文摘要
描述了一种数据流式传输系统和方法。服务器(10)被配置成向客户端(40,50,60)流式传输多个编码数据流中的一个。所述多个数据流中的每个数据流都是按与所述多个数据流中的其它数据流不同的分辨率编码的公共数据源的独立表示。服务器(10)包括一发送器(100)和一第一缓冲区(120)。发送器被配置成通过第一缓冲区(120)向客户端(40,50,60)传输所述编码数据流的数据分组。发送器(100)被配置成,对第一缓冲区(120)的内容进行监控,并且在从第一缓冲区(120)中检测到预定准则的情况下,进行切换以传输所述多个数据流中的另一数据流。
文档编号H04N7/24GK1643875SQ03807048
公开日2005年7月20日 申请日期2003年3月27日 优先权日2002年3月27日
发明者迈克尔·埃尔森·尼尔森, 蒂莫西·拉尔夫·杰布 申请人:英国电讯有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1