专利名称：用于数据流式传输系统的数据结构的制作方法
技术领域：
本发明涉及一种数据结构，该数据结构适于存储在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)是另外一种公知的用于创建弹性视频源的技术。已经表明可以将视频代码转换设计为具有比视频编码低得多的计算复杂度。然而，并不能由此忽略计算复杂度，所以并不能产生可伸缩的视频流式传输结构。
发明内容
依据本发明的一个方面，提供了一种数据结构，用于存储流式传输系统的数据源，该数据源包括多个编码数据流，该多个数据流中的每一个都是所述数据源中的数据的独立表示，并以不同于所述多个数据流中的其它数据流的分辨率编码，所述数据结构包括报头、用于各个编码数据流的流数据结构、以及编码数据流的一个或多个分组，所述报头与所述流数据结构中的一个相链接，其中各个流数据结构包括报头、与下一个流数据结构的链接以及与所述编码数据流的第一个分组的链接。
下面详细说明使用这种数据结构的系统和方法。数据结构的复杂度取决于可能很多的相互交织的多个流中的分组，以及支持切换和恢复的需要。需要通过指针来从一个分组导向另一分组，因为在流中连续的分组通常在文件中并不是连续存储的。切换和恢复分组的写入操作需要被记录的源和目的分组的精确细节。回放过程中流间的切换首先需要识别下一个可用切换分组，随后是“from”流中的剩余分组的回放，切换分组的回放，然后是从适当的点开始回放“to”流中的分组。此外，优选地，当进行流间切换时没有明显的延迟。
优选地，所述多个编码数据流是视频数据流。也可将音频数据编码为数据流。
用于视频和音频数据流的流数据结构可以包括各个数据流的比特率编码数据。
所述数据源还可以包括用于在一个视频数据流和另一个视频数据流之间进行切换的定义了多个切换点的切换流，切换数据流的数据流结构包括关于可以从哪些视频流和分组进行切换以及可以切换到哪些视频流和分组的数据。
所述数据结构的报头可以包括与最后一个流数据结构的链接。流数据结构的报头可以包括与编码数据流的最后一个分组的链接。
本发明允许根据网络状况的变化来伸缩压缩视频的传输比特率。
在上述系统中，不必以一个固定比特率传输所产生的音频视频流，由此所述数据结构必须能够支持网络瞬间支持的任何速率下的传输。
已经表明该系统和数据结构在GPRS网络上运行良好，其极好地利用了可用网络带宽，提供了令人满意的多媒体质量。
该系统和数据结构被设计为克服IP网络(尤其是移动IP网络)的特性，以向用户提供具有最小起始延迟的质量一致的多媒体。
下面参考附图详细说明本发明的示例，图中图1是使用本发明的音频-视频数据流式传输系统的示意图；图2是图1的系统中所使用的视频编码层级的示意图；图3是能够实现视频流之间的无失配切换的视频编码结构的示意图；图4是适用于图1的系统的客户端-服务器结构的示意图；图5a和图5b分别示出了标准TKPT传送分组结构和该结构为图1的系统所进行的变型结构；和图6a-6c是示出了根据本发明一个实施例的包括音频-视频数据流的数据结构的各个方面的示意图。
具体实施例方式
图1是使用本发明的一个实施例的音频-视频数据流式传输系统的示意图。
服务器10直接从编码器20或者从文件30接收编码多媒体内容，并且把这些内容提供给一个或更多客户端40-60。服务器10执行少许处理(即选择要向前传输的分组)来支持独立访问多个内容的多个客户端40-60。在服务器10中不执行媒体的编码或者代码转换。
原理上，服务器10以相同的方式操作来自编码器20的实时流和来自文件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将实时或者存储的多媒体内容编码成弹性编码表示。在低比特率下将音频编码成单个编码比特流，因此该音频本身是非弹性的。然而，由于音频所需的比特率一般比视频的低，因而如果以弹性方式对视频进行编码，那么可以将音频和视频的混合编码视为弹性的。
在4.8kbit/s下使用AMR(自适应多速率)编码器对音频进行编码。将视频编码成弹性表示。编码器20以类似于分层的方式创建独立视频流的层级结构。此层级结构不是通过使各个流依赖于层级结构内所有较低的流来创建的，而是对各个流进行独立编码。这种层级结构是公知的，被称为“联播(simulcast)”。
虽然只说明了使用低比特率AMR方案来编码音频数据，但是也支持其它AMR编码速率和其它编码标准，诸如MP3。可以以与下面用于视频的描述类似的方式将不同速率下的编码音频组织成独立流的层级结构，但是由于各个音频帧一般是独立编码的，所以编码表示之间的切换更为简单。
使用ITU-T标准H.263的扩展所创建的视频层级结构包括帧内流(intra stream)200，用于随机访问视频流；和一个或者多个播放流(playstream)210a、210b，用于内容的正常观看。以不同比特率对各个播放流210a、210b进行编码，由此使给定客户端40-60在适合于其与服务器10的当前网络连接110的速率下接收这些播放流。该层级结构还包含切换流(switch stream)220、230、240，其允许从帧内流200到最低速率播放流210a以及播放流之间的切换。
由于编码算法采用运动补偿预测，因而在播放流中的任意点处进行比特流间切换即便是可能的，也将由于不同比特流的相同时刻的重构帧之间的不匹配而导致视频缺陷。这些视频缺陷还将在一段时间中蔓延。
在当前的视频编码标准中，只有在将来帧/区域不使用当前切换位置(即，在接入图像(access picture)处)之前的任何信息的位置处才可以进行比特流之间的完美(无失配)切换。此外，通过以固定(如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.量化源编码链接图像在第三种方法中，通过基于可在“ftp://standard.pictel.com/video-site/中获得的“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”中说明的概念的技术对链接图像进行编码，本文称为量化源图像。
在图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的大小来使其包含的数据可多于多个往返延迟所传输的数据，为少量重传提供时间以从丢包状态中恢复。这使得能够从大部分丢包情况恢复，而不影响已解码的媒体质量，并使连接具有半可靠性。
最后，同样通过在解码缓冲区44中积累数据，当接收比特率小于编码比特率时或当接收速率降为零时，客户端40可以使媒体质量在一段时间内保持一致。
由于以独立于编码速率的速率将数据流式传输到客户端40并存储在解码缓冲区41中，所以有必要对数据解码进行正确定时，而不是简单地解码并尽快放映。为此目的使用时间戳，该时间戳也可用于音频和视频的同步。
由于网络变化，以字节为单位测量的客户端的解码缓冲区41中的数据量可能随时间变化。另外，根据数据量所表示的媒体放映时间的长度所测量的解码缓冲区41中的数据量也会随时间变化。对于实时内容的流传输这意味着如果将第一数据以最小延迟(从捕获该第一数据并对其编码的时刻起算)发送到客户端40，则数据不可能填充解码缓冲区41。因此，发送到客户端40的第一数据必须为旧数据，即，该数据代表客户端40与服务器10相连之前的某一时间所发生的事件。然后随着解码缓冲区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的反馈，即可获知客户端40接收了多少数据，从而可以确定播放流之间的切换。
客户端的解码缓冲区41中的数据积累能够恢复一些网络故障，例如抖动、丢包和可变吞吐量。显而易见，不可能从所有网络故障中恢复，除非将解码缓冲区41设计为包含整个媒体内容并且直到接收了所有数据时才开始放映。由于这种情况不是流传输，而是下载，所以需要一种从严重网络故障中得到恢复的策略。
当网络吞吐量下降，并在相当长的时间内低于最低速率播放流的编码速率时，解码缓冲41中的数据量将降低，并且最终变为零。此时，将停止向用户的放映。然而，在服务器10中将继续填充环形缓冲区。结果，当网络恢复到可以重新传输最低速率的播放流时，客户端40所需的下一个数据很可能已不在服务器的环形缓冲70、80、90中，因为该数据可能已被更新的数据所覆盖。
为了从这种情况中恢复，服务器10必须重新开始流传输，就像从客户端建立了一个新的连接一样服务器10必须找到帧内流中的一点，并从该点开始流传输，然后通过链接流切换到最低速率播放流。对于用户的影响为漏失了从解码缓冲区41变为空到当服务器开始传送该帧内流时这段时间内的媒体。
因为服务器10知道客户端何时开始解码以及已经成功接收了多少数据，其将获知客户端的解码缓冲区是否变空。因此，可以在帧内流图像处重新开始，而不需从客户端获得特殊的消息。然而，为了进行系统复原，例如从服务器和客户端的不同时钟速率中恢复，在这种情况下从客户端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变满时起，服务器记录发送到网络缓冲区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.一种数据结构，用于存储流式传输系统的数据源，该数据源包括多个编码数据流，该多个数据流中的每一个都是所述数据源中的数据的独立表示，并以不同于所述多个数据流中的其它数据流的分辨率编码，所述数据结构包括报头(600-680)、用于各个编码数据流的流数据结构(700)、以及编码数据流的一个或多个分组(800)，所述报头(600-680)与所述流数据结构(700)中的一个相链接，其中各个流数据结构(700)包括报头(705，740，750)、与下一个流数据结构的链接(710)以及与所述编码数据流的第一个分组的链接(720)。
2.根据权利要求1所述的数据结构，其中所述多个编码数据流为视频数据流。
3.根据权利要求1或2所述的数据结构，包括编码为数据流的音频数据。
4.根据权利要求2或3所述的数据结构，其中用于视频和音频数据流的流数据结构(700)包括用于各个数据流的比特率编码数据(740)。
5.根据权利要求2、3或4所述的数据结构，其中所述数据源还包括切换流，所述切换流定义了用于在一个视频数据流和另一个视频数据流之间进行切换的转换点，该切换数据流的数据流结构包括关于可以从哪些视频流和分组进行切换和可以切换到哪些视频流和分组的数据。
6.根据上述任一权利要求所述的数据结构，其中所述数据结构的报头包括与最后一个流数据结构的链接。
7.根据上述任一权利要求所述的数据结构，其中所述流数据结构的报头包括与编码数据流的最后一个分组的链接(730)。
8.根据权利要求1至7中任意一项所述的数据结构，其编码在计算机可读介质上。
全文摘要
一种数据结构，用于存储流式传输系统的数据源，该数据源包括多个编码数据流，该多个数据流中的每一个都是所述数据源中的数据的独立表示，并以不同于所述多个数据流中的其它数据流的分辨率编码，所述数据结构包括报头(600－680)、用于各个编码数据流的流数据结构(700)、以及编码数据流的一个或多个分组(800)，所述报头(600－680)与所述流数据结构(700)中的一个相链接，其中各个流数据结构(700)包括报头(705，740，750)、与下一个流数据结构的链接(710)以及与所述编码数据流的第一个分组的链接(720)。
文档编号H04N7/24GK1643932SQ03807049
公开日2005年7月20日 申请日期2003年3月14日 优先权日2002年3月27日
发明者蒂莫西·拉尔夫·杰布, 迈克尔·埃尔林·尼尔森 申请人:英国电讯有限公司