CN101129041A - 使两个实时传输协议多媒体流会话之间的切换延迟最小化的系统和方法 - Google Patents

Abstract

通信系统包括与多媒体服务器(MS)相互通信的多媒体播放器(MP)群组，根据IETF RTSP协议运行的播放器和服务器都与所用的传输网络无关。称为流切换处理器(SSP)的新的网络元件位于播放器和视频服务器/视频编码器(ME)之间，用以根据从多媒体播放器(MP)接收到的指令(通知)来执行内容流的切换。另外的办法是，SSP也含有视频服务器和视频编码器的功能度。SSP至少包括M个缓冲器(频道－1，…，频道－M)，以便始终保持有相同数量的独立的内容流。这个体系结构使得SSP在处理消息流时能够同时向播放器传送切换了的内容流。其结果是，在第一RTSP会话的情况下，播放器接收新的内容流。在照此方式操作时，由于某些典型的延迟彼此重叠，因而明显地减少了切换延迟时间(SDT)，而其它的延迟是与SDT在相同时期中发生的。能够从编码的实时信号(如卫星TV频道)或取自档案的注册内容中派生出多媒体内容。对播放器进行编程，以便从它的接收缓冲器中清除视频/音频MPEG－4帧，并用时钟更快的相关辅助缓冲器的帧来装填清空了的空间。调整发送关键帧的进一步的办法防止了在所显示的图像上的假象，在此，紧跟在关键帧后面的是“安全的”填充长度。由播放器在UDP或TCP上发送切换消息；该消息至少包括请求频道的标识符和播放器内的缓冲器状态。另外的办法是，创建新的RTSP消息，其中包括根据RTSP表示规则描述的信息字段。

Description

使两个实时传输协议多媒体流会话之间的切换延迟最小化的系统和方法

技术领域

本发明涉及通过IP网络来传送/享用多媒体内容的领域，更具体地说，涉及最大限度地减少在两个RTP(实时传输协议)多媒体流会话之间的切换延迟的系统和方法。在典型的多媒体流平台的情况下，例如，在3GPP环境下对移动网络有效的著名IMS，或者是在其它的地面的(PSTN)或无线的(WLAN，Wi-MAX等)固定的网络平台的情况下，相对于涉及RTSP/RTP/RTCP协议的那些部件来说，本发明完全符合3GPP和IETF标准。在附录C中列出了所用的缩略语，在附录D中给出了参考文献资料。

背景技术

图1示出了通过IP来传送、点播多媒体流内容的系统体系结构，例如，预编码内容、直播内容、模拟直播内容。该体系结构极为普通，以致能够根据RTSP/RTP/RTCP IETF协议来实现大多数的已知的实施方案，而与用户和IP供应商之间所用的传输网络无关。在附录D的参考文献资料是RTSP的[RFC2326]和RTP/RTCP的[RFC3550]。

参照图1，我们看到N个多媒体播放器MP，它们分别与多媒体服务器MS相连，并包括供注册了的影片或类似媒体(预编码内容)用的内容资料库，并进而与多媒体编码器ME连接，以便提供如像卫星电视频道之类的直播多媒体内容。传输网络可以是：无线的、有线的、光纤的、三种类型混合的，或者是符合IP网络级别的其它种类的传输网络。在体系结构上，对于不同连接可以有不同传输网络。无线型的例子是3G UMTS(通用移动电信系统)网络，并且其播放器是电话手机，或者是点对多点的MAN(城域网)，并且其播放器是终端设备(客户机)。有线型的例子是与互联网提供商相连接的PSTN，并由用户通过常规的调制解器或ADSL来存取。根据用户的意见，光纤正在逐渐取代铜绞合线，从而使多媒体流具有宽带的优点。

在具有多媒体服务器的情况下，在操作时，想要得到多媒体文件的用户要用IP网络来建立RTSP会话，以便在RTPC控制下享用RTP内容。根据[RFC2326]，RTSP建立并控制连续媒体(例如音频或视频数据)的单个或多个的时间同步流。由表示描述(presentation description)来限定要控制的流集。可以由RTSP URL来鉴定每个表示和媒体流。没有RTSP连接的想法；然而，服务器保留了用标识符标志的会话。RTSP会话决不连接到如像TCP[RFC0793]之类的传输级连接之上。在RTSP通话期间，RTSP客户机可以接通并关断对服务器的许多可靠的连接，以便发送RTSP请求。另外的办法是，可以使用如像UDP[RFC0768]之类的无连接的传输协议。由RTSP控制的流可以使用RTP，但是，RTSP的操作并不依靠用于携带连续媒体的传输机制。

图2示出了与在媒体播放器和媒体服务器之间的多媒体流服务会话相关的、典型的RTSP消息顺序图。对于由播放器发送的每个RTSP消息，有一个来自媒体服务器的响应。参照图2，示出了下列的RTSP方法：SETUP(设置)、PLAY(播放)、DESCRIBE(描述)和TEARDOWN(撤销)。下面将对这些方法和其它有用的方法(即PAUSE、OPTIONS，ANNOUNCE，RECORD，REDIRECT，SET_PARAMETER)一起进行简明地说明。

