CN101352013A - 用补充命令文件进行rtp出口流的方法和装置 - Google Patents

Abstract

一种硬件加速流配置，特别地用于RTP实时协议流，采用一个命令文件，该命令文件确定通过一个网络加速流系统发送出去的一个或多个数据包的偏移量和头长度以及指针。命令文件通过控制处理器建立，例如，工作在后台，并且该命令文件被存储，以提供信息，该信息使得包括有效载荷的头大小和指针以及其他数据的信息的确定变为可能，而无需在出口过程中用到相关协议和媒体类型的相关分析数据。这样就使得控制处理器不需要关注，并且允许出口处理以一种重复的方式进行，较佳地，该方式依赖于用于加速的硬件元件，并且使控制处理器进行控制功能而不进行计算，这些控制功能可能比较复杂，但是出现并不频繁，并且/或对实时流在时间上并不敏感。

Description

用补充命令文件进行RTP出口流的方法和装置

相关申请的交叉引用

本申请要求于2005年10月7日提交的、申请号为60/724,462，2005年10月7日提交的、申请号为60/724,463，2005年10月7日提交的、申请号为60/724,464，2005年10月7日提交的、申请号为60/724,722，2005年10月7日提交的、申请号为60/725,060以及2005年10月7日提交的、申请号为60/724,573的美国临时专利申请的优先权，其全部内容通过引用结合在本申请中。

背景技术

本发明涉及实时数据传输的设备和方法，例如应用实时传输协议(以下简称：RTP)流的数字视频处理中心或娱乐系统中，会议系统或其他应用中。本发明也适用于包数据传输应用，其中，在包处理中信息被确定，并且信息被插入到输出数据包头，例如：像包寻址(packetaddressing)或处理信息。该操作需要与RTP流的实时数据速率保持步调一致，较佳地要与有限的计算负荷保持步调一致。根据本发明，命令文件(directing file)由控制处理器形成，可以便于在包出口(packetegress)过程中这种信息的插入。

本发明的设备和方法可用于各种记录、重放(playback)和处理功能，其中，内容和控制信息被导引到功能元件中和从功能元件被导引出，该功能元件能够存储、显示或处理数据。在数据流的上下文中，当响应控制信息时，需要确定某些步骤。例如，当开始一个连接时，需要设置数据包处理和寻址(addressing)配置，以响应控制信息。需要从存储介质或通信路径或套接字(socket)中找到或访问将被传输的包。基于控制输入以及在包中找到的信息，确定如何准确传输的设备开始工作。在发信号过程中，需要决定并使用必需的编码、标记(flags)、地址和其他条件指标(conditional indicator)，例如，插入包头或提供新的用于数据块的包头，在数据块中携带原始的包等。这些步骤可能计算复杂，一般依靠软件进行。

在这样的连接被建立后，数据传输开始，必要条件稍微不同。例如，在一连续流中，下一个包的信息、控制和寻址可能紧密的关系到用于最近的前一个包中的信息。连续包可以通过流以类似的方式被处理。信息包在增加值(incremental)方面可以不同，例如包序列号(packetsequence number)。在从某种存储介质中读取的情况下，源地址可以前置(advance)。然而，计算复杂性会降低。这些步骤受益于速度和效率，一般依靠软件。

如果重复的数据处理步骤计算不复杂是有利的，处理起来与一些功能是不同的。重复的数据处理步骤，例如，数据包到带有存储元件的网络和带有存储元件的网络到数据包的路由；一些功能，例如，控制处理和寻址步骤，这些功能计算复杂但是也相对很少发生。需要一种最佳的解决方案。

一般而言，使使用可能的不同数据格式的可能的不同的装置能够相互作用是有利的。在数据处理系统中，在调节不同的装置和高速数据速率的不同数据格式时，由于需要提供多功能性，设计的挑战提升了。

工业标准支配某些数据类型的格式化。标准影响寻址和发信号(signaling)技术、数据存储和检索(retrieval)、通信等。标准典型地适用在多个级别。例如，当传输根据视频编码标准等编码的视频数据时，包发信号标准或协议可以应用。

使在源端和目的端之间传输的包数据接受中间处理步骤的处理是有利的，这些中间步骤例如数据格式变换、计算、缓存(buffering)以及类似处理和/或存储步骤。在一个有多个服务器和终端设备的数据处理系统中，一部分计算负载来自与数据格式化(formatting)和重格式化(reformatting)相关的操作。一部分负载来自于在源端和目的端之间寻址和交换，在响应如用户选择的条件时，可能需要改变配置。

当形成流数据包时，需要在输出数据包中提供某种信息用来标识该包，以供沿着流信号路径上设置的元件使用。可以控制处理器在不工作时分析流数据，分析流数据是一个计算负载。提供硬件装置来处理此功能是可能的，但是该装置需要是复杂的，且可能缺少程序设计的多功能性。这就需要不同的解决方法。

与提供计算的复杂性相比，形成流和速度简化的目的当然是矛盾的设计目标。与需要计算能力相比，优化速度需求和数据容量的协调是有利的，从而可以提供既快又通用的配置。本发明将用于管理输出数据包的功能再分为某些功能，例如包出口(packet egress)，这样形成必要的输出信息的复杂而且适应的功能由控制处理器来完成，可以通过软件具体实现。

在优选的实施例中，本发明参考实时协议(RTP)包流来进行阐述。讨论一个可仿效的包源端及目的端类型组，该源端及目的端类型组可适用于娱乐或电话会议的视频数据处理，可能包括安全监视、游戏系统(gaming systems)及其他应用。传输路径可以是有线的或无线的，可以包括企业网或公众网。重放终端可以包括音频的和视频的娱乐系统、计算机工作站、固定或便携的装置。数据可以用网络服务器来存储及处理。可仿效的通信系统包括局域网及广域网、宽带和电信公司网络，等等。

与音频和视频数据相关的实时协议(“实时协议(Real TimeProtocol)”也被熟知为“实时传输协议(Real Time TransportProtocol)”)是一种标准协议，该协议适用于移动成包后的音频和/或图像且通过数据通信网络以实时数据速率移动图像数据。在避免内容的停止和开始的同时，需要以实时或现场(live)的速率重放音频和视频数据，以最小化对缓存器的需求。在类似电话会议及类似的通信的应用中，有利地收集、处理、传输及读取成包后的数据应当仅有一些可察觉的延迟，并且应当没有间隔，应当和面对面的实时会议及交谈一致。

