专利名称：呈现从媒体流获得的媒体的方法和系统的制作方法
技术领域：
本发明一般涉及数据信号传输技术。
背景技术：
介绍数字媒体流技术可允许用户看到和/或听到从诸如媒体发送单元等远程位置收到的数字媒体。客户机或接收单元处的用户可选择文件用于观看。用户可替换地从实时编码器选择数据用于观看。来自所选择的文件/编码器的媒体或数据可作为媒体流向接收单元发送，在接收单元为用户播放或呈现这些媒体或数据。对文件的选择可包括各种情形。例如，用户可点击网站处的电影预告片，或在通过某个因特网供应商看电视时换频道。因为此媒体常常包括数据以同时创建音频和视像感觉，所以可称其为“多媒体”数据或内容。
由于精确呈现此类多媒体所需的数据量的缘故，可能在将数据发送到客户单元之前在编码器处对其进行压缩和编码。要为呈现目的而再现原始的媒体，通常在呈现媒体之前要对其进行解压缩和解码。编码器和解码器两者都可利用缓冲来补偿内容的比特率中的任何可变性。此过程有时被类比成漏桶模型，其中编码器根据漏桶进行编码，而客户单元具有相似大小的桶来防止下溢。这是由于内容的比特率在某种程度上是可变的，并且桶的大小基本上是比特率最大可变性的度量。
传输媒体流出于实用目的，承载来自媒体流编码器的音频和/或视频的媒体流通常是不连续的，而相反被分成多个包以供传输。在某些格式中，此类包包括一个或多个有时称作关键帧的内部帧或I帧。一个I帧作为单独图像来编码，而不参考以前或以后的帧。
下溢当接收单元用完要解码(或呈现)的数据，此情形就称为“下溢”。当接收单元准备好对下一帧进行解码(或呈现)，但接收单元还未收到(或解码)该帧的所有数据时，下溢发生。
下溢的实际可见到的表现形式是运动视频呈现中暂时性的中断(即，“打嗝”或“结巴”)，这不是合乎需要的效果——即流畅地播放运动视频。例如，经受下溢的接收单元不是以固定频率(例如，15帧每秒)显示运动视频，而是显示一帧视频流，后跟者可注意到的延时，再显示下一帧。这可能持续几秒或甚至几分钟。
当选择新的文件或编码的内容时(例如，换频道)，更具备下溢的条件。如果接收单元一收到和解码传入的新频道的媒体流时就立即呈现这些帧时，下溢的情况很可能发生。
相反，将对多媒体数据的呈现延迟足以填满客户边的缓冲的时间段是很常见。当对多媒体数据进行解码和呈现时，接收单元取出存储在其缓冲内的数据。但是，当接收单元呈现已解码的数据时，更多已编码的数据被下载以重新填入缓冲。只要下载数据和回放数据一样快从而缓冲从不完全是空的，则文件应会流畅地播放。
上述设计成防止下溢的常规技术可能在用户选择与实际向用户呈现该选择之间产生讨厌的延迟。
发明内容
本文所描述的各个实施例提供呈现从媒体流获得的媒体的方法和系统。本文中所描述的至少一个实现测量在配置成向用户呈现多媒体的下游组件处收到多媒体流的速率(测得速率)；并至少部分地利用测得速率来确保一定持续长度(测得持续长度)的时间，来缓冲呈现之前所收到的多媒体。
所有附图中用同样的标号来引用同样的元素和特征。
图1所示是能够(完全或部分地)实现本文中所描述的至少一个实施例的示例性媒体流网络拓扑的示意图。
图1A所示是能够(完全或部分地)实现本文中所描述的至少一个实施例的示例性媒体流网络拓扑的示意图。
图2所示是本文中所描述的一种方法的实现的流程图。
图3所示是本文中所描述的一种方法的实现的流程图。
具体实施例方式
概述以下系统和方法减少缓冲延迟，同时缓解多媒体呈现中的断续现象。某些实现可减少缓冲延迟并同时完全避免呈现中的断续现象。发送单元将来自所选文件或现场编码的会话的媒体流化传输到客户单元(下文中用术语“源”(source)来指文件或会话、或其等效物)。术语“流式传输速率”(streaming rate)用于标识媒体从发送单元流式传输到客户单元的速率。一接收到媒体，客户单元可立即或随后向客户或用户呈现流式的媒体。数据用于呈现的速率称为呈现速率。平均呈现速率可约等于平均流式传输速率；但是，在瞬间的时间点处，流式传输速率和呈现速率可能是不同的。
在流式传输媒体之前，发送单元向客户单元发送涉及该媒体的咨询数据。咨询数据将在以下具体描述，它包括诸如发送单元流式传输媒体的加速速率、加速间隔、各缓冲值、启动概况、和/或推荐或估算缓冲持续时间等各种组件。加速速率是发送单元试图发送数据的流式传输速率，是相对于呈现速率表达的，或可以表达为每秒比特数或每秒字节数形式的绝对值。发送单元能在称为加速间隔的一段时间以诸如呈现速率的两倍(2×)等某个加速速率开始流式传输。典型的加速速率可以在1.0×、1.2×、1.5×、2.0×、和3.0×的范围中，尽管这些仅仅是例子，且取决于发送单元及介于发送单元与客户单元之间的网络的特性可能出现任何其它值。
客户单元可缓冲数据以在呈现期间有足够多的数据来避免下溢情况。客户单元至少能以两种方式向缓冲添加数据。第一，客户单元可在开始呈现多媒体之前预先进行缓冲。在此实例中所有收到的数据都被缓冲。但是，此类缓冲导致启动延迟，所谓启动延迟是在例如用户按播放和实际看到或听到多媒体呈现之间的时期。第二，客户单元还可在呈现媒体的同时，在加速间隔期间进行缓冲，因为客户单元可用比其呈现数据更快的速率来接收数据。在后面的实例的一个例子中，呈现率可以在每秒1兆字节(Mbps)。发送单元可在加速间隔期间以2×或2Mbps流式传输媒体。客户单元可在加速间隔期间缓冲此过剩的数据，同时利用数据进行呈现。
在某些实现中，咨询数据可包括启动概况。一般而言，启动概况可涉及在呈现中的一个或多个点为避免下溢所需或所推荐的缓冲量。发送单元可在发送媒体流之前编译估算的启动概况。在各种实现中，计算出以估算的加速速率满足启动概况的估算或第一启动时间。启动时间是客户应从客户单元从开始接收媒体流直至开始呈现该媒体的时候应积累的缓冲量的度量。此缓冲量可用比特的单位或以时间单位来度量，其中时间单位仅仅是比特值除以平均比特率。
一旦客户单元开始接收媒体流，启动时间即可被验证或重新计算。某些实现可利用所测得客户单元接收媒体流的加速速率来重新计算启动时间或缓冲持续时间。使用启动概况以及在加速间隔期间所缓冲的数据量的实际度量，可允许计算出更准确的第二或测得启动持续时间。其它实现可仅在开始呈现多媒体之前，利用测得加速速率来验证估算启动持续时间的准确性。
在一些实现中，本方法可将测得加速速率与较先估算加速速率相比并从而采取动作。如果比较示出测得加速速率慢于估算加速速率，那么本方法可重新计算缓冲时间并进行更长时间的缓冲。如果以超过估算速率的速率接收数据，那么本发明能够缩短缓冲时间。与现有技术相比，以此方式计算所得的启动前的缓冲量可以充分减少。对启动概况的重新计算可以在客户开始接收数据之后的任何时间发生。例如可在例如100毫秒等有规律的间隔发生，或可在初始估算启动时间的固定分数发生——例如初始计算所得的缓冲时间的50％。
客户单元是最接近于向用户呈现文件的设备，或换言之，客户单元是最下游的设备。媒体路径沿途的各种延迟、瓶颈和/或其它中介情况导致客户单元比上游组件处在进行启动计算的更佳位置。
除了其它优点以外，允许客户单元决定在启动之前缓冲数据多长时间可减少缓冲时间中的不准确性，不这样的话，中介事件可能会导致不准确性。例如，上游发送单元可为估算计划向客户单元流式传输数据的估算的传输速率计算缓冲持续时间。实际上客户单元可能以不同的(例如，较高或较低的)速率收到媒体流。如此由客户单元所作的计算可能比发送单元处作出的计算要更为准确。客户单元可对其接收数据的速率有最准确的见解，并且能够最准确地计算其应当进行缓冲的时间量以避免下溢。
示例性实施例以下描述阐述了用于呈现从媒体流获得的媒体的方法和系统的一个或多个示例性实施例，此描述包含所附权利要求书中所陈述的元素。这些实施例带着特殊性描述以满足法定书面描述、授权书、和最佳模式的要求。但是，此描述本身并不试图限制本专利的范围。
媒体流网络拓扑图1和1A示出示例性媒体流网络拓扑100的高层表示，可在其中(部分地或完整地)实现本文中所描述的技术、系统、和其它方面。
示例性拓扑100包括诸如服务器等一个或多个媒体流发送单元110，它经由传输装置130通信地耦合到接收或客户单元120。接收单元120可包括个人计算机(PC)、蜂窝电话或机顶盒等等。在此实施例中，接收单元120还包括显示或呈现设备140，它包括显示屏和一个或多个扬声器。发送单元的功能可由单个组件或多个组件来实现，类似地客户单元的功能可由单个组件或多个组件来实现。
发送单元110可存储诸如文件等各种源以供向接收单元120发送，和/或可经由网络150访问各种源。在各个实施例中，网络150可以是限制访问的网络，或可包括因特网以及其它配置。网络150可耦合到编码器160，对受到发送单元110访问的多媒体数据或内容进行编码和压缩。替换地，发送单元110可在通过传输装置130将媒体发送到客户单元120之前对其进行编码，而客户单元120可在呈现之前将媒体解码。
拓扑100可允许用户用客户单元120选择诸如文件等源进行呈现。客户单元120可请求发送单元110将来自文件的媒体流式传输到客户单元。发送装置130可包括任何适合的传输装置，诸如以太网、宽带、拨号和无线网等。客户单元120可经由呈现设备140向用户呈现媒体。尽管客户单元120和呈现设备140在本文描述为不同的组件，其它实现可将它们的功能集成到单个单元中。
第一示例性方法和实现图2是根据一种呈现从媒体流获得的媒体的方法，表示各个动作的流程图。
动作202请求接收多媒体流。此类请求可以作为客户单元上的选择由用户发起。例如，用户可点击web浏览器中的内容，或可在通过因特网供应商观看电视时切换频道。请求可能仅仅是要对诸如文件等所选源进行流式传输，或可能更具体。例如，请求可能是要将对应于在20秒开始的10秒呈现时间的内容流式传输到所选文件中。请求可使对应于播放请求的文件受到诸如发送单元等访问。
至少部分地通过访问源，可获得与源数据的呈现相关联的咨询数据。咨询数据可包括由原先创建文件的程序存储在该文件的标题中的信息。此程序检查文件以对文件中的任何点决定最大的或推荐的缓冲量。缓冲数据可写到文件的标题中，在那里可由发送单元对其进行访问。
发送单元可仅仅收集咨询数据并将其发送到客户单元。在其它实现中发送单元可在向客户单元发送咨询数据之前处理咨询数据的各个组件，诸如缓冲数据等。在某些例子中，发送单元计算其向客户单元发送的一个或多个估算启动概况。启动概况可涉及客户单元在呈现中的各点应获的数据量。例如，启动概况可包括一组值，该组值指出下溢的最大量、发生下溢的时间、和用于计算下溢的加速速率。在以下所描述的某些实现中，涉及多个加速速率的数据可包含在单个启动概况中。其它实现可为各个加速速率生成分别的启动概况。
在一个实现中，通过在每个呈现时间增加包的大小来计算启动概况，从而确定在文件的呈现期间各个时间的呈现要求。基于各具体加速速率，本方法可计算客户由于在每个呈现时间加速的流式传输而本应收到的数据量的估算值。本方法可在开始呈现之前提供估算缓冲持续时间，以避免客户缓冲发生下溢(用完数据)。
启动概况可包括各种形式。仅举一例，启动概况包括数据数组。数组元素可涉及具体加速速率。例如，对于每个加速速率，该数组包括一个下溢字节值和下溢发生的时间。
在某些实现中，启动概况对给定加速速率涉及两个缓冲条件。第一缓冲条件可涉及开始文件呈现之前推荐或估算缓冲大小。第二缓冲条件可涉及在加速间隔结束处推荐的缓冲大小。这两个条件将在以下具体描述。
第一缓冲条件可用于计算客户单元应开始进行多长时间的缓冲，从而到每次下溢时间为止它至少有足够的字节数以减少和/或避免中断现象。第二缓冲条件涉及计算最差缓冲情形，以确保当客户单元结束加速期时，它对于呈现中的任何点都有足量的缓冲。此最差缓冲情形可能是编码过程所写的标题值，它表示客户应具有的推荐的缓冲量，以避免最差情况或内容最具“动作性”的部分的下溢。此第二计算是基于客户单元在加速间隔期间应仅依赖于增加其缓冲量的前提。在某些实现中，发送设备在咨询数据中发送涉及建议缓冲量的标题值。在其它实现中，发送设备可特意提供建议客户设备在加速间隔结束之前达到的完全缓冲值作为咨询数据的一部分。
在这样一个实现中，本方法判定对于整个呈现来说足够的缓冲数据量，客户单元应在离开加速间隔之前达到此缓冲数据量。当然，在呈现期间，随着客户单元继续接收流式传输的媒体，新的数据被添加到缓冲，但是新数据是以更接近于将数据解码以供呈现的速率的速率被添加的。因此不应指望总缓冲大小显著增加。本方法的此实现在呈现之前计算缓冲持续时间，从而以发送单元打算对媒体进行流式传输的估算加速速率，同时满足这两个缓冲值。
在又一个实现中，发送单元可进行缓冲计算，并仅将客户单元应进行缓冲的时间量的单个值传递给客户单元。替换地，发送单元可将缓冲时间数组传递给客户单元用于不同的加速速率，且客户单元可仅仅挑选最接近其本身测得加速速率的时间，或内插出更准确的值。本领域技术人员应当认识到，这些只不过是哪些组件执行算法的例子。例如，在某些实现中，可由发送单元执行更多或全部的计算。在其它实现中，可由客户单元执行更多或全部的计算。
示例性发送单元算法本节描述在一个实现中发送单元所用的示例性算法的更具体的例子。此算法配置成配合各种客户要求而作用。在一个此类例子中，客户要求加入诸如电视节目等已在运行的广播发布点。在另一个此类例子中，客户要求播放来自可能在网站上被引用的点播发布点的文件。
对于广播发布点的例子，本方法找到作为流式传输到客户单元的媒体的起始点的I帧。以下本算法对要发送到客户单元的数据组(即，从该I帧开始)进行操作。在点播的例子中，计算仅仅在呈现的第一个包处开始。替换地，用户可搜索文件中的任何点。在该情况中，本方法找到某个靠近该搜索点的I帧并开始从该点发送数据。计算从该I帧开始。
在实时编码的内容的情形中，不存在流式传输到客户单元的实际文件。但是，发送单元可缓冲一定量的实时内容，并将数据从该缓冲发送到客户单元。出于启动概况的目的，该缓冲在很多方面逻辑上等效于文件。该缓冲可以环形方式排列，随着新的数据加入，旧的数据从末端被删除。为了要给实时编码的内容提供从发送单元到客户单元的加速，发送单元仅仅以快于实际回放的速度将此缓冲量的一部分发送到客户。
在此特定实现中，发送单元一般执行建立概况的过程，该过程用于在媒体流的特定时期寻找客户单元缓冲需求的峰值。此特定实现通过累计先前的包的大小，来计算每个呈现时间的数据。任何特定呈现时间的数据是所有具有较少呈现时间的包的总和。此值是客户单元为避免下溢所应具有的数据量的度量。
此实现还通过取到该点为止发送到客户单元的字节数，并将其除以发送时间的差，来计算流的平均比特率。此值是本地实际平均比特率，并且可与存储在文件标题中对流的各个部分的平均比特率值不同。此特定实现利用此值，而不是来自文件标题的平均值，因为它可能在文件正受检查的部分上更为准确。
此实现用以上计算所得的平均值计算在每个同样的呈现时间值处要发送到客户单元的流式传输的数据量。此方法可为若干加速速率进行此计算。
此实现可通过为每个加速速率从第一个数(所需数据-流式传输的数据)减去第二个数，来计算每个间隔处的估算过剩的客户缓冲量。只要此数为负，就向客户流式传输多于其需要量的数据，从而它不会发生下溢。但是，如果在呈现中的任何点此值为正，那么在客户单元将存在下溢的条件。
此方法还为每个加速速率跟踪客户缓冲的最大下溢值和最大下溢发生的时间。随着加速速率的改变，客户会有最大缓冲需求的时间点也可能改变。在此类情况中，此方法计算若干加速速率下的下溢值。
这将为每个加速速率生成诸如数据量等下溢值和该下溢值的时间。对于每个加速速率，下溢值往往不同，因为由于变化的加速速率，向客户传送数据的速率也会不同。但是，对于若干加速速率，每次下溢的时间值可能相同，或可能不同。取决于估算数据传送对时间的曲线形状，不同的加速速率可能在不同时间产生下溢。
此实现随后可向客户单元发送这些计算所得的下溢缓冲值和它们发生的时间、用于计算前两者的加速速率和到呈现中的该点的平均比特率。在某些实例中，可将以上所编译咨询数据作为客户单元的启动概况发送给该客户单元，其中启动概况包含发送单元计算所得的估算缓冲持续时间。例如，发送单元可为一个或多个加速速率中的每一个发送所使用的缓冲量，这一个或多个加速速率中的一个可以是发送单元打算流式传输数据的估算加速速率。至少部分基于此缓冲数据，客户单元随后可内插或者用其它方法计算最佳值用于更准确地知道其加速速率，如将在以下具体描述。其它实现甚至可以有更多的发送单元所作的计算。例如，发送单元可监视其向客户单元发送的数据量，并随即向客户发送退出缓冲并开始呈现的信号。
以下提供此类启动概况的一个示例。X-StartupProfile＝Rate＝10，12，15，20，30；MaxBytes＝123424，113482，103245，94030，85125；Time＝520，280，160，120，40；StartTime＝5500；LastTime＝1640；MaxDiffTime＝0；MaxDiffSndTime＝0；ByteRate＝135626，126514，119730，116204，106546动作204接收涉及多媒体流的咨询数据。如上所述，咨询数据可涉及发送单元可使用的且受介入的网络或传输装置支持的一个或多个加速速率下的启动概况，因为网络本身可能是在发送单元和客户单元之间可达到的比特率的限制因素。
以下仅是发送单元和客户单元用来传达各个设备分别支持哪些特征的标题的一个例子。在此特定例子中，发送单元和客户单元可支持以启动概况形式的咨询数据。
Supportedcom.microsoft.wm.startupprofile部分实现可允许客户单元具有某种交互能力或算法能力，以基于咨询数据控制发送单元。例如，客户单元可基于咨询数据选择加速速率和加速间隔，并要求发送单元据此对媒体进行流式传输。在另一个例子中，发送单元可决定加速速率，但可允许客户单元请求加速间隔。如以下将具体描述，在任何加速速率下，客户单元可计算发送单元应加速多长时间，以避免由于加速间隔结束处满的缓冲值而产生的额外启动延迟。因此，一从发送单元收到咨询数据，具体而言是估算的加速速率，客户单元即可计算并请求对应的加速间隔。替换地，客户单元可在其实际收到咨询数据之前计算和请求对应的加速间隔。它可在初始请求接收媒体流期间将此所请求的加速间隔传递给发送单元。
在其它实现中，发送单元作出关于媒体流的决策而不考虑对客户单元的保护。在一个此类实现中，发送单元仅在咨询数据中向客户通知估算加速速率和加速间隔并对媒体进行流式传输。注意在某些网络拓扑中，加速间隔可由发送单元准确控制，从而加速间隔依赖于介入网络的特性以及发送单元发送的速率。
如果咨询数据包含估算加速速率和结果的估算缓冲持续时间，则此方法可前进至动作206。替换地或可选地，客户单元可在前进至动作206之前决定估算的加速速率和/或相关联的估算缓冲持续时间。例如，客户单元可用包对或运行时间包对估算未来的流的加速速率。在另一个例子中，客户经由诸如“？wmbitrate＝xxx”等URL变址来决定估算速率。
计算估算的缓冲持续时间的一个例子可在以下情景中看到。在此实例中，加速间隔是1.0秒，平均呈现速率是1.0Mbps，最差缓冲要求是2.5兆比特数据。估算加速速率是3Mbps。如果回放在流式传输一开始时即发生，则在加速间隔期间可缓冲如2.0兆比特数据，使人相信在呈现之前应缓冲0.5兆比特。但是，因为在回放之前必须有一些缓冲，所以在回放开始以后客户不会经受1整秒的加速，因为部分加速时间将消耗在回放开始之前的缓冲中。在此特定例子中，如果客户缓冲1/2秒，则它将获得3/2＝1.5兆比特数据。随后它播放1/2秒，在此期间发送单元仍在3Mbps下加速，但1Mbps被回放所消耗，因此2Mbps可用于缓冲。因为这继续了1/2秒，所以在回放期间缓冲了1/2×2＝1Mbps数据。这导致在加速间隔结束时缓冲有1.5+1＝2.5兆比特数据，足以避免停顿。应缓冲的2.5兆比特分成两部分1.5兆比特在呈现开始之前缓冲，而1.0兆比特在呈现开始之后缓冲。
动作206开始接收和缓冲多媒体流。媒体流可由客户单元从发送单元接收。缓冲可基于上述的估算的缓冲持续时间被启动。
动作208确定接收多媒体流的测得速率。客户单元本身可测量该速率，或可从第三方组件确定接收速率。本领域技术人员应当知道测量客户单元处收到媒体流的速率的合适方法。
动作210至少部分基于测得速率来计算缓冲媒体流的持续时间。以下此持续时间将被称为测得缓冲持续时间或测得持续时间，以示与上述估算缓冲持续时间的区别，并且并非旨在暗示持续时间是自测的，而是测得缓冲持续时间是用测得加速速率计算的。基于整个多媒体内容文件的最差情况缓冲要求，测得缓冲持续时间可比估算持续时间更加准确，并可允许此方法在减少启动时间的同时减少停顿的可能性。
在此例中，可能客户单元实际并非以估算速率收到流式传输的媒体。结果实际上估算的缓冲持续时间可能太短或比所需的长。因此，此方法逼近估算缓冲持续时间，客户单元利用测得的加速速率来重新计算启动概况计算以查看实际上它是否在测得加速速率下缓冲了足够长的时间以缓冲足够的数据。
如果计算发现客户单元缓冲时间不够长，那么客户单元将进行增量缓冲。例如，当此量是估算缓冲持续时间与测得缓冲持续时间之间差值的一半时，客户单元可选择重新检查缓冲计算。客户可能希望对此差值设诸如100毫秒设定最小界限，以避免在很小的时间间隔内重复进行计算。当此额外缓冲持续时间到达，客户用当前测得加速再次执行启动概况的计算。因为加速可能有某种程度的变化，所以该值目前较高，并且客户可能能够在此点退出缓冲状态是可能的。选择新旧值之间差值的一半作为新的缓冲时间的一个理由，是要使客户单元有机会尽快退出缓冲。
示例性客户算法此特定实现利用如上述由发送单元提供的启动概况的数据组。启动概况数据还包括对发送单元上记录的呈现时间总量的度量，以及如果音频在视频之后发送，还包括音频和视频发送时间之间的最大差值，。音频和视频发送时间在以下具体讨论。
在此特定实例中，每个加速速率的数组的各个元素包括下溢字节值、此次下溢发生的时间、此计算中所用的加速速率、和到该点为止文件的平均比特/字节速率。发送单元的启动概况指示在特定时间客户的缓冲中为避免下溢所应有的预留的额外字节(在平均流式传输速率乘以加速以上)。如上所述，客户单元有两种方法获得那些额外的字节通过初始缓冲和通过流式传输期间的加速。客户单元计算它应进行多长时间的初始缓冲，从而到每个下溢时间T时，它至少具有适当数目的字节来避免下溢。
数据组提供与具体加速有关的下溢值。因此，发送单元告知客户单元因某个时间点T的具体加速值而发生的下溢量。客户单元接收媒体流的测得加速速率恰好匹配发送单元的估算加速是不大可能的。因此，数据组的初始缓冲持续时间可导致客户单元缓冲过多或过少的数据。客户用其本身测得的加速重新计算缓冲量。在此特定实现中，客户单元随后为其达到的测得加速速率下内插其自己的下溢值。
此示例性客户计算如下进行客户估算加速速率或根据来自发送单元的估算来决定估算缓冲持续时间。
一旦客户单元开始接收媒体流并确定其接收媒体流的测得速率，则它可用发送单元的内容平均比特率，利用测得速率来为发送单元传递给它的每个下溢/时间对计算测得缓冲持续时间。
在此实现中，发送单元先前可能在咨询数据中发送了最大加速参数，该参数告知客户它将不会比某个特定量更快地发送数据。客户单元在计算中将此量用作加速参数的上界。知道了测得加速速率，客户单元可计算到其开始呈现之后的任何特定时间为止它将会增长(由于加速)的过剩字节数。
客户单元随即将发送单元传递下来的下溢字节值减去计算所得的字节。如果结果为正，那么客户单元应缓冲足够长的时间来积累该额外数量的字节。客户单元在其计算中用来自发送单元的每个下溢/时间对来跟踪缓冲字节的最大值。在计算中使用该值之前，客户将每个来自发送单元的下溢值内插成其自己的测得加速速率。通过将字节数除以从发送单元传递下来的平均比特率而不是跟踪缓冲字节，客户可在时间空间中一样好地进行计算。使用时间而不是字节对于某些将使用呈现或发送时间(而不是所获字节)作为它们收到多少数据、及何时退出缓冲并开始回放的度量，对某些的客户单元来说可能更为方便。
在一个替换实现中，客户单元仅为传递给它的下溢/时间对中最匹配其测得加速的下溢/时间对计算测得的缓冲持续时间，而不是为所有下溢/时间对进行计算。客户单元还可使用下溢/时间对的某些其它子集，诸如最接近其本身测得的加速的两对等等。
其它因素发送数据块的大小如上面所提及的，流化传输媒体通常包括在时间间隔而不是连续地发送的成组包。按照此过程，部分实现可增加对发送单元带宽变化的估算，这是从发送单元进行的每两次发送之间的间隔。例如，在某些发送单元的配置中，发送单元将以1秒的数据块发送数据。在相对于内容为高速的链路上，如果没有考虑到数据块大小，则以大数据块发送数据可能使客户过早退出缓冲。
此类事件的推理是，在每一个大数据块的发送之后，可能会有一个显著的时期(几乎1秒)中没有从发送单元传来数据。然而，在某些配置中，客户的计算假设数据是以加速的速率线性传来的。如果它从1秒的发送只能勉强获得足够的缓冲数据以满足其缓冲需求，那么它很可能在下一个1秒的发送之前就用完了数据，因为它假设其以平均加速速率线性接收数据。
为避免此问题，发送单元可向客户单元发送对其发送数据块大小的指示，而客户单元将此数量加到其缓冲时间上。在一个此类例子中，发送单元以150毫秒的数据块(1.2兆比特的内容)进行发送。响应于此，客户可对在其启动计算上加150-200毫秒以避免此数据块效应。
音频视频分离在部分实现中，动作204处接收的咨询数据可包含涉及任何对媒体流中对应部分的音频和视频数据的分离的信息。在某些文件格式中，对应的音频和视频数据不能一同被发送。例如，如果在1秒时间上呈现的视频在文件中是1000字节，而同1秒呈现时间的音频在文件中是2000字节，那么客户单元在呈现文件的这个部分之前不得不等待音频。此因素可能比其它快速启动缓冲的考虑更为重要，因为直到客户单元同有了对应的音频和视频两者才开始呈现可能是不合需要的。例如，如果音频比视频晚3秒，则即使其有足够缓冲来开始回放并避免停顿，此方法仍可等待3秒的持续时间。在一个此类实现中，发送单元将此信息作为标题发送给客户单元。一个标题是音频视频的关系，另一个标题是给定加速速率下的启动概况缓冲时间。
在一个此类实现中，发送单元试图通过查看文件中音频和视频包的呈现时间的差值来对音频关于视频的延迟进行定量。
在此特定实现中，每次遇到音频包，此方法就计算上一个视频包和此音频包的呈现时间之间的差值。当此值为正(视频呈现时间大于音频呈现时间)，这意味着对应于此视频样本的音频数据在文件中较远的某个点处——在未来的某点，而客户单元将不得不等待该音频，从而才能将音频与视频同步。此方法可保存在第一步中计算所得的最大值，将其作为音频相对于视频落后多少的最坏情况的度量。此方法随即可向客户单元发送此音频延迟的最大值。
此特定实现可在每次它标识音频样本时重复此计算，它随机可将发送时间中的差值加到计算所得的值上，因为此样本将延迟该数量的时间才被发送，这进一步加重了音频的延迟。
在另一个实现中，一个视频样本覆盖若干个包，而一个音频样本散布在其间。计算可找到在某个给定呈现时间的最后一个视频包，并将其与音频呈现比较。
动作212基于测得缓冲持续时间启动多媒体的呈现。可在减少的时间启动呈现，同时减轻和/或避免呈现期间的停顿。
第二示例性方法和实现图3表示根据一种呈现从媒体流获得的媒体的方法的动作的流程图。
动作302测量在配置成给出多媒体的下游组件处接收多媒体的速率(测得速率)。测量接收多媒体的速率可利用任何合适的装置来完成。在此相对位置测量接收速率可减少诸如由介入事件或情况引起的不一致性，这些不一致性可能会减少试图估算更上游处的速率的准确性。
动作304至少部分利用测得速率来决定在呈现之前缓冲收到的数据的持续时间。仅举一实现为例，此方法基于测得接收速率，在开始回放之前就开始缓冲流式传输的数据并计算持续时间。在缓冲持续时间的计算中利用测得速率可导致启动时间缩短并同时仍能避免呈现的停顿。在开始呈现媒体之前，动作302和304可重复多次以更精确地确定缓冲持续时间。
计算机环境如本文中所述的一个或多个实施例可在许多其它通用或专用计算系统环境或配置中实现。适用的公知计算系统、环境和/或配置的例子包括，但不限于，个人计算机、服务器计算机、瘦客户机、厚客户机、手持式或膝上设备、蜂窝电话、多处理器系统、基于微处理器的系统、机顶盒、可编程消费者电子设备、网络PC、小型计算机、大型计算机、包括上述任何系统或设备的分布式计算环境、等等。
如本文中所述的一个或多个实施例还可在分布式计算环境中实施，其中任务由通过通信网络链接的远程处理设备执行。在分布式计算环境中，程序模块可位于包括记忆存储设备在内的本地和远程计算机存储介质两者之中。
如本文中所述的一个或多个实施例可在由处理器或计算机所执行的诸如程序模块等处理器可执行指令的通用环境中描述。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型和功能的例程、程序、对象、组件、数据结构、等等。通常，在各个实施例中，各程序模块的功能可按需组合或分布。
结论以上所描述的实现允许配置成实际向用户呈现媒体内容的单元作出关于在向用户呈现媒体之前缓冲媒体流的持续时间的最终决定。这样一个配置可减少缓冲持续时间并同时缓解和/或避免呈现期间的停顿。
尽管本发明的概念是以具体到结构化特征和/或方法性动作的语言描述的，应当理解，在所附权利要求书中描述的本发明的概念不必限制于所描述的具体特征或动作。相反，揭示这些具体特征和动作是将其作为实现要求保护的发明概念的示例性形式。
权利要求
1.一种具有处理器可执行指令的计算机可读介质，当由处理器执行所述指令时，执行一种方法，包括测量在被配置成向用户呈现多媒体的下游组件处接收多媒体流的速率(测得速率)；以及至少部分地利用所述测得速率来确定在呈现所收到的多媒体之前对其进行缓冲的持续时间(测得持续时间)。
2.如权利要求1所述的介质，其特征在于，还包括在所述测量之前，接收以一估算的加速速率提供用于呈现的累计缓冲量的咨询数据。
3.如权利要求2所述的介质，其特征在于，还包括至少部分地基于所估算的加速速率和所述累计缓冲量，确定在呈现之前缓冲所收到的多媒体的估算的持续时间。
4.如权利要求1所述的介质，其特征在于，还包括在所述测量之前，接收提供一个或多个加速速率的数据组的咨询数据，且其中，对各个加速速率，所述数据组包含一对应的下溢字节值、呈现中发生所述下溢字节值的时间、以及对所述流中一给定点的平均数据速率。
5.如权利要求4所述的介质，其特征在于，还包括为所述数据组的每个加速速率确定在呈现之前缓冲所收到的多媒体的估算持续时间。
6.如权利要求5所述的介质，其特征在于，确定所述测得持续时间包括在一较高的数据组加速速率和一较低的数据组加速速率之间内插所述测得速率。
7.一种包括如权利要求1所述的介质的计算设备。
8.一种便于快速启动与一来源相关联的新的多媒体流的方法，其特征在于，所述方法包括请求接收多媒体流；接收涉及所述多媒体流的咨询数据；开始接收并缓冲所述多媒体流；确定接收所述多媒体流的速率(测得速率)；至少部分地基于所述测得速率，计算缓冲所述多媒体流的持续时间(测得持续时间)；以及基于所述测得持续时间，启动所述多媒体的呈现。
9.如权利要求8所述的方法，其特征在于，所述接收包括接收咨询数据，所述咨询数据包括对一估算的加速度速率，在开始呈现所述多媒体之前的估算的缓冲持续时间，其中，一上游组件试图以所述估算的加速速率对所述多媒体进行流传输。
10.如权利要求8所述的方法，其特征在于，所述接收包括接收包含加速速率的数据组的咨询数据，且其中，各个加速速率是与用于呈现的累计缓冲量相关联的，且其中，所述数据组还包括一上游组件试图对所述多媒体进行流传输的估算的加速速率，以及所述上游组件试图维持所述估算加速速率的加速间隔。
11.如权利要求10所述的方法，其特征在于，还包括在所述开始动作之前，至少部分地根据所述咨询数据，为所述数据组的加速速率确定在开始呈现多媒体之前的估算的缓冲持续时间。
12.如权利要求8所述的方法，其特征在于，所述接收动作包括接收咨询数据，所述咨询数据包括涉及多个加速速率的启动概况，且其中，所述计算包括在多个加速速率中具有高于所述测得速率的值的第一速率和所述多个加速速率中具有低于所述测得速率的值的第二速率之间内插所述测得速率，以及选择所述测得持续时间以同时满足所述第一和第二加速速率两者。
13.如权利要求8所述的方法，其特征在于，所述计算包括计算第一测得持续时间，以及在达到所述第一测得持续时间之前确定第二后续测得速率并计算第二测得持续时间，并且其中，所述启动是基于所述第二测得持续时间。
14.一种被配置成实现如权利要求8所述的方法的计算设备。
15.一种计算机实现的方法，其特征在于，包括确定在开始呈现多媒体之前缓冲所述多媒体流的持续时间；以及在开始接收所述多媒体流之后，但在开始呈现所述多媒体之前，验证所述持续时间。
16.如权利要求15所述的方法，其特征在于，所述验证动作包括测量接收所述多媒体的速率(测得速率)，并将所述测得速率与接收所述多媒体的估算速率进行比较。
17.如权利要求15所述的方法，其特征在于，所述确定和验证动作是由单个组件完成的。
18.一种系统，其特征在于，包括被配置成发送多媒体的发送单元；以及被配置成接收所述多媒体并向用户呈现所述多媒体的接收单元，其中，所述接收单元还被配置成确定所述接收单元接收所述多媒体的测得速率，并至少部分地基于所述测得速率，计算在开始呈现所述多媒体之前应对所述多媒体进行多长时间的缓冲。
19.如权利要求18所述的系统，其特征在于，所述发送单元包括服务器。
20.如权利要求18所述的系统，其特征在于，所述发送单元被配置成访问已编码的多媒体并向所述接收单元发送所述已编码的多媒体。
21.如权利要求18所述的系统，其特征在于，所述发送单元被配置成在向所述接收单元发送所述已编码多媒体之前对所述多媒体进行编码。
22.如权利要求18所述的系统，其特征在于，所述发送单元被配置成从现场编码会话访问所述多媒体。
23.如权利要求18所述的系统，其特征在于，所述发送单元被配置成从文件访问所述多媒体。
24.如权利要求18所述的系统，其特征在于，所述接收单元包括个人计算机。
25.如权利要求18所述的系统，其特征在于，所述接收单元包括机顶盒。
26.如权利要求18所述的系统，其特征在于，所述接收单元包括蜂窝电话。
27.如权利要求18所述的系统，其特征在于，所述接收单元被配置成对从所述发送单元收到的多媒体进行解码。
28.如权利要求18所述的系统，其特征在于，所述发送单元还被配置成发送关于与所述多媒体的呈现相关联的缓冲值的信息。
29.如权利要求18所述的系统，其特征在于，所述发送单元还被配置成访问包含在文件中的与所述多媒体的呈现相关联的标题信息，并向所述接收单元发送所述信息的汇总。
30.如权利要求29所述的系统，其特征在于，所述汇总包括至少一个数据组，所述数据组包括至少一个加速速率和一个与所述多媒体的呈现相关联的汇总的缓冲值。
31.如权利要求29所述的系统，其特征在于，所述汇总包括至少一个数据组，所述数据组包括加速速率、与所述多媒体的呈现相关联的相关联缓冲值、或呈现中与所述缓冲值相关联的时间中的一个或多个。
32.如权利要求18所述的系统，其特征在于，所述发送单元还被配置成发送其试图发送所述多媒体的估算加速速率，元以及其计划以所述估算加速速率发送的持续时间。
33.如权利要求18所述的系统，其特征在于，还包括一耦合所述发送单元和所述接收单元的传输装置，且其中，所述传输装置可使来自所述发送单元的传输速率高于所述接收单元处的测得速率。
34.一种系统，其特征在于，包括一下游组件，它被配置成接收并缓冲多媒体流，并在缓冲一定数量的多媒体单元之后开始为用户呈现所述多媒体；以及一上游组件，它被配置成访问所述多媒体，并将所述多媒体流传输到所述下游组件，且其中，所述上游组件还被配置成在所述呈现中的一个或多个点处获得至少一个涉及推荐缓冲量的启动概况，以缓解下溢情况。
35.如权利要求34所述的系统，其特征在于，所述至少一个启动概况包括涉及所述多媒体流的可能流传输速率的多个启动概况。
36.如权利要求34所述的系统，其特征在于，所述上游组件编译所述至少一个启动概况。
37.如权利要求34所述的系统，其特征在于，所述上游组件至少部分地基于所述至少一个启动概况，计算缓冲所述单元数量的估算缓冲时间。
38.如权利要求34所述的系统，其特征在于，所述上游组件至少部分地基于所述至少一个启动概况，计算缓冲所述单元数量的估算缓冲时间，且其中，所述上游组件将所述估算缓冲时间传递给所述下游组件，所述下游组件根据所述估算缓冲时间进行缓冲，而不再另外计算或验证所述估算缓冲时间。
39.如权利要求34所述的系统，其特征在于，所述上游组件至少部分地基于所述至少一个启动概况，计算缓冲所述单元数量的估算缓冲时间，且其中，所述上游组件将所述估算缓冲时间传递给所述下游组件，所述下游组件根据所述估算的缓冲时间进行缓冲，并且在开始所述呈现之前，所述下游组件验证所述估算的缓冲时间。
40.如权利要求34所述的系统，其特征在于，所述下游组件至少部分地基于所述至少一个启动概况，计算缓冲所述单元数量的估算缓冲时间。
41.如权利要求40所述的系统，其特征在于，所述下游组件被配置成通过至少部分地基于所述下游组件接收所述多媒体流的测得速率计算缓冲所述单元数量的第二缓冲时间，来验证所述估算缓冲时间。
42.如权利要求41所述的系统，其特征在于，所述下游组件被配置成由于所述多媒体流的属性，而将开始所述呈现延迟到超过所述第二缓冲时间。
43.如权利要求42所述的系统，其特征在于，所述属性包括发送字节块大小或音频/视频分离中的一个或多个。
全文摘要
如本文中所述的一种实现，便于快速启动新的媒体流，同时缓解、并在某些实现中避免在呈现该新的媒体流中有暂时性的中断(即，“结巴”)。本文中所描述的至少一个实现测量在配置成向用户呈现多媒体的下游组件处收到多媒体流的速率；并至少部分地利用测得速率来确保，在呈现所收到的多媒体之前对其进行一定持续长度的时间的缓冲。
文档编号H04N7/64GK1753503SQ20051010641
公开日2006年3月29日 申请日期2005年9月23日 优先权日2004年9月24日
发明者A·E·克莱梅特斯, J·C·斯图尔特, 章葛强 申请人:微软公司