*DESCRIBE(描述)：检索用来自服务器的请求URL鉴别的表示或媒体对象的低级描述。可以用“接受头标”来规定客户机了解的描述格式。服务器用被请求资源的描述来加以响应。可以用会话描述协议(SDP)[RFC2327]来描述在RTSP中的流或表示。DESCRIBE(描述)答复-响应对构成了RTSP的媒体初始阶段。DESCRIBE(描述)响应必须包含它所描述的资源的所有的媒体初始化信息。媒体初始化是基于RTSP的任何系统所需要的，但是，RTSP规格并没有强行规定必须通过DESCRIBE(描述)方法来做到这一点。RTSP客户机可以通过三个方法来接收初始化信息：a)通过RTSP的DESCRIBE(描述)方法；b)通过其它的一些协议(HTTP，E-mail附件等)；c)通过命令行或标准输入。如果媒体客户机从一个数据源而不是从DESCRIBE(描述)获得了一个表示描述，并且此描述包含一整套媒体初始化参数，该客户机就应当使用这些参数，随后不再通过RTSP请求相同媒体的描述。

*SETUP(设置)：服务器为流分配资源并起动RTSP会话。客户机能够为已经活动起来的流发出SETUP(设置)请求，以改变服务器允许的传输参数。传输头标规定了客户机可以接收的传送参数，以便传输数据；响应包含由服务器选择的传输参数。

*PLAY(播放)：通过在SETUP(设置)中规定的机制告诉服务器开始发送数据。在认可任何未完成的SETUP(设置)请求是成功的之前，客户机决不能发出PLAY(播放)请求。PLAY请求将标准播放时间放在规定范围的开始，并传送流直到达到范围的终端为止。

*TEARDOWN(撤销)：停止传送指定的URI(统一资源标识符)的流，解放与其相关的资源。如果URI是该表示的表示URI，与此会话相关的任何RTSP会话标识符不再有效。除非所有的传送参数都由会话描述来定义，在能够再次起用会话之前，必须发送SETUP请求。

其它的方法是：

*PAUSE(暂停)：该方法暂时中断(停止)流的传送。如果请求URL是一个流，就只停止该流的回放和记录。例如，对音频数据而言，这就相当于静音。如果请求URL是一个表示或一组流，就停止在表示或组中的当前活动的所有的流的传送。在恢复回放或记录之后，必须保持轨道(tracks)的同步。在SETUP消息中，由会话头标的超时参数所规定的时期内，尽管服务器在被暂停之后可以关闭会话并释放资源，但仍要保留任何服务器资源。

*OPTION(选择)：得到可以利用的方法。如果客户机想要尝试一个非标准的请求，就可以在任何时间发出OPTIONS(选择)请求。这并不影响服务器的状态。

*ANNOUNCE(宣告)：这个方法服务于两个目的：在从客户机向服务器发送时，ANNOUNCE(宣告)将由请求URL鉴定的表示或媒体对象的描述传递给服务器，在从服务器向客户机发送时，ANNOUNCE(宣告)实时更新会话描述。

*RECORD(记录)：根据表示描述开始记录一系列的媒体数据。时间戳反映了开始时间和结束时间(UTC)。如果没有指定时间范围，就使用在表示描述中提供的开始时间和结束时间。如果会话已经开通，立即开始记录。

*REDIRECT(改向)：通知客户机必须连接到另一个服务器位置上。它包括强制性的头标定位，该头标定位表明客户机应当发出对URL的请求。它可以包括表明改向何时生效的参数范围。如果客户机想要继续为URI发送或接收媒体，那么，客户机就必须为当前会话发送TEARDOWN(撤销)请求，并在指定的主机上为新会话发送SETUP(设置)请求。

*SET_PARAMETER(设置参数)：请求为由URI规定的表示或流设置参数值。

发明内容

技术问题概况

与图1的体系结构相似的所有的系统体系结构的缺点是它们有过多的延迟，这个延迟是发生在享用内容流的用户按压键钮以便切换到新的内容流上和新内容在播放器的屏幕上可视化的瞬间之间。在表1中将这个延迟称为SDT。根据上面的RTSP方法的分析能够证明，这个延迟实质上是由于RTSP而产生的，这是因为只能在封闭RTSP会话之后立即开启指向新的RTP/PTCP流的RTSP会话才能实现内容流的切换。开启RTSP会话包括在多媒体播放器和各个服务器之间的几个协议步骤，通常，要通过一个插入的服务器代理系统(server Proxy)来实现。更详细地说，为了制订切换请求，用户将得到新媒体流的RTSP URL。在接收认证之前，将要认证用户的请求，以便答应此项服务。随后，在播放器和服务器之间的SDP协商步骤是设立物理层的普遍规则。此外，播放器将把与其操作状态和它的内部缓冲器的状态相关的某些信息发送给服务器。所有上述的步骤都需要时间。同样地，关闭活动会话也需要时间来重新设置连接和所分配的资源的状态。