RTP实时协议是，用改进的方法，意在使处理包括音频和视频在内的实时数据更便利的协议。它可以用于媒体点播(media-on-demand)和交互式服务，比如因特网电话。它可以将音频和视频数据从多个源端和目的端导出，或将音频和视频数据导入到多个源端和目的端，以使显示和/或记录能够与并行的处理一起进行。

用控制和寻址功能，比如开始或结束包括特殊源端、目的端或参与者的连接，数据处理的方式有时是可改变的，因而RTP包括用于内容传输的数据内容部分和用于改变数据处理方式的控制部分，包括开始、结束及寻址。RTP的控制部分叫做实时控制协议(Real Time ControlProtocol，简称RTCP)。

RTP的数据部分是单薄或精简的协议，该协议为具有实时属性的应用提供支持比如连续媒体(如音频和视频)的传输。该支持包括时间重建(timing reconstruction)、丢包检测或恢复(loss detection orrecovery)、安全、内容识别及类似功能，这些功能为重复的，并且随着媒体内容的传输连续大量地发生。

RTCP为在通信网络中(比如互联网)的任何大小的组的实时会议提供支持。该支持包括源端识别和像音频及视频桥(video bridges)的这类网关的支持，还包括对多播到单播转换器(multicast-to-unicasttranslators)的支持。它提供从接收器到多播组的服务质量(quality-of-service)反馈以及对不同媒体系统的同步提供支持。

RTP和RTCP是特别安排以使上面提到的数据传输更容易，但在特定的网络结构中RTP和RTCP协议可能和更高层次的或更低层次的协议及标准联合。在更高的层次上，比如，RTP和RTCP协议可能被用来服务视频会议系统或监测及储存(view-and-store)或其他处理数据的技术。在较低的或更基础的层次上，应用于RTP和RTCP数据传输的包可能实际上依照不同的包传输信息协议被传输。例如，传输控制协议(TCP或在网络上，TCP/IP)及用户数据报协议(User datagram Protocol，简称UDP)。

TCP和UDP协议都是用于包传输的协议，但是在包的完整性(packetintegrity)和错误校验(error checking)、对丢包的敏性以及其他方面，二者又有着截然不同的特性。TCP协议通常帮助确保在传输中维持一个双向连接(two way connection)，该连接持续直到所有相关的包被传输并在接收端被组合，可能包括重新尝试获取丢失或损坏的包。UDP通常处理包传输尝试，但是是由发送和接收包的应用来保证所有必须的包都被发送和接收。一些应用，比如电话会议图像流，对包的间歇性丢失并不非常敏感。但如果包应当被丢弃，那么将是有利的，可以使流尽可能的无间断。

在允许充分利用有区别的不同协议的各种方式的优势的同时，如果技术可以被解决，其中用大范围的更高层次和更低层次的协议的实时传输可操作，这会是有利的。在高性能或高要求的系统中，适应操作将会是非常有用的，这样，用于通信的可用资源，用于计算的条件敏感切换(situation sensitive switching)以及决策制定的可用资源可以被最优化。

发明内容

本发明的一个方面是通过使用数据处理配置(arrangements)提供有效的视频及类似的连续的流数据处理，该配置具有分立的并且同时间操作的传输数据路径和控制数据路径，其中这两个数据路径，使用分别为吞吐量(throughput)和处理能力配置的资源，分别处理数据吞吐密集的功能和数据处理密集的功能。

更具体地说，为处理器和切换装置的处理，通过将与实时协议相关的源密集(resource-intensive)处理的多个子集(subsets)进行划分，这些处理器和切换装置为他们被指定的子集被优化，提供了一种方法和装置，用于方便和加速媒体服务器进行的处理。基于速度的功能的划分被分配给拥有数据通道(pipelines)特征的装置。计算负载被分配给一个或多个中央处理器，该中央处理器管理RTP会话(sessions)以及处理计算侧操作，而无需处理器过多关注数据通信通道中流数据的移动。

在某些实施例中，该方法涉及使用硬件接口元件，该元件至少部分组成用于定义与RTP包流相关的输出数据块(data blocks)而提供的信息。提供了一种命令文件，该命令文件能以被中央处理器全部或部分提供的方式提供，并且被连接到一个加速器元件，该加速器元件访问该与包出口相关的命令文件。该命令文件引导该与包出口相关的硬件加速器。处理器处理不同的并发的流连接，而没有必要分析每一个包。可代替地，处理器为每一个进行中的连接建立命令文件，并且当包被发出时，加速器应用该信息。

该加速器可以是一个硬件接口元件，可以以高速数据速率运行，而无需充分的监视，该元件提供必需的基于命令文件内容的程序块及头信息(header information)。因此，控制处理器不需要注意计算密集的功能。虽然在讨论的优先的实施例中加速器是硬件元件，但加速器中的处理器并不被排除在外。

依照一个实施例，内容可寻址存储器(Content Addressable Memory，简称CAM)文件被维持，通过该CAM文件硬件加速器把多个目前可维持的包队列(packet queues)与某些地址联系起来。CAM文件可以被用来确定头信息，尤其是与包括多等级偏移量(offset)头的数据包相关的头信息。当设置(SETUP)请求被接受以发起新的到新的端点(endpoint)的流连接(streaming connection)且CAM文件中没有发现匹配的记录(entry)时，硬件加速器发信号给处理器且建立记录。该硬件加速器提供相关的头值(header values)，即通过在内容可寻址存储器发起一个记录，预期记录(RECORD)或发送(SEND)消息。与新的端点相关的头值被控制处理器已知，但处理器仅仅需要通过在内容可寻址存储器(CAM)中设立新的包队列来建立到新端点的路由。然后该硬件加速器可以像机器人(automaton)那样运行，可以为输入包找到包队列记录，替代必需值以及将包传输到它的目的端。

当有一个已经建立的队列记录的RTSP记录(RECORD)或发送(SEND)消息被接受时，在与流量管理器(traffic manager)和中央处理器的数据通信中，该硬件加速器负责确定输出头值。该连接可以保持进行中且可以从高数据速率获益，直到完成或直到中央处理器实现(effect)必需的新的控制及活动，比如依照任一可编程的功能确定端点或流的端点。该功能可以包括许多或全部另外会需要处理器通过已编程的软件程序确定如何处理每一传输包的功能。该功能可以包括在源端和目的端间的包路由、插入中间处理步骤、路由包同时到达两个或多个目的端，比如播放的同时记录(record while playing)，等等。

本发明采用含有用于普通头及头块(header block)的信息的命令文件，附加在RTP头中，用于包出口(packet egress)，例如输出(output)，这样，加速包输出的管理就是使控制处理器空闲时重复的注意减到最小。

流数据率和吞吐量要求是非常严格的。为了使用的处理器保持步调一致，需要非常快且能力强的中央处理器以释放计算负载，以及形成和插入信息到输出数据块中。本发明的一个方面在于采用命令文件来最小化中央处理器的计算负载。在这种情况下命令文件可以被安排连接到硬件加速器，该计算负载可以被充分的限制到通过控制器建立命令文件，以及允许流在没有控制器的监视下继续发送数据块。

本发明的一方面是提供最佳的解决方案用有效的方式处理控制和内容包(content packet)。RTSP/RTP解决方案不应该全部通过硬件或全部通过软件执行，而最好的应该是通过混合的方案执行，其中处理过程很大程度上被软件控制，而该过程产生可以被使用的登记值(register values)及类似的值等等，使用媒体对象及软件产生的支持文件以加速数据传输更适宜使用硬件。

由于操作的相对复杂和少见，RTSP和RTCP(即在极大程度上用于管理控制过程的包)可以在中央处理器上执行而不会使中央处理器过载(overburdening)，这是由于RTSP或RTCP包需要少量的关注(attention)。另一方面，RTP处理需要专注于每一个媒体流中的输出包的处理，可以从加速中获益。

包发送流需要严格的实时支持，比如与数据包的实时速率同步。本发明采用命令文件，是一种提示，使用提示(hinting)为硬件提供需要的RTP包信息，或者导致必要的发送信息的产生。控制处理器可以用作确定命令文件的内容。然而在命令文件为连接到位后，通过移除必要条件，该提示技术(hinting technique)加速了服务器上的RTP流，该必要条件是为了继续处理，服务器或控制器空闲(on-the-fly)时分析被形成流的媒体的必要条件。

本发明技术并没有将负担全部转移到硬件。例如，本技术不需要硬件由于可能需要分析提示数据而具备充分的复杂性。

考虑到以后的扩展，合适的命令文件的格式是可以灵活变动的(flexibly)。同时，命令文件格式的灵活性，不会使将高重复性计算简单的流功能转嫁到硬件装置这一目标变得复杂化。

本方法通过在补充文件(complementary file)中包含除媒体对象之外的必要信息，可以解决这一问题，该补充文件可以被硬件使用。如果带有特定RTP包类型(即按照FRS定义的包类型)的媒体文件可被流装置(streamer)访问，作为形成流的备选方案，可以生成一个命令文件。该文件是由运行在中央处理器上的软件在后台产生的，即作为一个低优先级的功能，当资源可获得时被处理。命令文件与提示数据相似，用于通知流装置如何将RTP成流对象(the object for RTP streaming)打包。然而，本发明命令文件在如何影响包的出口上比提示数据更为具体。因而，即使中央处理器对于原始媒体对象具有较少了解，本发明技术也可以运行。

这些及其他目的和方面会在如下的优选实施例及例子的讨论中变得明显。

附图说明

某些可仿效的，非限定的，作为目前优选的本发明的实施例如附图所示。然而，为了确定本发明要求保护的范围，应当参考权利要求中要求主张的权利。在附图中，

图1为本发明源端到目的端数据传输关系(例如，服务器到客户端)的结构图，其中，RTP数据内容成分围绕控制点路由，控制点例如是处理RTSP和/或RTCP控制信号的中央处理器；

图2为本发明流控制器的结构图；

图3示出在RTP头中的成分(component)值的表格；

图4为代表性实施例命令文件的数据表格；

图5为附加娱乐系统“HNAS”的家庭网的部件结构图，“HNAS”被较佳地配置成包括本发明的包数据处理规定。

具体实施方式

RTP不进行源预留(resource reservation)，且不保证为实时业务的业务质量，如在RTP协议层次上保证维持连接和信息包不丢失等。数据传输协议，即RTP，通过可用于会话控制(即从源端到目的端的RTP传输)的控制协议(RTCP)和全面的显示控制协议被补充。

RTCP和RTSP控制协议涉及被传输的包，例如，当建立或撤销一个传输路径时，当在一个方向(PLAY)或其他方向(RECORD)开始传输时，当暂停时等。内容数据包需要以一些同步的参考，尽可能实时地连续地流动。内容包，与RTCP和RTSP包同时被传输，但是这三个独立协议使用不同的被编址(addressed)的逻辑连接或套接字(sockets)。

RTCP/RTSP控制和RTP数据流协议一起提供可以升级至大型组播网络(multicast networks)的手段。设计RTP和RTCP以使其不依赖于下层传输和网络层，这样，可以使其与不同的可选择的某一层使用。该协议也在需要的地方支持RTP标准的转换器(translators)和混合器(mixers)的使用。

RTP控制协议(RTCP)具有监控服务质量和传播有关正在进行会话的参与者的信息的能力。参与者信息对于“宽松控制的(looselycontrolled)”会话已经足够，例如，没有明确的成员人数控制和设置的会话，但是，确定的应用就要具有更多的需求授权或者通信要求，一般地，这是RTSP会话控制协议的范围。

在源端和目的端之间流动的RTP数据内容包充分简单的，实时沿着向目的地址传递。鉴于包的实时传递，在接收设备上，很少需要缓冲存储。基于同样的原因，典型的发送设备不需要创建临时文件。不同于其他的一些协议，如HTTP对象传输，RTP用媒体-特定头(media-specificheaders)将对象打包。RTP接收器被配置成可恢复包丢失(packetloss)，而不具有重新尝试发送信号的能力。RTP传输可以使用TCP/IP无连接协议。典型地，RTP传输由RTP数据的用户数据报协议(UDP)包传输被完成，典型的，但不一定要用各个UDP包组成一个RTP包。

RTP包具有标识该包为RTP包的确定的头(header)、包序列号(packet sequence number)、时间戳(timestamp)、同步源识别(synchronization source identification)、贡献源标识(contributing source identifiers)的空列表和有效载荷数据(payload data)。有效载荷数据包括特定数量的数据值，如音频采样(samples)或压缩视频数据。