表1和表2详细介绍了与实时多媒体内容的产生和在它们之间的切换相关的各种延迟。表1报告了集中在SDT延迟中的所有延迟的描述。表2报告了集中在RPT延迟中的所有延迟的描述，RPT延迟大于SDT，它相当于在编码器输入上的实时事件和该实时事件在播放器屏幕上可视化之间的延迟。根据这两个表，能够察觉到大量的顺序延迟，它们集中在前工艺的切换工序中。

延迟SDT随着图1的传输网络的减缓而增大。由于它们的复杂性，大的延迟成为以移动/无线网络为基础的传输网络的特征；在这样的情况下，根据最乐观的估计，SDT延迟大约为10秒。对于那些倾向于接收3秒以下的延迟的网络操作员而言，这个值被认为是过高的。存在这样的情况，尤其是在实时事件的情况下，客户将低的切换延迟时间认作为是选择解决方案的关键问题。考虑到操作人员对提供有价值的流服务的兴趣日益增长以及相关业务的并行发展，这方面的技术解决方案对倡议者是非常有利的。外部公司(多媒体平台制造商)继续进行研究，以便最大限度地减少由于在RTSP会话关闭/打开期间所引起的延迟，但是，遗憾的是，在专利申请者的资料中至今尚未有令人满意的提案。在[RFC2326]的第9.1段的RTSP中说道：“支持持久连接或无连接模式的客户机”可以“流水线式地发送(pipeline)”它的请求(即发送多个请求而不用等待每个响应)。服务器必须按照与接收请求相同的顺序发送它对那些请求的响应。”不再讨论对于这类请求和响应的可能的指示以及相关的实际应用。在申请人的意见中，如何加速在实时情况下的切换时间的问题，这就是说，要想迅速改变在其播放器屏幕上看见的、正在播放中的音频-视频频道的UMTS用户，仍然不能根据RTSP提议来解决问题。在预先知道请求的类型和顺序的情况下，流水线式地发送请求可能是有用的，在这样的情况下，服务器可以利用请求的等待时间来处理随后的一个，但是，这种情况是否得到验证，流水线式地发送方式是没有用的。在事先知道用户请求的类型和顺序的精确组合的情况下，可能的方案是能够同时享用多媒体流，但是，这既不符合当前市场上的用户终端的能力，也不符合由IP供应商提供的服务器的类型(如果是UMTS传输网络，就符合网络操作员的要求)。

与在两个多媒体内容之间快速切换相关的另一个问题是，在用新的帧来替换以前的帧的过渡过程中如何管理音频-视频表示。在某些实际情况下，需要极大的压缩比，这就是说，在UMTS手机的屏幕上直接接收卫星电视频道。在这样的情况下，MPEG-4(或者在任何普通的3GPP编码译码器中)允许使用差分编码/译码技术将数字信号从初始宽带压缩为适合于传输网络的带宽(UMTS通常支持384、128、64kbps)。在传输信号流时，这在技术上大大强化了缓冲器的使用。考虑到多媒体内容从视频服务器到用户的单向传输，在用户终端上总是包括接收缓冲器，与此同时，在视频服务器中为每个发送的流配备了传输缓冲器。缓冲操作允许恢复系统在实时表示中的系统时延和在传输和接收时钟之间的可能的差异。在视频信号的不同的编码的情况下，MPEG-4(或3GPP)流包括被合适地放置在彼此之间并在任何情况下被解码器用于获得整帧的所谓关键帧(3GPPI帧)。从关键帧开始，解码器从仅被编码的差异获得连续的帧，以便播放器内部的接收缓冲器将至少容纳两个关键帧之间的所有帧在其中。与缓冲器长度成比例的是播放器缓冲PB(见表1)，其被耗费用于从接收缓冲器中清空实际帧，并用新频道的帧来填补它。无论是否有机会被最小化，PB延迟对应于整个缓冲器长度。在过渡时期中，无论是否提供其它，由于差分编码导致用户接收一些假象。

本发明的目的

本发明的主要目的是为了指示减少通过IP网络以及特别地通过运行RTSP/RTP/RTCP协议的多媒体服务器所提供的多媒体内容之间的切换时间(尤其是SDT时间)的方法。使得用户能够响应通过按压其终端上的按钮或某些等同动作所执行的明显请求来接收服务，无论由服务器从所存储的内容中或直接从实时接收的信号(现场内容)中直接解码并重新编码来取得所传输的流。在时间上绝对随机地、且在所订阅的内容池中随机地引发请求，在这种意义上，用户不会被束缚于用于减少切换时间的特殊策略。

本发明的另一个目的是为了指示对于播放器如何以无缝模式在多媒体内容之间执行快速切换。

发明的概述和优点

如权利要求1所披露的，本发明通过提供一种用于响应由播放器发送的切换请求消息、在基于用于根据RTP/RTCP协议向播放器终端传送实时多媒体内容的RTSP因特网协议的流会话之间进行切换的方法来实现所述目的。