RTP流系统使用不同的实时数据内容包(RTP)、控制包(RTCP)和/或会话控制包(RTSP)。管理包(RTCP、RTSP)与连接相关，该连接可以携带RTP包越过一个或多个连接。RTCP和RTSP连接包括不同连接套接字(sockets)RTP，但是，更重要的，包在频率和功能上是不同的。

在接收器中提供一个处理器是可能的，如连接到娱乐系统的网络、电视会议系统、附有存储装置或类似装置的网络，并且为处理器设计程序以适当地将RTP包与RTCP或RTSP控制包进行区别是可能的。数据包被传向它们的目的端，控制包由处理器使用于影响其他程序功能和信息的传输。为了让该系统保持步调一致，RTP内容包必须实时被处理，并且，如果中央处理器用于管理包括插入到包出口之上的字段(fields)的包的详细数据，处理器必须以高数据速率运行。

在形成流过程中的控制包可以被引导到一个或多个方向上的各种特定连接上，这些连接具有不同的数据格式，涉及到多个端点(endpoints)。控制处理器需要计算复杂性和需要可能的处理涉及到的控制过程的编程。如果一个特定的处理器，具备足够的计算复杂性(例如具有一个复杂的程序)，并被用于阐述RTP内容包，那么高的数据速率和复杂的计算能力是需要的。然而，如果处理器花费大部分运行能力在越过一个或几个可识别的连接一个接一个传输包上面，例如包出口，那么处理出现频率不高的复杂控制计算的处理器的计算能力就被浪费了。

本发明的一方面提供一种方法，该方法中，通过控制处理器产生的计算结果可以传递到相对不太复杂，但可能更快的硬件装置来向前传递包，例如，包的出口。该方法通过使用本发明的命令文件技术来完成。

图1示出一个简单的网络环境，一个控制点被布置在一个服务器(即流数据的源端)和一个客户端(目的端)之间。每个相互连接由用于RTP流的不同的支持包类型标注。通过提供一项技术，用前文描述过的硬件加速器将消息头中的字段进行替换，本发明的主题广泛的适用于涉及到控制点、将在控制点进行处理的需求至少部分分流(bypass)的架构中。

图2示出种一代表性的情况，其中，控制点被表示为一个中央处理器，该中央处理器通过网络连接到包的源端(所示为一服务器)。在该结构中，所示中央处理器通常需要传递包至一个或多个目的端，例如，通过流量管理器/仲裁器(traffic manager/arbiter)，通过将包流(astream of packets)中的被标识的包从包的源端导引到一个或多个可寻址(addressable)的目的端，或者传递到一个读出装置；目的端，例如是附加存储元件的网络，在本实施例中存储元件由磁盘存储器和它的控制器来表示。

根据本发明的一方面，包数据部分被网络加速器形式的接口装置处理。该网络加速器具体可以是一个具有高吞吐量的装置，如果进行混合计算时，该装置的吞吐量最小，该混合计算用于在包含有RTP包的数据块中插入值，从而控制RTP包的处理以及后续的流的处理。为了这个目的，命令文件产生，该命令文件包括包含标识编码的头部分和一些值的集合，这些值包括包计数(packet count)、头块大小(header blocksize)、用于标识待处理的RTP头的数据的位置的长度值和/或指针(pointers)。

在该例子中特定的源端和目的端实体(entities)是典型实例。本发明适用于涉及到多个可能的源端和临近的或远端的目的端的情况，远端和目的端被连接到所示的数据通信中，这样，包的源端和目的端就能在两个这样的实体之间在一个或另一个或两个方向上传输包。这个特定的例子可能被用来处理包的通道，该包的通道在内容信号出现在重放装置上且同时被记录(record)的位置上。在其他的例子中，数据流配置可以被设置，其中数据被记录但没有被重放或者重放但没有被记录。也可以涉及到其他的特定的源端和目的端元件。同样的输入包可以从一个源端被路由到两个或多个目的端。可选择地，来自于两个或多个源端的内容可以被指定为并列存储或者重放，例如，画中画插入(picture-in-picture inset)或者同时并行播放(side by sidedisplay)，例如进行电话会议时。这些以及其他类似的应用根据本发明已经是可能的了。

数据流分成三个主要的类型，即用于全部的显示控制的RTSP包；用于个人会话控制的RTCP包；以及用于数据内容传输的RTP包。

RTSP是一个应用层协议，常用于控制一个或多个并行发生的显示或者数据的传输。单个RTSP连接可以控制几个RTP对象并行的和/或串行的传输。在视频会议配置中，例如包括多个地点，双向传输可以在每两个地点间设置。RTSP的语法类似于HTTP/1.1的，但是它对媒体传输提供明确的协定。定义会话的主要的RTSP命令为：

●设置(SETUP)：促使服务器为流分配资源和开始RTSP会话。

●播放和记录(PLAY and RECORD)：在通过SETUP分配的流上开始从源端到目的端的数据传输。

●暂停(PAUSE)：暂时停止流而无需释放服务器资源。

●撤销(TEARDOWN)：释放与流联系的资源。RTSP会话停止存在于服务器上。

当控制点使用RTSP SETUP请求(RTSP SETUP request)请求对象传输时，控制点发送请求到服务器和包括对象传输详细资料的客户端，对象传输详细资料包括对象标识、源端和目的端IP地址和协议端口，并且使用传输级协议(一般包括RTP和TCP或UDP之一)。这样，RTSP请求描述到客户端和服务器的会话。在某些情况下，请求会明确的针对可用对象的子集(subset)，如对象的音频或视频成分。

当全部必需的设置(SETUP)请求已形成并被获知(acknowledged)，控制点可依据传输方向发起播放(PLAY)或记录(RECORD)请求。请求可选择地指定被传递的对象的某一范围，对象的正常播放时间，以及重放应开始的当地时间。

在重放完成之后，会自动暂停显示，就像暂停(PAUSE)命令被发出似的。当发出暂停(PAUSE)命令，暂停(PAUSE)命令指定流应被暂停的时间戳(timestamp)，并且服务器(客户端)停止传递数据直到随后发出播放(记录)(PLAY(RECORD))请求。

当发出撤销(TEARDOWN)请求，在指定流上的数据传输被暂停，并且全部联合的会话资源被释放。

RTSP命令可指定一带外(out-of-band)传输会话，其中，RTP/UDP或者RTP/TCP被用于传输。“带外”传输表示两个或多个不同的传输或连接路径。如果是那样的话，RTSP业务可以在一个连接上进行，并且不同的连接可以被RTSP指定以承担RTP数据的现行传输。