根据本发明的方法，进行第一RTSP会话的用于欣赏第一多媒体流内容的播放器通过向多媒体RTSP服务器发送切换请求消息来激发对所接收的流内容的改变；后者当处理该切换消息时，切换到在一直被播放的M个多媒体独立的内容中选择的新的流内容，并并行地传送所切换的流内容到播放器。处理来自RTSP服务器的切换消息被视为读取切换消息的信息内容，使用它来关闭第一RTSP会话，并开启第二RTSP会话。在播放器和系统之间交换M个可能的内容的列表，且该列表被周期地或基于请求和/或通知而保持更新。如上所述的切换的结果是，播放器接收以第一RTSP会话的文本的新的流内容。以这种方式操作使得切换时延SDT被显著地减少，因为某些典型的时延被重叠，且其它时延与SDT同时。多媒体内容被编码成实时信号，诸如卫星TV频道，或从档案中取得的注册内容。

有利地，M个多媒体内容填补服务器端的各个辅助缓冲器。如果播放器被编程为快速地从其接收缓冲器清出视频/音频MPEG-4帧，并更快地用相关辅助缓冲器的帧来填补空出的空间，这允许最小化SDT延时。进一步方便对调整其后跟随了“安全”填补长度的关键帧的相对应的发送防止了在显示图像上的假象。

根据三种不同的实施例即：“双切换”、“单切换”和“仅在辅助流之间的单切换”，本方法是可执行的。在“双切换”中实施例中，在服务器接收到切换请求消息之后通过用于发送所切换的内容的辅助假想部分来立即切换到第二RTSP会话。在“单切换”实施例中，进行第一RTSP会话的服务器在接收到切换请求消息之后立即切换到用于发送所切换的内容的辅助假想部分，并在不关闭第一会话并开启第二会话的情况下保持在辅助部分中。第三个实施例不同于第二个，仅由于如下事实，服务器切换到从用于发送第一流内容的辅助部分开始的第二流内容。

如独立系统权利要求所披露的，本发明的另一目的是根据本发明的方法的通信系统。

本发明的系统不考虑所使用的传输网络，使一个或多个播放器与RTSP服务器进行通信。可以预见至少两个等同的实施例，这两者包括用于响应从播放器接收的命令来执行切换的流切换处理器。该处理器包括至少M个缓冲器，用于等同数量的独立流内容。根据第一个实施例，流切换处理器位于播放器和视频-服务器/视频编码器之间。根据第二个实施例，该流切换处理器还实现了视频服务器和视频编码器的功能。

附图说明

被认为具有新颖性的本发明的特征在所附权利要求中被特别指出。可以参考以下一些实施例的具体描述以及纯粹为了无限制的示例目的所给出的附图，来理解本发明及其优点，其中：

图1，已经描述的，示出根据现有技术的用于经由IP发送多媒体内容的典型系统架构；

图2，已经描述的，示出在图1的系统中建立的多媒体流服务会话相关的典型RTSP消息序列流程图；

图3a、3b和3c示出根据本发明的用于经由IP发送多媒体内容的一些架构；

图4示出在图3a、3b和3c的架构中可见的SSP(流切换处理器)块的组成部分；

图5示出在图4的SSP块中可见的辅助增强缓冲器块的组成部分；

图6示出在图5中可见的现场内容缓冲器块的组成部分；

图7示出在图4的SSP块中可见的流切换处理器核心的组成部分；

图8到10指示用于在多媒体流之间切换的一些可替换的方式；

图11到14显现通过图3a、3b和3c的架构进行用于从当前多媒体会话切换到另一多媒体会话的操作步骤的序列；

图15到19显现根据图11到13显现的操作步骤的序列、在多媒体内容切换期间、分别位于播放器和SSP块中的两个缓冲器的动态状态；

图20提供由图3a、3b和3c的架构所实现的多媒体流切换方法的各个步骤所花费时间的可视支持。

具体实施方式

参考图3a，我们看到不同于图1系统的系统结构，其包括称为流切换处理器(SSP)的新网络元件，它放在多媒体服务器MS和N个多媒体播放器MP的群组之间。SSP元件通过传输网络与用户播放器相连，该传输网络提供SSP和每个播放器之间的单独连接。一旦连接起来以后，RTSP/RTPC协议就开始运行并由每个播放器将NOTIFY(通知)消息传送给SSP。SSP元件通过其它的RTSP/RTP/RTPC连接依次与多媒体服务器相连，并通过单独的RTP/RTPC连接与M个多媒体编码器中的每一个相连。适当地研究了在多媒体编码器ME的输出上的RTP/RTPC流的复制，以便提供现行的多媒体服务器(视频服务器)MS，它与系统中引入SSP元件兼容。可通过多点传送来进行复制。如像下面将要详细讨论的那样，根据客户机的请求并通过最大限度地减少内容流切换的延迟时间，SSP元件为多媒体系统提供“快速内容切换”功能。在图3b中，列出了以前结构的变型，其中，多媒体服务器MS也包括多媒体编码器ME。如图3c所示，能够进一步地简化体系结构，在此，单个的网络元件起着多媒体编码器、多媒体服务器和SSP处理器的作用。在详细说明了图4到图7中的SSP元件之后，将要说明相关的操作。

图4简略地示出了SSP元件的内部结构。参照此图，将SSP再划分成如下几个主要的逻辑部分：切换事件接听器SWEL、多媒体会话管理器MSM、RTSP处理器RTSPP、流切换处理器芯SSPC、高级辅助缓冲器(RTP/RTCP)AAB。为了简化起见，在图中未示出RTSP处理器的总线和这些块的连接。在方案设计上，不管是否需要发现K-帧，高级辅助缓冲器(RTP/RTCP)AAB都不是非有不可的。相关的外部连接是：

·来自N个播放器的NOTIFY(通知)消息到达切换事件接听器SWEL；

·发送到/来自N个播放器的RTSP消息占用播放器一方的RTSP处理器RTSPP的N个端口；

·发送到/来自M个多媒体编码器的RTSP消息占用PTSP处理器RTSPP的M个端口；

·将在流切换处理器芯SSPC的输出上的RTP/RTCP流引导到N个播放器上；

·将在M个多媒体编码器的输出上的RTP/RTCP流引导到高级辅助缓冲器AAB上。

图5示意性地示出了图4的高级辅助缓冲器AAB的内部结构。参照此图，所示出的块包括：

·视频点播临时缓冲器PCB，用于存储从内容资料库中提取的预注册的多媒体内容(图3a)，并将其发送给提出请求的播放器；

·供已编码的实时流用的、数量为M个的直播内容缓冲器LCB；

图6示意性地示出了图5的直播内容缓冲器LCB的内部结构。参照此图，所示出的块包括：

·RTP/RTCP缓冲器处理器；

·RTP视频缓冲器；

·RTP音频缓冲器；

·RTCP视频缓冲器；

·RTCP音频缓冲器；

图7示意性地示出了图4的流切换处理器芯SSPC的内部结构。参照此图，所示出的块包括：

·客户会话中心；

·RTP/RTCP音频/视频同步器；

·视频关键帧扫描器；

·缓冲器变址管理程序；

·RTP流程处理器；

·RTCP流程处理器；

相对于在SSP处理器的操作中的三个变型，现在讨论前面各图中示出的系统的操作。参照图4，SSP处理器根据辅助的RTP/RTCP缓冲器的理念来工作。一个缓冲器相当于一个多媒体内容，并可用来将分组传送给几个客户机。多媒体体内容受相同的编码规则和格式(即MPEG-4)的支配。所有的与多媒体内容相关的RTP/RTCP分组都事先缓存于特定的高级辅助缓冲器AAB中，以便将其传送到播放器MP上。根据引导到切换事件接听器SWEL上的客户机的切换请求来进行传送，SWEL为流切换处理器芯SSPC提供要切换的新的多媒体流的指示。SSPC命令高级辅助缓冲器AAB从M个缓冲器中选择所想要的一个，在多媒体服务器MS上完成多媒体会话的(可能的)关闭和重新接通之前，M个缓冲器将它的内容传送到提出请求的播放器MP中，以便按此方式减少SDT延迟。在直播(或模拟直播)多媒体流内容的情况下，多媒体服务器/多媒体编码器连续向辅助缓冲器馈给。在静止内容的情况下，根据客户机的请求对视频点播临时缓冲器(图5)进行馈给。在处理RTP/RTCP之后，SSPC从缓冲器的点上开始向播放器(RTSP客户机)传送分组，该缓冲器最佳化(也就是最小化)在同一时期内的(contemporary)延迟时间，并(最大限度地利用)用户的经验：事实上，选择第一个可以利用的视频K-帧(和相应的音频部分)以作为切换后要发送的内容的第一部分，从而向用户提供最好的视频感受(切换时的非艺术作品)。

相应于本发明的实施例的同等数量，图8、9和10简略地示出SSP处理器的下列三种可供选用的操作形式：即“双切换”(图8)、“单切换”(图9)和“仅在辅助流之间的单切换”(图10)。参见图8，在“双切换”实施例中，正在观看与第一多媒体会话相关的第一频道的播放器切换到与第二多媒体会话相关的第二频道上，被当作到SSP元件中的辅助第二频道的中间切换。要说明的是，辅助的和次级的会话代表相同的“频道”(即两者都向用户传送MTV)。向辅助的第二频道的中间切换相应于总是接通的辅助的多媒体会话。参照图9，在“单切换”的实施例中，正在观看与第一多媒体会话相关的第一频道的播放器切换到相应于总是接通的辅助多媒体会话的辅助第二频道并停留下来。参照图10，在“仅在辅助流之间进行的单切换”中，正在观看与第一辅助频道的播放器切换到总是接通的第二辅助频道上并停留下来。从第一实施例(图8)开始，更为详细地说明了这三个实施例，在图11到图14的支持下说明了第一实施例的操作步骤。

图11示出了对“双切换”(图8)或“单切换”(图9)的实施例都有效的起始条件。参照图11，图中示出了在SSP处理器中的M+1个缓冲器，在视频服务器内的M+1个缓冲器，在播放器中的单独的缓冲器。用M个频道的内容流来装填M个缓冲器，与此同时，用频道1的内容来装填其余的缓冲器。在系统中进行的、用以得到图12的结果的操作步骤如下：

1.SSP感受来自播放器(RTSP客户机)的第一多媒体RTSP会话的请求。

2.SSP向视频服务器传送第一RTSP请求。

3.SSP向播放器传送来自SSP上的辅助缓冲器的频道1的RTP/RTCP分组，并在必要时处理它们，此播放器接收频道1的内容。