RTP包可以通过TCP传输。这通常效率不高，因为UDP传输不需要一个持续连接，对丢失包是不敏感的，和/或不会如同TCP那样会设法进行丢包检测和回复。UDP传输协议适合实时传输如音频或视频数据采样值的包。这样的值并非独特的，至关紧要的，但是需要以高的数据容量(high data volume)被移动。TCP在连接建立上不同于UDP，该协议强调可靠性，例如，通过获得转播试图恢复丢包等。这些方面与RTP需要的一致性要弱于UDP该公开的情况通常认为UDP被用于RTP传输。然而，该公开不应当被认为是优选的UDP传输的限定，代替的，也可以是其他的包括TCP的协议。

当服务器收到用RTP传递对象的请求时，典型地，对象被从它的原始格式转换成可被打包(packetizable)的格式。很多请求注释(Requestfor Comment，简称RFC)消息线索(threads)已在工业中形成，以解决与描述过的打包数据相关的问题，并且保持在线访问，例如，通过互联网工程任务组(Internet Engineering Task Force，简称IETF)，包括一个用于各种给定媒体类型的相关RFC。

根据在联合的RFC中提供的标准的规范，每个媒体对象类型典型被不同地打包，甚至不同的类型用不同的头格式(header types)。差别应归因于在具有不同用途的处理数据中遇到的不同的对象和问题。

如图3所示为普通RTP头的格式，例如，在RFC 3550/3551中提出的。头字段缩写如下。

“V”表示版本号。当前版本是版本2。尽管在头中没有能够独一无二地标识该包为RTP格式的信息，但是，在该头位置版本号“2”的出现就是一种标识。

“P”是一个值，用于说明在有效载荷的末端是否存在应当被忽略的间隙(padding)，如果存在，那么就是间隙的范围。间隙值的最后一个比特给出了间隙的总数目

“X”为一个值，用于表示是否存在扩展头(extension header)。

“CC”为在该头中被标识的有贡献的源(contributing sources)的计数。

“M”为一标记位。该位的执行特别地针对有效载荷的类型。

“PT”标识有效载荷的类型，就是被传输的对象的类型。在其他的协议中，有效载荷类型标识符允许接收器决定如何终止RTP流。

“序列号”为传输的RTP包的数目的总数。应当注意，这时不同于TCP的，TCP用序列号标识传输字节(bytes)的数目。RTP序列号为传输的RTP包(packets)的数目，如，包索引(packet index)。

“时间戳”为依赖于有效载荷类型的字段值(field value)。典型地，时间戳提供用于包被发送的时间索引，以及在某些情况下，提供允许接收器适应记录或回放信息包内容的参考。

“SSRC ID”标识被传输的数据源。

“CSRC ID”标识任意的有贡献的源端或已处理被传输数据的源端，如混合器(mixers)、转换器(translators)等。可以有多个有贡献的源，或者除了在SSRC ID中标识的原始源没有其他的源。如上述表明的，在头中的值CC为有贡献的源的总数。总数允许不确定数目的有贡献的源标识同等的被对待，并在跟着头的内容前为其编索引。

如果X位被设置，则有一个紧跟RTP头的扩展头。扩展头的用途和性质依赖于有效载荷类型(payload-type-dependent)。特定的有效载荷子头以一方式被明确，该方式为允许改善包损失以忍受某一事件的发生次数。对于某些格式，如MPEG2，带有视频和音频编码信息的很多复杂的子头可能跟随着主要RTP头。

如图3所示，有效载荷跟着包中最后一个子头。到初始媒体对象(native object)的有效载荷的关系也由描述对应的有效载荷类型的标准所决定。通常在初始对象(native object)和RTP包有效载荷的连接(concatenation)之间不是一对一的。尽管导致这个的因素是多方面的，RTP包有效载荷序列和包含在初始对象中的字节的序列之间的差别可能是由于：

●为一特定帧使音频和视频信息同步的需求；

●在一RTP有效载荷内部数据块的交叉；

●重复包用于一重要的数据要素；

●音频/视频分离(demuxing)

●或者1.1.3RTCP

周期性地，当特定RTP会话被激活，关于会话的控制信息在使用RTCP的单独连接上被交换(对于UDP，RTP会话使用偶数数目的端口，并且RTCP信息在下一较高级的奇数数目的端口上传输)。RTCP执行各种功能，包括提供数据分发(distribution)质量的反馈，提供该反馈对于服务器确定网络问题是本地的还是全网的非常有用，特别是在IP多播传输的情况下。RTCP也对为RTP源、别名记录(CNAME)携带的持久的传输层标识有作用。由于冲突或程序重启可能引发SSRC IDS的迁移，接收器需要CNAME明了各个参与方。CNAME也可用于同步来自于多个RTP会话的多个相关的流(如，同步音频和视频)。

传输中的所有的参与方都需要发送RTCP包。当会话中的参与方的数量增加时，由各个参与方发送的包的数量有利地被按比例减少。通过各个参与方发送它的RTCP包到全部的其他方，各个参与方可以明了参与方的数量。该数量被用于轮流计算控制包的发送率。RTCP可用于传播最小会话控制信息，如在用户接口播放的参与方信息。

为了完成这些任务，RTCP包分成如下种类和格式之一：

●SR：发送器报告(sender report)，用于来自参与方的传输和接收统计，该参与方是激活的发送器；

●RR：接收器报告(receiver report)，用于来自参与方的接收统计，该参与方不是激活的发送器，并结合SR为激活的发送器报告多于31种源；

●SDES：源描述项，包括CNAME；

●BYE：标识参与的结束；以及，

●PP：明确的申请功能(application-specific functions)。

与RTP类似，每种形式的RTCP包以一通常的头开始，其后紧跟不同长度的子头。多种包可以被连接(concatenated)，以形成一个复合包(compound packet)，该复合包可以连同低层协议中的单个包被一起发送。这就需要产生各种计数器和指针来区分流中预期字段的位置。

本发明的一方面优化在RTP格式的流数据的处理，特别是通过在流包(streaming packet)中包含一个命令文件来促进出口流(egressstreaming)，该命令文件包括计数和索引指针值。

RTP包的出口流须被实时提供。因为进行着的流的特性，实时处理是减少对缓存器(buffer)的需求(或者至少是它们的大小)的RTP协议的一个重要的方面。本发明采用不同的提示，这些提示可以为硬件提供某种RTP包信息。通过将服务器在空闲时(on-the-fly)分析正被形成的流的媒体的需求，这种方式的提示可以加速服务器上的RTP流。

“提示(hinting)”为有时用于表示信息的项，该信息与被压缩的视频(例如MPEG-4)一起被编码，与被压缩的数据不同，单独被发送，该信息典型地被指定的装置使用，该装置能够分析该提示，从而辅助相关的被压缩视频数据的解压缩。

根据本发明，提供了一种补充信息文件(complementaryinformation file)作为通常的头(header)和头块(header block)。这样，就不需要专用的能够分析提示数据的硬件，来处理特定格式的前向的和后向的相关的图像文件(image files)。可代替地，命令文件为一连串的用于索引本地RTP头和包信息的计数和指针值。

命令文件不同于解压缩提示方式或类似方式，在这些方式中，指针信息被灵活表示，例如，可表示不同的包数据格式以允许用于将来扩展。在接口文件中提供灵活性，对于从处理器中移出部分流功能(streamingfunctionality)到硬件元件中，可能会造成困难，该处理器被编程以识别不同的格式，而硬件元件中的大部分参数是固定的。本方法通过在补充命令文件中包含所有必要的信息(除了媒体对象本身)可以解决这个问题，该命令文件可以被硬件使用，部分因为该命令文件包含与信息相对的索引指针，这些信息用众所周知的偏移量和其他期望值来格式化。

如果一个媒体文件具有确定的RTP包类型(通常由RFC或注释信息(thread of comments)引导的指定改进(stated refinements)来证明)，可以被流装置(streamer)访问，并且可以是形成流的候选文件，那么可以通过运行在中央处理器(较佳地，当源可用时，运行在后台)上的软件来首先生成命令文件。

该命令文件类似于提示数据，在提示数据中，可告知流装置(streamer)如何将RTP流对象打包，但是，命令文件更加明确如何去做，并且它认为中央处理器甚至没有关于初始媒体对象的知识。代表性的命令文件45(二进制数文件)的格式如图4所示。

参考图4，普通头(General Header)仅被定义在文件的开始，并且可以应用到整个字块(block)。普通头包括：

●版本/鉴别字段(version/authentication field)，允许流装置验证命令文件为正确格式文件，

●包总数字段(total number of packets field)，如果整个文件被使用，该字段定义被传输的包的数量，

●命令文件头字块大小(directing file header block size)，定义命令文件中为各个头字块分配的字节(bytes)的数量。

头字块通过命令文件45被明确用于各个包，各个包被明确用于传输。头字块具有固定的长度用于特定的命令文件45。头字块包括：

●有效载荷偏移(payload.ptr)，是一个文件，包含从存储器中对象的起点开始，当前包的有效载荷的偏移量，

●主体跳转(bodyskip)：指示有多少字节从当前队列位置跳转(若有的话)直到有效RTP载荷的起始位置，

●有效载荷长度(body.length)：指示RTP有效载荷的长度，

●头长度(header.length)：指示用于当前RTP包的RTP头字段的字节的数量。

当生成命令文件时，其被存储，所以命令文件可以与特定的对象关联。如同提示数据，如果有多种方式对象可被形成流(不同包类型，或者对于相同包类型的不同网络属性)，那么，多个命令文件可与一对象关联。

这个事实的扩展允许流装置通过生成仅指向I帧(I-frames)或指向每N个I帧的命令文件，很容易地实现快进/快退(trick-play)功能，其中，N与命令文件45规定的快速发送(fast forwarding)的速度有关。

如果对应的RTP会话还不存在和没有被建立，设备仍然保持准备状态直到在核心处理器上运行的RTSP提供从端点接收的SETUP命令。一旦RTSP接收设置(SETUP)消息，它从设置(SETUP)消息确定一套查找参数(源端和目的端IP地址和端口，以及传输协议)，并且在与硬件加速器相连接的内容可寻址存储器(CAM)中，为该会话分配连接表记录(entry)。在CAM中，用于RTP会话的有效位(valid bit)立即被设置。然后RTSP等待一来自于相连的控制点的随后的播放(PLAY)请求。播放(PLAY)消息可包括播放流的(时间)范围。

这时，会话可被认为已经建立，网络加速器和流量管理器(trafficmanager)预备分发数据。流量管理器有两个适用于各个RTP会话的联合队列，一个用于从初始媒体对象传输数据的对象队列(object queue)，以及一个用于传输从命令文件读取的RTP头的头队列(header queue)。对于各个被发送的RTP包，流量管理器使用命令文件的字段来提取RTP头和有效载荷，以及安排(schedule)产生的包。然后，流量管理器发送包到网络加速器。

网络加速器的操作包括：

●添加偏移量(offset)到输出包的RTP头的序列号字段，该偏移量由中央处理器决定，作为相关传输的CAM连接表记录中的一个字段存储。如同RFC3550中规定的那样，提供一个随机ISS是有利的。

●用类似的方式调节输出时间戳。如同RFC3550中规定的那样，提供一个随机ITS是有利的，

●构建并将层3和层4头应用到输出包(如前置(pre-pend))，以及

●发送输出包到MAC/PHY字块。

该方法允许媒体对象形成流，而不需要网络加速器对于初始媒体对象的格式有任何了解。由于命令文件较优地是由运行在中央处理处理器上的软件生成的，新出现的包类型可以很容易地通过软件设置调节。该方法进一步允许流装置的重复性数据通道(data pipeline)功能从控制处理器中被转入偏重于硬件(hardware-oriented)的网络加速器中进行处理。不过，这些计算不太复杂的重复性数据通道功能，具有较高的时间优先级(time priority)。本发明在网络加速器中提供这些功能，保留中央处理器的能力和处理时间，中央处理器用于处理面向控制的出现频率较低的需求，这些需求获益于计算复杂性，并且很难与流连接的数据通道功能的时间要求保持协调。

网络加速器使用命令文件处理数据包时不需要或很少需要了解媒体对象的格式，与这一要求保持一致，较佳地，命令信息应当被包含在一个文件当中，而不是一个磁道(track)中。这样，服务器不需要知道如何提取用于特定输出包或包字块的指示信息。