4.SSP接收“NOTIFY(通知)”消息，以便从频道1切换到频道2内容。

5.SSP使用来自辅助缓冲器的分组向播放器发送频道2的内容。这相当于向频道2的第一个切换，与此同时，播放器接收新的内容。

6.SSP在同一时期内执行用以关闭在服务器上的以前的多媒体会话所需要的所有动作，与此同时，客户机继续接收频道2的内容。

为了得到图13的情况而在系统中进行的操作步骤如下：

7.SSP执行用以开启在服务器上的新的多媒体会话所需要的所有动作(认证、装载等)，与此同时，客户机继续接收频道2的内容。

为了得到图14的情况而在系统中进行的操作步骤如下：

8.在视频服务器上完成新的多媒体会话，SSP使用来自服务器上的新的多媒体会话的分组向播放器发送频道2的内容。这相当于向频道2的第二个切换，与此同时，播放器继续接收频道2的内容。

如上所述，尽管已提出了一个最佳设计方案，但是，辅助缓冲器的使用并不是强制性的，不管是否需要发现K-帧，都要使传输和接收时钟完全同步。在这样的情况下，使用SSP处理器中的多路复用器来选择要向播放器传送的频道，该多路复用器是由数字代码控制的，并用由含于“NOTIFY(通知)”消息中的、在切换了的频道(频道2)上的指示派生出的数字代码来控制。

从图11所示的初始条件开始，在与“单切换”实施例(图9)相应的系统中进行的操作步骤如下：

1.SSP感受第一多媒体RTSP的会话的要求。

2.SSP向视频服务器传送第一个RTSP请求。

3.SSP向客户机传送来自SSP上的辅助缓冲器的频道1上的RTP/RTCP分组(在必要时处理它们)，并且，播放器接收频道1的内容。

4.SSP接收“NOTIFY(通知)”消息，以便从频道1切换到频道2内容。

5.SSP使用来自辅助缓冲器的分组向播放器发送频道2的内容。这相当于向频道2的切换，并且，播放器接收新的内容。

6.SSP在同一时间内执行用以关闭在服务器上的、以前的多媒体会话所需要的所有动作，与此同时，客户机继续接收频道2的内容。

7.SSP执行为开启在服务器上的新的多媒体会话所需要的所有动作(认证、装载等)，与此同时，客户机继续接收频道2的内容。

8.SSP使用来自辅助缓冲器的分组继续向播放器发送频道2的内容(不需要二次切换)，客户机继续接收频道2的内容。

从不同于图11所示的初始条件开始，根据用辅助频道1的内容来装填播放器中的接收缓冲器的这个事实，在与“仅在辅助流之间单切换”的实施例(图10)相应的系统中进行的操作步骤与图9的“单切换”实施例所描述的步骤具有相同顺序。

由SSP处理以便切换频道的NOTIFY(通知)消息是由播放器产生的，并在UDP或TCP上发送该消息。NOTIFY(通知)消息至少包括：

·提出请求的播放器的IP地址；

·在播放器上运行的现行频道的标识符；

·所请求的频道的标识符；

·切换命令；

·在播放器中的缓冲器状况；

·由播放器接收的最后的分组的顺序号，等等。

替代NOTIFY(通知)消息的一个办法是包含来自播放器的请求，以便直接切换在RTSP信令中的现行频道。在此情况下，根据RTSP表示规则来制作新的RTSP消息，在此消息中包括适时说明的上述信息字段。在RTSP协议中接纳了这个机会。

图15到图19说明了预先使用RTP/RTCP视频/音频辅助缓冲器的程序的步骤。根据本发明的与图8到图10相关的三个实施例，在完成第一切换时，在每个图中比较与现行频道(频道1)相关的播放器内的缓冲器的状态以及与切换了的频道(频道2)相关的SSP内的辅助缓冲器的状态。为了完整起见，图15示出了在停止服务时的缓冲器的空状态。

图16示出了在播放器观看频道1时两个缓冲器的状态。参照图16，应当注意到的是，播放器缓冲器几乎被完全装满，超出了开始播放的限度，并且还包括三个关键帧。在图的右边示出了在播放器屏幕上可以看到的频道1的图像。与频道2相关的辅助缓冲器是装满了的，并且至少包括两个相隔10秒的关键帧。用SSP处理器来使辅助缓冲器1到M总是保持在完全装满的状态；这个策略允许在现行播放的频道和剩余的M-1个多媒体内容之间进行快速的、绝对随机的切换。

图17示出了在用户决定要切换内容时的两个缓冲器的状态。参见图17，应当注意的是，已清洗了存储在播放器缓冲器中的视频帧，这些视频帧超出了被称为是“再缓冲限度”的最小值(7帧)。清洗视频帧尽管不是强制性的，但有助于最大限度地减少总的切换延迟时间。如果正确地限定了播放器缓冲器的大小(小于3秒)，快速切换就变成可能的事情而不用清洗播放器缓冲器。装填满了的频道2的辅助缓冲器肯定包含一个关键帧，其后紧接着大于“再缓冲限度”的帧的最小“安全”数(a，......h)。在用户决定切换内容时，播放器清洗它的接收缓冲器(音频/视频)，直到达到最小数为止，然后使用上面列出的机会向SSP发送NOTIFY(通知)消息。为了进一步减少切换延迟，可以用UDP协议来发送NOTIFY(通知)消息，以避免TCP信号交换。频道1是播放器屏幕上的静止背景，但是，显示礼节性的消息则是可以任选的。