假设命令文件45一旦生成，通过使用当前设置的普通头和字块头(block header)的指针和计数值，该对象可以用于任意次数的流形成。流装置(streamer)需要一种方式来访问和分类命令信息，前面提到的使用带有指针和计数的文件是比较方便的方式。一个附加的好处在于，出口流命令文件45不需要被传输到端点，端点不需要与从流装置中出口流相关的信息，该流装置将包或包块发送到该端点。

本发明的一方面通过提供代替仅硬件解决方案或仅软件解决方案的混合硬件和软件的解决方案，来改善总体RTSP/RTP解决方案的完成。如果任何全硬件解决方案用于整体控制情况的方案，是非常复杂的。相比而言，具有处理这种复杂情况的处理器和编码能力的任何仅软件解决方案还没有完全被开发。对于一个正在被处理的给定流之后的大多数操作，用于为给定流处理连续包的方式与之前的包是相同的，这些方式是重复的，并且不需要大的计算能力。

本发明为混合解决方案的一部分，其中控制过程被可运行可能复杂的和有能力的软件程序的控制器设置和安排，但是，当连接被激活以执行控制器已设置好的流操作时，控制处理仅设置要素(factors)、值和指针来使得网络加速器(较佳地可以是硬件，但不是必须是硬件)继续处理。

参考图5，在一优选实施例中，本发明结合包括磁盘阵列控制器装置的数据操作系统。该装置可以执行存储管理和为用户电子数字媒体应用提供服务，或者其他类似特性的应用，如通信和电话会议(teleconferencing)。在娱乐应用中，装置提供在本地网和数据存储装置阵列间的接口，一般地，例如通过硬盘驱动器(Hard Disk Drives，简称HDDs)来存储数字媒体(音频、视频、图像)。

更好地，该装置提供一个接口到家庭网络(home network)或其他局域网(local area network，简称LAN)的综合的10/100/1000以太网MAC端口。USB 2.0外围附加端口被方便地提供用于媒体输入装置(如闪存卡)的连通或通过外部无线LAN适配器附加提供到无线家庭网络(home network)的连通。

通过高层协议加速引擎(engine)(用于IP/TCP，IP/UDP处理)和会话意识流量管理器(session-aware traffic manager)，较佳的数据操作系统使用许多层和用于共享高性能的功能(functions)访问媒体档案文件(media archive)。会话意识流量管理器用作中央处理器，中央处理器除了管理此处提到的RTP流，还根据激活媒体会话的类型，提供共享资源的分配，例如网络带宽、存储器带宽和磁盘阵列带宽。例如，视频会话接收比图像浏览会话更多的资源。此外，带宽被分配，作为用于时间敏感的媒体会话的保证带宽，或作为用于非时间敏感应用的最好(best-effort)的带宽，如媒体档案文件批量上载或多个PC备份应用。

数据操作系统包括带有独立磁盘冗余阵列(Redundant Array ofIndependent Disks，简称RAID)的高性能流。流-RAID(streaming-RAID)块可被安排用于错误保护冗余及防止任何单个HDD的失败以保护存储在在档案文件上媒体。HDDs可为串行ATA磁盘(SATA)，该系统，例如包括8个SATA磁盘，具备通过流量管理器/仲裁器块处理64个同时的双向流的能力。

数据操作系统为本发明多种可能应用的一个例子，全面的数据操作系统如图7所示，仅概括性的描述。在该装置中，有两个分离的数据通道，即接收通道和传输通道。“接收”通道被认为是从其他外部装置到该系统那个的业务流的方向，“传输”通道为数据流的反方向，在给定流的上下文(context)中，该通道在某个点分别引导从一个源端来的数据传输和到达目的端的数据传输。

高层处理器(Upper Layer Processor，简称ULP)耦合数据通信到/从G比特以太网控制器(Gigabit Ethernet Controller，简称GEC)或者外围流量控制器(Peripheral Traffic Controller，简称PTC)。PTC直接接入到流量管理器/仲裁器(TMA)用于基于传递的非包(nonpacket)。包传递如此处描述的被处理。

在接收数据通道中，GEC或者PTC块典型地从物理接口接收以太网包，例如，该物理接口是一个连接到/自一大型网络的接口。GEC执行多种以太网协议相关的检查，包括包完整性、多播地址过滤(multicastaddress filtering)等检查。包为了进一步的处理被传递到ULP块。

ULP分析层2、3和4的头字段，该字段被提取来形成地址。然后，基于该地址的连接查找被执行。使用查找结果，ULP做出发送接收到的包到哪里的决定。来自已经建立的连接的到达包(arrival packet)携带出于业务队列目的被TMA使用的预先定义的队列标识(Queue ID，简称：QID)。来自于未知连接的包需要通过应用处理器(ApplicationProcessor，简称AAP)进行进一步的调查。该包用一特定QID标注，并被路由到AAP。AAP之后，到达包的最终目的端可为当它携带媒体内容时的用于存储的硬盘，或者为当它携带控制消息时的用于进一步调查的AAP，或者包不能被AAP识别，可能导致新的QID的建立。在上述的任一种情况，包被发送到TMA块。

TMA在共享存储器中存储达到的业务。在媒体对象传递的情况下，输入的对象数据被存储在存储器中，并传递到RAID解码器和编码器(RDE)块用于磁盘存储。TMA通过为RDE提供适当的控制信息管理存储过程。指定用于AAP检查的控制业务也被存储在共享存储器中，并且AAP被允许读取存储器中的包。AAP也使用这种结构来再排序(re-order)任一接收到的无次序(out-of-order)包。一部分共享存储器和磁盘包含用于AAP的程序指令和数据。TMA通过从磁盘传递控制信息到存储器和从存储器传递到磁盘来管理到存储器和磁盘的访问。TMA也使AAP能够从现存的包流中提取数据和插入数据到现存的包流中。

在传输数据通道中，TMA管理来自于磁盘的对象检索(retrieval)请求，该请求被指示为必需被处理通过应用处理器或网络接口发送。在从应用处理器接收到媒体重放请求之后，TMA通过MDC和RDE块接收从磁盘传递的数据，并存储在存储器中。然后TMA根据需要的带宽和媒体类型，调度数据到ULP块。ULP用以太网和层3/层4头，为各个输出包封装(encapsulate)数据。然后包被发送到各个基于指定的目的端口的GEC或PTC块。

对于在接收数据通道上输入包，网络加速器的连接查找功能部分可包括地址形成、CAM表查找和连接表查找功能块。CAM查找地址部分形成于从输入包头中提取出的信息。被提取的头字段的详细信息依赖于使用中的业务协议。将要形成的地址只能表示唯一的连接。对于最大众化的网络业务，例如在IP V4和TCP/UDP协议中，源IP地址、目的IP地址、TCP/UDP源端口号、TCP/UDP目的端口号和协议类型(所谓的来自于包头的“五元组(five tuple)”)定义唯一的连接。如果包为不同的业务协议(如IP V6)，其他字段可用于确定连接。适当的控制，例如标识(flags)和识别码(identifying codes)可在多个协议被提供的地方被参考，使得系统作为“协议意识到的(protocol aware)”分等级系统。例如，过程可被分为三个阶段(stage)，每一阶段对应被支持的协议的一级。第一阶段，可以从头分析过程中被提取出的字段和存储在用于到达包的信息缓存器记录中的字段中，检查L3协议的版本号，作为地址形成过程中的一个步骤。在地址形成过程的第二和第三阶段，提供混合的硬件表(hardware table)。在各个阶段的表记录编号依赖于该表所处的阶段，以及每个阶段可以被支持的不同协议的编号。每个表记录通常有一个内容可寻址寄存器(CAM)记录和一个位置编号登记(position number register)组成。每个位置登记通常由一对偏移量大小(offset-size)的字段组成。每个CAM记录为相应的位置登记存储特定的协议值。该偏移量定义从包头的起始点到被提取的字段处应当被跳过(skipped)的字节数。大小字段(size field)定义被提取出的半字节(nibbles)的数目。相同的地址被用于访问CAM文件和位置登记。

对于输出包的出口，本发明使用如描述的命令文件，该命令文件可在存储器中被建立，能够被该构架中的任意一个点的中央处理器访问

本发明结合具有代表性的实施例被公开，但是应当参考权利要求而非实施例中的讨论来确定本发明要求保护的排他性的范围。

Claims (18)

1、一种流设备，用于将数据包从数据包的至少一个源端导引到数据包的至少一个目的端，包括：

网络加速器，与数据包的源端和目的端进行数据通信；

控制处理器，用于控制从源端到目的端的数据包的流的形成；

其中所述控制处理器被编程，以建立一套参数值，至少在从源端到目的端的数据包的流形成过程的预先确定的步骤的期间，所述参数值从所述控制处理器连接到所述网络加速器；以及

其中，依据所述参数值，并充分独立于所述控制处理器，所述网络加速器用于在所述预先确定的步骤后，将从源端到目的端的所述数据包形成流。

2、根据权利要求1所述的流设备，其中源端和目的端中的至少一个包括通过数据通信网络与所述控制处理器进行通信的客户端，所述源端和所述网络加速器耦合到所述数据通信网络。

3、根据权利要求1所述的流设备，其中由所述控制处理器建立的所述参数值包括用于标识通过通信网络与控制处理器和网络加速器数据通信的至少两个客户端的寻址信息。

4、根据权利要求3所述的流设备，其中所述参数值由所述控制处理器依据请求信号建立，所述请求信号由所述源端和目的端中的一个发起，至少包括用于所述源端和目的端的寻址信息。

5、根据权利要求3所述的流设备，其中所述参数值在由所述控制处理器提供的命令文件中提供，并且进一步包括一个连接到所述处理器的存储器，其包含反映多个并行流操作的命令文件。

6、根据权利要求4所述的流设备，其中所述参数值包括标识码、包计数、头块大小以及位置指针和计数值之一。

7、根据权利要求3所述的流设备，其中所述参数值由所述控制处理器依据请求信号建立，并被作为包含有用于所述数据包的标识编码的普通头，从所述控制处理器传输到所述网络加速器。

8、根据权利要求7所述的流设备，其中所述网络加速器用于包含带有传输到目的端的包的所述普通头。

9、根据权利要求8所述的流设备，其中所述网络加速器用于在将所述包形成流的过程进行时，将控制信息插入到被传输到目的端的普通头中。

10、根据权利要求9所述的流设备，其中所述网络加速器用于插入包数据计数，通过所述包数据计数所述目的端能够将接收的包排序。

11、根据权利要求1所述的流设备，其中，

所述控制处理器、源端和目的端中的至少一个和网络加速器传递显示控制消息、个人会话控制消息和实时流信息包，所述控制处理器处理控制消息，而所述网络加速器处理实时流包。

12、根据权利要求11所述的流设备，其中所述控制处理器通过由所述网络加速器通过建立步骤，来控制流的形成，包括：

设置命令，其中通信资源被分配用于流操作；

播放和记录命令中的至少一个，在至少一个所述源端和至少一个所述目的端之间的至少一个方向上开始流操作；以及

暂停和撤销命令中的至少一个，其中分别地当由于暂停命令保存所述资源分配和由于撤销命令放弃所述资源时，暂停先前开始的流操作。

13、根据权利要求12所述的流设备，其中所述控制处理器根据所述显示控制消息的实时会话控制协议，所述个人会话控制消息的实时控制协议进行操作，其中实时流包遵从使用TCP协议和UDP协议中的至少一个的RTP协议。

14、一种用于实时形成流内容的方法，包括：

提供带有相关头信息的打包的数据内容，通过所述头信息，所述打包的数据至少在源端和目的端中的一个被进行内容处理；

依据与所述源端和所述目的端中的至少一个进行数据通信的控制处理器的程序化操作，开始流操作，为流操作寻址源端和目的端中的至少一个，以及实现流操作的暂停和停止中的至少一个；

其中，根据所述程序化操作，所述控制处理器用于建立包括信息的命令文件，所述信息在流操作过程中至少被暂时维持；以及，

在开始流操作之后，通过网络加速器的操作继续流操作信息，所述网络加速器处理所述命令文件提供的信息和流操作过程中处理的信息。

15、根据权利要求14所述的方法，其中在所述流操作期间，所述网络加速器将来自命令文件的信息插入到被传输的包头中。

16、根据权利要求15所述的方法，其中所述网络加速器将寻址信息以及包数据计数和包数据指针中的至少一种插入到所述包头中。

17、根据权利要求16所述的方法，其中包括：在所述流操作开始之后，通过控制处理器的程序化操作改变流操作。

18、根据权利要求14所述的方法，其中包括：通过控制处理器建立和维持多个命令文件，每个命令文件涉及到至少一个并行运行的流操作。

Images