参照图18，SSP接收NOTIFY(通知)消息，并从关键帧(a)开始，将来自频道2的辅助缓冲器的输出内容传送到提出请求的播放器中。为了快速装载播放器缓冲器，将SSP缓存分组传送到播放器缓冲器中的速度大于编码速度。频道1是在播放器屏幕上的静止背景并显示礼节性的消息。参照图19，根据播放器的最小“安全”延迟来完成向频道2的切换，并在屏幕上显示频道2。对于上面所考虑的全部实施例而言，这个行为是相同的。

借助于图20以及附录B的表3和表4的帮助来进行延迟分析，在此，该延迟分析与图11到图14所示的流切换方法的操作步骤相关。参照图20和表3能够看出，在此提出的发明确实最大限度地减少了切换延迟时间SDT。事实上，某些延迟(用“*”标志)对SDT并没有任何影响，对PBT(PBT＞SRT+PWT)而言，其它的延迟(用“*”标志)是同时期发生的。

附录A

表1    切换延迟时间(SDT)分析

SDT＝在用户按压键钮和在播放器屏幕上看见新的流之间的时间
	SRT＝切换请求时间(从播放器到APP/代理服务器)
APT＝认证处理时间(包括产生URL)
	RRT＝第二直播流程开始的RTSP再连接时间
GOPT＝图像时间群(为了得到关键帧)
	PWT＝代理服务器工作时间
PBT＝播放器缓冲时间
	SDT＝SRT+APT+RRT+GOPT+PWT+PBT

表2播放时间(RPT)的实时分析
	RPT＝实时事件和在播放器屏幕上事件的可视化之间的延迟
ET＝编码时间
	ESD＝服务器传送时间编码器
SB＝服务器缓冲
	SPD＝从服务器到代理服务器的传递时间
PB＝代理服务器缓冲
	PHD＝从代理服务器到手机的传递时间
PBT＝播放器缓冲时间
	RPT＝ET+ESD+SB+SPD+PB+PHD+PBT

附录B

表3用流切换处理器(SSP)来进行切换延迟时间(SDT)的分析
	SDT＝SRT*+APT*+RRT*+GOPT*+PWT*+PBT≤5秒(见注释1)
APT，RRT&GOPT(用“*”标志)对SDT没有任何影响
	对PBT(PBT＞SRT+PWT)而言，SRT&PWT(用“*”标志)是同时期发生的。

注释1：如果正确地配置播放器缓冲器并且网络足够快的话，所试验的SDT＜1秒。

表4：(见注释2)用流切换处理器(SSP)进行实时播放时间(RPT)的分析

MAX RPT＝ET+ESD+SB+SPD+PB(13)+PHD+PBT(13)＝Fix+6秒
	Min RPT＝ET+ESD+SB+SPD+PB(3)+PHD+PBT(3＝Fix+6秒)
PB＝代理服务器缓冲＝GOP(0-10)+PBT(3)＝3-12秒

注释2：数字值仅是示范性的。

附录C

所用的缩略语

3GPP  第三代合作计划

ADSL  异步数字用户线

HTTP  超文本传输协议

IMS   IP多媒体芯网络子系统

IP    互联网协议

MAN   城域网

MPEG  活动图像专家系统

PLMN  公用陆地移动通信网

PSTN  公共交换电话网

RFC   请求评论

RTCP  实时传输控制协议

RTP   实时传输协议

RTSP  实时流协议

SDP   会话描述协议

URI   统一资源标识符

URL   统一资源定位符

UTC   通用统一时间

WLAN  无线局域网

附录D

[RFC2326]IEIF RFC 22326，“实时流协议(RTSP)”，Schulzrinne H.，Rao A.和Lanphier R.，1998

[RFC3550]IEIF RFC 3550，“RTP：实时应用传输协议”H.Schulzrinne，S.Casner，R.Frederick，V.Jacobson，July 2003

[RFC2327]IEIF RFC 2327，“SDP：会话描述协议”，Handley M.，Jacobson V.，1998

[RFC0793]IEIF RFC 0793或STD 0007，“传输控制协议”，J.Postel，Sept.011981

[RFC0768]IEIF RFC 0768或STD 0006，“用户数据报协议”，J.Postel，Aug.28 1980

Claims (20)

1.一种用于基于由多媒体播放器发送给多媒体服务器的切换请求消息(通知)从第一RTSP流会话切换到第二流会话的方法，其中，

在多媒体播放器(MP)和多媒体服务器(SSP，MS，ME)之间建立的第一RTSP流会话用于根据RTP/RTCP协议向播放器(MP)传送第一多媒体流内容，

第二流会话被建立用于根据RTP/RTCP协议将第二多媒体流内容从所述的多媒体服务器传送到所述的多媒体播放器上，

其特征在于包括下列步骤：

采用相同的编码规则和格式，对所述的第一和第二多媒体流内容进行编码，并由所述的多媒体服务器(SSP，MS，ME)使多媒体流内容保持运行；

在将所述的第二多媒体流内容发送到多媒体播放器(MP)的同时，基于所述的切换请求消息(通知)的信息内容关闭所述的第一会话并建立所述的第二会话。

2.如权利要求1所述的方法，其特征在于，第二多媒体流内容是从采用相同的编码规则和格式编码的M个总是开着的(ME)中选出来的。

3.如权利要求1或2所述的方法，其特征在于，所述的多媒体流内容是编码了的实时信号。

4.如权利要求3之外的任何上述的权利要求所述的方法，其特征在于，所述多媒体流内容是从档案中提取的预先注册的内容。

5.如前述任意一个权利要求所述的方法，其特征在于，所述第一和第二多媒体流内容由所述多媒体服务器(SSP，MS，ME)来缓冲。

6.如权利要求5所述的方法，其特征在于，所述多媒体流内容是视频/音频编码帧，所述多媒体播放器被编程，以便在发送所述的切换请求消息(通知)之前，从其接收缓冲器上清除第一多媒体流内容的视频/音频编码帧。

7.如权利要求6所述的方法，其特征在于，所述接收缓冲器的空出空间采用以大于编码速度的传送速度从存储了所述第二多媒体流内容的所述的多媒体服务器(SSP，MS，ME)的缓冲器上传送来的编码帧来充填。

8.如权利要求7所述的方法，其特征在于，所述编码帧的传送从其随后有大于确保正确播放的给定最小值的多个帧的关键帧开始。

9.如前述任意一个权利要求所述的方法，其特征在于，所述切换请求消息(通知)至少包括下列的信息字段：

-所述请求多媒体播放器(MP)的IP地址；

-运行于播放器上的现行多媒体流的标识符；

-被请求的多媒体流的标识符；

-切换命令；

-在播放器内的缓冲器状态；

-由播放器接收的最后的分组的顺序号。

10.如前述任意一个权利要求所述的方法，其特征在于，所述切换请求消息(通知)符合RTSP协议。

11.一种根据权利要求1的方法操作的通信系统，其至少包括可以通过传输网络与多媒体服务器(SSP，MS，ME)相连的多媒体播放器(MP)，多媒体播放器(MP)和多媒体服务器都包括被配置来用以建立RTSP会话以及撤销所建立会话的装置，该RTSP会话用于根据RTP/RTCP协议将多媒体流内容从所述的多媒体服务器(MS)传送到所述的多媒体播放器，并且该多媒体播放器包括用于向所述的多媒体服务器发送切换请求消息(通知)以便关闭现行的RTSP会话并开启从新的流中得到多媒体内容的新RTSP会话的装置，其特征在于，所述多媒体服务器(SSP，MS，ME)包括流切换处理器(SSP)，该流切换处理器又包括：

第一装置(AAB，ME)，配置来用于使采用相同的编码规则和格式编码的、给定数量M的多媒体流始终保持运行；

第二可控装置(SSPC)，用于从M个所述始终运行的多媒体流中选择一个，并将所选择的流传送给所述多媒体播放器(MP)；

第三装置(SWEL)，配置来用于在运行第二装置的同时，接收所述切换请求消息(通知)，并命令所述的第二装置(SSPC)选择并传送新的多媒体流，以便撤销所述现行RTSP会话并建立所述新会话。

12.如权利要求11所述的系统，其特征在于，包括M个编码器，配置来用于编码和复制所述的多媒体流，并根据RTP/RTCP协议将所复制的流发送给所述流切换处理器(SSP)和所述多媒体服务器(MS)。

13.如权利要求12所述的系统，其特征在于，被配置来用于设置和撤销RTSP会话的装置运行以便只撤销所述现行的RTSP会话。

14.如权利要求12所述的系统，其特征在于，所述被配置来用于设置和撤销RTSP会话的装置是非活动的。

15.如从权利要求12起的任意一个权利要求所述的系统，其特征在于，所述流切换处理器(SSP)包括所述多媒体服务器(MS，ME)。

16.如权利要求15所述的系统，其特征在于，所述流切换处理器(SSP)包括所述M个编码器。

17.如从权利要求11起的任意一个权利要求所述的系统，其特征在于，所述第一装置(AAB)包括M个给定数量的缓冲器(LCB，PCB)，用于临时存储所述多媒体流内容。

18.如权利要求17所述的系统，其特征在于所述多媒体播放器(MP)包括：接收缓冲器，用于临时存储所接收的多媒体流内容，该多媒体流内容最好是含有关键帧的视频/音频编码帧；以及用于在发送所述切换请求消息(通知)之前从所述接收缓冲器中清除该视频/音频编码帧的装置。

19.如权利要求18所述的系统，其特征在于，所述用于将所选择的流转发到所述多媒体播放器(MP)的第二装置被配置用于从其随后有给定最小值的顺序帧的关键帧开始，以大于编码速度的速率发送所述视频/音频编码帧。

20.如前述任意一个权利要求所述的系统，其特征在于，所述传输网络符合UMTS标准。

Images