CN101352012A - 使用不同元件对流进行媒体数据处理以及控制方法 - Google Patents

使用不同元件对流进行媒体数据处理以及控制方法 Download PDF

Info

Publication number
CN101352012A
CN101352012A CNA2006800457326A CN200680045732A CN101352012A CN 101352012 A CN101352012 A CN 101352012A CN A2006800457326 A CNA2006800457326 A CN A2006800457326A CN 200680045732 A CN200680045732 A CN 200680045732A CN 101352012 A CN101352012 A CN 101352012A
Authority
CN
China
Prior art keywords
stream
bag
data
content
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CNA2006800457326A
Other languages
English (en)
Inventor
阿姆巴拉瓦尼尔·阿尔乌拉姆巴拉姆
陈建国
哈肯·I·派堪
肯特·E·威尔斯
纳文·C·海因策
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Agere Systems LLC
Original Assignee
Agere Systems LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Agere Systems LLC filed Critical Agere Systems LLC
Publication of CN101352012A publication Critical patent/CN101352012A/zh
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

硬件被加速流装置,特别地用于RTP实时协议流,使用编址寻址和处理标准,指引在源端和目的端之间的一个或多个流的数据包,该寻址和处理标准部分地由控制包确定,用于改变或补充与流内容包相关的头。可编程控制处理器响应RTCP或RTSP格式的控制包,由此,RTP包的指引和处理可以被改变。该控制处理器为存储器中的新的编址和处理标准存储数据,被存储的数据可被硬件加速器访问,同时,该硬件加速器被安排存储用于多个正在进行的流的标准。当接收到一内容包,通过网络加速器的动作,它的编址和处理标准可以在存储器中被发现并被应用,而无需控制处理器的计算。当流继续时,网络加速器反复的工作,以继续将该标准应用到给定流的包,并可以以很高的数据速率传递途径(date rate pipeline)工作。处理器可以被编程,用于以通用的方式修正该标准,包括:如果必要的话,使用大量的计算,因为解除了该处理器反复的处理工作,这些工作被网络加速器完成。

Description

使用不同元件对流进行媒体数据处理以及控制方法
相关申请的交叉引用
本申请要求于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)流的应用中。一般地,本发明还应用于包数据传输应用,其中源端和目的端之间的传输耦合是根据控制处理器的程序设计来开始、停止或者有时改变的。
背景技术
本发明的装置和方法适用于各种录音(recording)、重放(playback)和处理功能,其中,内容和控制信息引自用于存储、显示或处理数据的功能性元件,或者指向用于存储、显示或处理数据的功能性元件。根据本发明的一方面,重复的数据处理传输功能关于数据率是特别苛求的,但是计算起来并不复杂,例如,数据包的重复路由到附加存储元件的网络,或数据包的重复路由自附加存储元件的网络,重复的数据处理传输功能是与那种计算起来很复杂但是相对来说不太频繁的功能分开处理的,例如,控制处理和编址步骤(addressing steps)。在较佳的装置(arrangement)中,包含硬件设备(device)的加速器在与控制处理器和带有数据存储设备的网络的数据通信中提供的。这些加速器充分专注于传输功能,因此,当根据程序设计释放处理器以处理控制功能时,可以达到很高的数据吞吐率,这些程序设计以通用地并最优地方式可以响应改变请求。
通常,使利用可能(potentially)不同数据格式的可能(potentially)不同设备能够互相作用是有利的。在以高数据率调节不同的设备和不同的数据格式的同时,提供数据处理系统的多功能性的需要使得设计难度提升了。
工业标准规定某些数据类型的格式。标准影响编址和传输信号技术、数据存储和检索(retrieval)、通信等。代表性地,标准在多个层次上应用。例如,当根据视频编码标准传输编码的视频数据时,包传输信号标准或协议是可以适用的,等等。
在源端和目的端之间传输的包数据有利地须经中间处理步骤,例如,数据格式转换、计算、缓存以及类似的处理和/或存储步骤。在具有多个服务器和终端设备的数据处理系统中,一部分计算负荷指向与数据格式化和重格式化相关的动作。一部分负荷在数据源端和目的端之间编址和切换,响应如用户选择的条件,还可能改变装置。
一些可应用的数据处理和通信功能是重复性的操作,其中连续的数据包被以大致相同的方式处理,用于源端到目的端的传输。这些功能能够从有效率的(streamlining)和简单化中使数据管道配置获益,以最大化速度。
其他数据处理和通信功能可能更具管理性和计算密集性。例如,当重新配置数据流路径来增加、移除或者在源端和目的端节点之间切换,或者在功能间进行改变时,除了一个包接着一个包的重复调整地址等等步骤之外,控制处理器可以被编程以调用各种其他步骤。这些功能能够从通用性中获益,然而,那也意味着程序设计和计算的复杂性。
与提供的计算的复杂性相对,为了速度有效率的和简单化的目的与设计目的显然是不一致的。与计算能力的需求相对,使速度和数据容量的一致的需求最优化是有利的,以致提供既快速又通用的装置。本发明将数据传输所需的某些功能再分进分组中。相对简单的高速度和典型的重复性功能被分配到加速器元件,该加速器元件可以完全或部分地在硬件中实现,例如,硬件网络加速器。相对复杂和适用于计算的功能被分配到控制处理器中,并且主要地通过软件来实现。在它的功能中,控制处理器设置并存储条件和要素到硬件网络加速器中,如在涉及到连续包的传输的特定操作中,被重复用到的编址信息。
在一个较佳的实施例中,本发明是关于实时传输协议(Real TimeProtocol,简称RTP)信息包流进行阐述的。讨论了一组代表性的信息包的源端和目的端类型,可以应用到视频数据处理,视频数据处理用于娱乐或电话会议,但可能包括安全监控、游戏系统以及其他应用。传输路径可以是有线的或无线的,并且可能涉及到企业或公共网络。用于重放的终端可以包括音频和视频娱乐系统、计算机工作站、固定的或便携式设备。数据可以使用网络服务器被存储和处理。代表性的通信系统包括局域网和广域网、电缆以及电信公司的网络等。
与音频和视频数据有关,实时传输协议(“RTP”,也称为Real TimeTransport Protocol)是一个标准协议,适用于将打包后的音频和/或图片以及图片数据,以实时数据速率在数据通信网络中进行移动。音频和视频数据以实时速率或实况速率(live rate)的重放是为了将对存储缓存区的需求减到最少,而避免内容的停止或开始。在如电话会议或类似的通信应用中,打包后的数据的收集、处理、传输以及读取,有利地应当很少有明显的延时,并且没有空白发生,应当与面对面的实时会议和谈话相一致。
RTP实时传输协议是已知的协议,意谓着使实时数据以有效率的方式的处理容易,实时数据包括音频和视频。该协议可用于媒体点播(media-on-demand),也可以用于交互式服务,例如网络电话。该协议可用于将音频和视频从多个源端和目的端导出,或者将音频和视频导入多个源端目的端,以使得结合并行的处理能够进行显示和/或记录。
使用控制和编址功能,处理数据的方式是可不断地改变的,例如,发起和终止涉及到特定的源端、目的端或者参与端的连接。如此,RTP包含用于内容传输的数据内容部分,以及用于改变数据处理方式的控制部分,包括开始、停止和编址。RTP的控制部分叫做实时控制协议(Real Time ControlProtocol,简称RTCP)。
RTP的数据部分是一个薄的(thin)或者有效率的协议,提供对具有实时特性的应用的支持,例如,连续媒体(例如音频和视频)的传输。这种支持包括:时序重构(timing reconstruction)、损失检测或恢复(lossdetection or recovery)、安全(security)、内容标识(contentidentification)以及与媒体内容的传输重复的,并且连续不断地大量地发生的类似的功能。
在如英特网的通信网络中,RTCP为任意大小的群组的实时会议提供支持。这种支持包括:源识别(source identification),以及对诸如音频和视频桥(bridge)之类的网关以及多播到单播(multicast-to-unicast)的转换器的支持。既提供从接收器到多播组的业务质量反馈,又对不同媒体流的同步提供支持。
RTP和RTCP是专门用来促进上述讨论过的类型的数据传输的数据协议,但是在特定的网络架构中,RTP和RTCP协议可能与更高层次或更低层次的协议和标准结合。在较高的层次上,例如,RTP和RTCP协议可以用于服务视频会议系统或观看-存储(view-and-store)或用于处理数据的其他技术。在较低或者更为基础的层次上,在RTP和RTCP数据传输中使用的包实际上可以根据不同的包传输消息协议来传输。例如,传输控制协议(TransmissionControl Protocol,简称TCP,TCP或者在因特网中,简称TCP/IP)和用户数据报文协议(User Datagram Protocol,简称UDP)。
TCP和UDP协议都是用于包传输的协议,但是就包完整性(Packetintegrity)和错误检测、对丢失包的灵敏度以及其他方面而论,二者具有截然不同的特性。TCP通常使用协议的方面以帮助确保在传输中一种双向(twoway)连接得到保持,并且该连接能够一直保持到所有相关的包都被传输到接收端并在接收端被组合,可能地,包括不断尝试获取丢失的包或被损坏的包。UDP通常处理包传输尝试(attempts),但是,可用于发送和接收包的应用来保证所有必要的包都被发送和接收。一些应用,例如,电话会议图像流,对于间歇地丢失的包并不是非常敏感。但是,如果包本应被丢失,那么流尽可能无缝的连续是有利的。
如果设计出技术方案,其中利用宽范围的较高层次和较低层次的协议,实时传输是可行的,同时允许配置以充分利用不同协议的不同方式,那么是有利的。在高性能或高要求的系统中适合操作是特别有用的,这样,用于通信的资源、用于计算的资源以及情况敏感的切换以及决策制定可以得到优化。
发明内容
本发明的一方面在于通过采用具有分立的并同步操作的传输数据的路径和控制数据的路径的数据处理装置,提供高效率的视频和类似的连续流数据处理,其中,使用分立的协同操作的资源,两个数据路径分别处理数据吞吐集中的功能和数据处理集中的功能,这些协同操作的资源分别用于吞吐和处理能力。
特别地,提供了一种方法和装置,通过区分与实时传输协议结合的某些资源-集中处理(resource-intensive processes)的子集,用来促进和加速由媒体服务器处理的过程;用于通过为了它们分配的子集被优化过的处理器和切换装置处理。基于速度的功能划分被分配到具备数据传递途径特性的设备。计算负荷分配到一个或多个中央处理器完成,该中央处理器以对于移动在数据通信传递途径中的流数据,处理器给予很少的关注,来处理计算的方面以及管理RTP会话。
在某些实施例中,方法涉及到使用一个硬件接口元件重复的替换在被选择的包中找到的头数据,该被选择的包是在中央处理器的控制下被发送和接收的。该中央处理器可以建立标准,例如安排具有某种标识属性的包以某种方式进行处理,例如被路由到特定的地址。这个标准存储在该中央处理器中,以控制硬件接口元件。硬件元件将结果强加于传输数据中,包括用替换的头数据值发现每个携带接收到的数据的连续的包头,该接收的数据从源自该控制处理器的数据读出或生成。
该硬件接口元件可以以高数据速率运行而无需实质的监控,从而控制RTP包的流向目的端和源端或自目的端和源端发送的RTP包的流,如视听显示设备和带有存储设备的网络。通过这种方式硬件接口元件加速数据的处理,并且将控制处理器从关注比将某一头值用定义的替换值进行IF/THEN替换更加计算量集中的功能中解脱出来,目前该关注的功能由硬件加速器来完成。
在基于可编址数据包的传输的数据流通信装置中,不管该装置是否涉及局域网或广域网,携带与重复的流功能相关的数据包的相同的数据路径,也携带与管理数据流需要的计算指令功能相关的控制和编址包。根据本发明的一个方面,一个内容可寻址存储器(Content Addressable Memory,简称CAM)文件可以被维持,由此,硬件加速器将多个当前被维持的包队列与某些地址结合来。当接收到SETUP请求来发起一个到新的终点的流连接时,在该CAM文件中找不到匹配的项(entry)。该硬件加速器具有相关的头值,即以在CAM中发起一个项的方式期待RECORD或SEND消息。控制处理器可以获知与新的终点相关的头值,但是该处理器仅需要通过在CAM中设置新的包队列来建立到新的终点的路由。然后,该硬件加速器可以像一个自动装置那样工作,找到输入包的包队列项(entry),替换必要的值,并且将该包向着它的目的端传递。
当具有已建立的队列项的RTSP的RECORD或SEND消息被收到时,在与流量管理器和中央处理器的数据通信中,确定输出头值的任务在硬件加速器中进行。这个连接可以在进行中保持,并且受益于高数据速率,一直到完成或者一直到中央处理器实行必要的新的控制和动作,例如根据任意一个可编程功能确定终点或流的终点。这种功能可以包括许多或所有的功能,不然,这些功能需要一个控制器通过可编程的软件程序来决定如何处理每一个传输包。这种功能可以包括源端和目的端之间的包的路由,插入中间的处理步骤,包同时路由到两个或更多个目的端,例如在播放的同时记录,等等。
将特定的头值用存储的值代替的CAM技术相对来说是机械的,可以很快地被完成。一些RTP控制功能,例如RTP终止程序,可能稍微复杂并且在硬件中不能最佳地被处理,例如,由于涉及到多个包并且不是一对一的交换,或者可能因为涉及到比基于存储值的IF/THEN替换更复杂的条件步骤。
另一方面,流吞吐的要求可能是严格的。为了满足以传统的方式吞吐,需要一个很快速并且有能力的中央处理器,在空闲时卸下计算负荷也卸下头值替换。在中央处理器提供替换值和标准之后,采用硬件加速器来处理头值替换是发明的方面。
一旦建立包队列项,流上的每一个包最初被应用到网络加速器中,例如在硬件中充分实现的高速单元。该加速器将包与CAM连接表中的信息相匹配,去掉层三和层四头(例如),插入新的本地头。当前包含一个可能被改变的本地头、RTP头和RTP有效载荷的包,通过流量管理器发送到它的目的端,例如在RECORD操作中被写入到被编写了地址的磁盘中,在PLAY操作中被发送到显示设备或一些其他地址,一次进行两个或多个这样的操作,等等。
本发明的方法的一个优点是输入的RTP流量可以被处理,并能最终通过软件被控制。如果新的不同的RTP有效载荷类型应该成为普遍的或者如果已知的有效载荷类型的定义应当改变,对于它们的支持可以通过流装置(streamer)来保持。另外,在存储时视图延迟(delayed-view-while-recording)的个人视频存储(Personal VideoRecording,简称PVR)中,被高度期待的功能可以得到有效的支持。
本发明技术的一个优点在于存储在RTP本地头格式中的对象可以使该对象对于HTTP传输器来说不可访问,或者在一些情况下,可能需要一些操作来取消该效果。然而,在主机处理器上的适合的软件程序可以被用于重新组织原始媒体对象,即时地或者在将来某一时候,当资源可用和/或对该对象的需求上升时,为了使该对象对于非RTP客户端来说立即可用。
上述这些或其他的目的和方面在以下的优选的实施方式和例子讨论中会变得清晰。
附图说明
在附图中示出了作为目前优选的本发明的某些代表性的和非限制性的实施例。为了确定本发明的排他性权利被声明的范围,对于附加的权利要求,应当做出参考。在附图中,
图1所示为本发明源端到目的端的数据传输关系(例如,服务器到客户端)的结构图,其中RTP数据内容组分围绕一控制点路由,例如处理RTSP和/或RTCP控制信号的中央处理器;
图2所示为本发明流控制器的结构图;
图3所示为RTP头中各组分的值的表格;
图4所示为说明用本地地址头预先添加RTP头的数据表格图;
图5所示为,在使用内容可寻址存储器来重复地应用最初从中央处理器获得的值中,涉及到的数据流和数据组分的结构图;
图6所示为通过设置执行的和携带在数据流连接上的功能的逻辑流程图;
图7所示为娱乐系统“HNAS”的组分结构图,该娱乐系统“HNAS”有利地被配置为包括本发明的包数据处理规定;
图8所示为当具有不同偏移量的协议被连接在一起时,可以应用的头偏移量的增加,以及鉴于该偏移量,确定包地址的方法的示意图;
图9所示为根据优选装置的内容可寻址存储器元件的级联(cascading)的逻辑图;
图10所示为本发明通过操作应用到数据包的本地头的布局的数据表格图。
具体实施方式
实时传输协议(Real Time Protocol,简称RTP)提供端到端的网络传输功能,适用于传输实时数据的应用,例如多播或单播网络业务中的音频、视频或类似的数据。
RTP并不进行资源预留,也不保证实时业务的业务质量,例如确保在RTP协议层次上连接可以被保持,以及包不会丢失等等。数据传输协议,即RTP,由控制协议(RTCP)进行了扩大,RTCP协议可被用于会话控制(即RTP从源端传输到目的端),也可以被用于整体的显示控制协议(RTSP)。
RTCP和RTSP控制协议涉及被传输的信号包,例如,当建立或拆除一个传输路径时,当在一个方向(PLAY)或另一个方向(RECORD)发起一个传输时,当暂停时等。内容数据包需要形成流,从而尽可能持续地与一些同步的参考保持实时。内容包与RTCP包和RTSP包同时被传输,但是这三种单独的协议的包使用不同的编址逻辑连接或套接字(sockets)。
RTCP/RTSP控制协议和RTP数据流协议共同提供可升级到大的多播网络的工具。RTP和RTCP设计为不依赖于基本的传输层和网络层,从而可以被用于各种可选择的层。协议也支持其中期望的RTP级的转换器和混合器的使用。
RTP控制协议(RTCP)具有监视业务质量的能力以及传达正在进行的会议中的参与方信息的能力。参与方信息对于“宽松控制”(“looselycontrolled”)的会话是足够的,例如,在没有清楚的成员关系控制以及设置,但是给定的应用可以有更多的需要的权限或通信要求的地方,这是一般地RTSP会话控制协议的范围。
在源端和目的端之间流动的RTP数据内容包实际上简单地沿着朝向目的端地址的方向实时传递。鉴于包是被实时传递的,在接收装置中的缓存器是没有必要的。基于同样的理由,典型地,在发送装置中也不需要创建临时文件。不像其他协议,例如HTTP对象传输,RTP将对象用特定媒体(media-specific)头打成包。RTP接收器用于恢复丢失包,而不具有重试信号能力。RTP传输可以采用TCP/IP无连接协议。典型地,RTP传输是通过对RTP数据的用户数据报文协议(User Datagram Protocol,简称UDP)包传输来完成的,典型地但是没有必要地,用一个UDP包组成一个RTP包。
一个RTP包具有一个固定的用于标识该包是RTP的头、一个包序列号(packet sequence number)、一个时间戳(timestamp)、一个同步(synchronization)源标识、一个起作用的源标识符(source identifier)的可能的空列表以及有效载荷数据(payload data)。该有效载荷数据包含给定数量的数据值,例如音频样本或压缩视频数据。
使用与控制包(RTCP)和/或会话控制包(RTSP)相对的不同的实时数据内容包(RTP)的系统的一个方面是,所有这三种类型或包通过相同的数据路径被发送和接收,但是具有截然不同的频率和功能。这样就有可能提供在接收器中的处理器,例如连接到娱乐系统的网络、视频会议系统以及附加存储设备及类似设备的网络,并且有可能对该处理器编程从而适当地区分RTP包和RTCP或RTSP控制包。数据包被向着它们的目的端传递,并且处理器使用控制包来影响其他的可编程功能和信息的传递。对于这样的系统保持步调一致,中央处理器必须以高数据速率运行,这样以致实时传递RTP数据包。该处理器还必须具有处理可能会涉及的控制过程所需要的计算复杂度和程序设计。该处理器必须快速而且有能力,但是当简单传递RTP包时,没有使用该处理器的计算复杂度,并且对于处理控制计算,该处理器的高数据速率也是非必要的,相对来说这些是并不频繁的。
本发明的一个方面在于为RTP数据和信号数据提供不同的数据路径,这样中央处理器(或处理器)的计算能力就不是来自于处理RTP数据的路由传递(对于特殊情况下的会议处理处理传输RTP数据的路由是没有的),而是大体上从RTP会话的稳定状态的处理中被分离。由于通过使用用于处理数据流的硬件切换装置和中央处理器在较高和/或较低的应用层处理多种支持的协议的复杂性能够达到的性能的优点,这种划分是有益的,例如,不同的输入和输出协议、设备、地址和功能。
如图1所示为带有一个设置在服务器(即流数据的源端)和客户端(即目的端)之间的控制点的简单的网络环境。每一个交互连接都用各种能够被支持的RTP流的包的类型标注。通过提供一种技术,使用描述过的硬件加速器借以替换消息头中的字段,本发明的目的是广泛被应用到涉及到控制点的配置中,并且至少部分地绕开在控制点进行处理的需求。
图2所示为一可实施的情况,其中控制点由中央处理器来表示,该中央处理器通过网络连接到一个包源端(图中所示为服务器)。在所示的配置中,中央处理器通常会被要求将包传递到一个或多个目的端,例如,通过一个流量管理器/仲裁器(traffic manager/arbiter),通过将在包流中被标识的包从一个包源端指引到一个或多个可寻址的目的端,例如带有存储元件的网络,在本实施例中通过磁盘存储器及其控制器来表示,或者表示为读出装置(readout device)等。
根据本发明的一个方面,首先包数据被网络加速器形式的接口装置处理。该网络加速器可以具体化为一个即使要计算的,复杂性也最小的高吞吐率设备,用于替换在输入流的RTP包中的头值,从而控制它们的处理。特别地,这些值被控制器设置到网络加速器的内容可寻址存储器中。例如,这些值可以是带有本地地址值的头值的直接替换,本地地址值路由包到存储装置或读出装置或其他本地目的端。可选地,硬件加速器可以被控制器指引,从而以某些其他方式路由包,例如将相同内容的两个或多个复本指引到两个目的端,有效地分开了信号路径。
为了这个目的,硬件加速器的内容可寻址存储器包括被加载一系列地址、头值、标志及类似的内容的表格,与流处理被发起时的特定的流相对应。当附加的包实时到达时,硬件加速器通过定位相关流中的表格项(entry)访问内容可寻址存储器中的相应信息,并将包中的头值用从加载在内容可寻址存储器中的值找到的或产生的头值替换。在内容可寻址存储器中的值的至少一个子集的值是由控制处理器产生的,例如执行用户命令。在内容可寻址存储器中的值的一个子集可选地可通过独立于控制处理器的硬件处理器的操作产生。例如,硬件处理器可以包括一个计数器或一个加法器,可以将一系列的数相加或在某些情况下,调整时间戳信息,这样以恢复UDP包的丢失或在切换功能中实现平滑传输,等等。
在本例中,特定的源端和目的端的实体是代表性的例子。本发明应用于涉及多种可能的源端和可能的目的端的情况,这些源端和目的端或多或少是最接近的或是在末梢的,并且如所示的接入数据通信,这样以在一个给定时间运行,作为数据包的源端或目的端在两个这样的实体中在一个或另一个或两个方向上传输包。在内容信号要在重放装置上显示并同时存储的情况下,这个特定的例子可能安排用于包的通路。在其他例子中,数据流装置可能被设置成数据被存储但是不被回放或被回放但不被存储。其他特定的源端和目的端元件也可以被涉及到。相同的输入包可以从一个源端被路由到两个或多个目的端。可选地,来自于两个或多个源端的内容可以被指定用于协同的存储或重放,例如,作为画中画(picture-in-picture)插入或者为了同时并列地播放,例如当电话会议时。根据本发明,这些或其他类似的应用是容易做得到的。
数据流分为三种主要的类型,即用于整体显示控制的RTSP包;用于单独会话控制的RTCP包;以及用于数据内容传输的RTP包。
RTSP是一个应用层协议,用于控制一个或多个并行的显示或数据传输。单个的RTSP连接可以并行地和/或连续地控制几个RTP对象传输。在一个视频会议装置中,例如涉及到多个位置,在每一对位置之间都可能安排双向传输。RTSP的语法与HTTP/1.1的语法类似,但是它为媒体传输提供协定细节(convention specific)。定义会话的主要的RTSP命令是:
Figure A20068004573200171
SETUP:促使服务器为流分配源端,并开始RTSP会话。
Figure A20068004573200172
PLAY和RECORD:开始通过SETUP分配的从源端到目的端的流上的数据传输。
PAUSE:暂时停止流而无需释放服务器资源。
TEARDOWN:释放与流相关的资源。该RTSP会话停止存在在该服务器上。
当控制点使用RTSP的SETUP请求来请求对象传输时,它发送请求到服务器和客户端,该请求包括对象传输的细节,对象传输的细节包括对象标识,源端和目的端IP地址以及协议端口,以及传输级协议(主要是RTP,和TCP或UDP),将被使用。这样,RTSP请求向客户端和服务器描述该会话。在一些情况下,该请求尤其可以用于有用的对象的子集,例如对象的音频或视频组分。
当所有必要的SETUP请求被使用并且被应答时,控制点可以根据传输的方向,发起PLAY或RECORD请求。该请求可选地指定待传输对象的确定范围、对象的正常播放时间、以及在重放应当开始时的当地时间。
随着重放的完成,显示自动被暂停,仿佛PAUSE命令已经被发起了一样。当PAUSE命令被发出时,它指定时间戳,在该时间戳流应当被暂停,并且服务器(客户端)停止发送数据直到后续的PLAY(RECORD)请求被发出。
当TEARDOWN请求被发出时,在指定流上的数据传输被停止,并且所有相关的会话资源被释放。
RTSP命令可以指定一个不同频道信号传输(out-of-band transfer)会话,其中RTP/UDP或RTP/TCP被用于传输。一个“不同频道信号”传输指引两个或多个不同的传输或连接路径。如果是那样的话,RTSP流量可以是通过一个连接,并且不同连接可以通过RTSP指定来携带RTP数据的实际传输。
RTP包可以通过TCP传输。这常常是效率不高的,因为UDP传输不需要一个持续的连接,对于丢包不敏感,和/或不会如同TCP一样尝试检测或恢复丢失的包。UDP传输协议适用于包的实时传输,例如音频或视频数据样本值。这些值并不是特别至关紧要,但是需要以高的数据容量传输。TCP与UDP的不同在于,一旦建立连接,该协议要强调可靠性,例如,通过获得重传输(retransmission)来寻求恢复丢失的包,等等。这些方面UDP要与RTP的要求更加一致。这一公开的事实通常假设UDP将被应用于RTP传输中。然而,这一公开的事实不应当被认为是对较优的UDP传输的限制,而是还包含另外的协议,如TCP。
当服务器接收到一个使用RTP的待传输的对象的请求时,该对象典型地被从它的原始格式转换成打包后的格式。许多“需求注释(Request ForComment,简称RFC)”消息线程在业界被开发用于解决与如提到的打包数据相关的问题,这些线程主张用于在线访问,例如,通过互联网工程任务组(Internet Engineering Task Force,简称IETF),包括用于各种给定媒体类型的相关RFC。
根据相关的RFC提供的标准规定,每一个媒体对象类型被典型地打包,多少有些不同,甚至在类型之间会有不同的头格式。这些不同是由于不同的对象和处理数据中遇到的事情具有不同用途造成的。
如图3所示为通常的RTP头的格式,例如RFC3550/3551中的记载。头字段的缩写词如下:
“V”代表版本号。当前的版本是版本二。尽管在头内部没有独一无二的标识来标明该包是RTP格式,但是在头位置中出现了版本号“2”就是一个标识符。
“P”是一个值,用于说明在有效载荷的末端是否存在应当被忽略的填充符(padding),如果存在,就是填充符的范围。填充符值的最后一个字节给出了填充符字节的总数目。
“X”是一个值,用于说明是否存在一个扩展头(extension header)。
“CC”是在这个头中被标识的起作用的源的计数。
“M”是标记比特,实现这个标记比特是用于指定有效载荷的类型。
“PT”标识有效载荷的类型,即被传输的对象的类型。在其他情况中,有效载荷类型标识符可以使接收器确定如何终止RTP流。
“序列号”(Sequence Number)是被传输的RTP包的数量的计数。应当注意的是,这是不同与TCP的,TCP使用一个序列号来指引被传输的比特数的数量。RTP序列号是被传输的RTP包的数量,例如包索引。
“时间戳”(Timestamp)是一个依赖于有效载荷类型的字段。典型地,该时间戳为被发送的包提供时间索引,在一些情况中,提供允许接收器适应记录包内容或重放包内容的时间条件的参考。
“SSRC ID”标识被传输数据的源端。
“CSRC ID”标识任何有贡献(contributing)的源端或具有已处理当前被传输数据的源端,例如,混合器、转换器等。可以有许多有贡献的源端,或者可能除在SSRC ID中标识的初始源端外什么都没有。如同所述,头中CC的值提供一个有贡献的源端的计数。这个计数允许有贡献的源端标识的模糊的数量也可这样被处理,并且为紧接着头的内容向前做索引
如果X比特被设置,会有跟随RTP头的扩展头。该扩展头的使用和性质依赖于有效载荷的类型。有效载荷特定子头通常以允许包丢失被改善的方式被指定,这样以可容忍一直到发生的事件的某一频率。对于一些格式,例如MPEG2,许多带有视频和音频编码信息的复杂的子头可能跟着主RTP头。
有效载荷跟在包中最后一个子头之后,如图3所示。有效载荷与原始媒体对象关系是由描述了相应有效载荷类型的标准来确定的。在原始对象和RTP包有效载荷的串联之间经常没有一对一的对应关系。尽管可能由多种因素会导致这种情况,但是在一些情况的例子中,RTP包有效载荷序列和包含在原始对象中的比特序列之间的潜在的不同可能由于:
●为给定帧同步视频和音频信息的需求;
●RTP有效载荷内部数据块交叉存取;
●关键数据单元的重复的数据包;
●音频/视频信号分离(demuxing);
●或者1.1.3RTCP。
周期性地,当一个给定RTP会话处于活动状态时,与该会话相关的控制信息是在使用RTCP的单独的连接上被交换的(对于UDP,RTP会话使用偶数的目的端端口,以及RTCP信息通过下一个更高的奇数的目的端端口传输)。RTCP执行各种功能,包括有提供关于数据分布质量的反馈,这对于服务器确定网络问题是本地的还是全球的是有用的,特别是在IP多播传输的情况中。RTCP也行使功能以携带用于RTP源端的持续的传输级标识符,即别名记录(CNAME)。由于冲突或程序重启可能导致SSRC ID的移动,接收器需要CNAME来明确每一个参与方。CNAME也可能被用于同步来自各种RTP会话的多个相关流(例如,同步视频和音频)。
在一个传输中所有的参与方都需要发送RTCP包。当会议中参与方的数量上升时,每一个发送方发送的包的数量有利地按比例减少。通过让每一个参与方发送他的RTCP包给所有其他方,每一个参与方能明确参与方数量。这个数量用于轮流计算控制包被发送的比率。RTCP可以被用于传输最少的会话控制信息,例如在用户界面中被显示的参与方信息。
为了完成这些任务,RTCP包可以分成以下范畴和格式中的一种:
●SR:-发送器报告,用于传输和接收来自参与方的统计,该参与方是活动的发送器;
●RR:-接收器报告,用于接收来自参与方的统计,该参与方是不活动的发送器,结合SR为活动的发送器就多于31个源端做报告;
●SDES:-源端描述项,包括CNAME;
●BYE:-表示参与结束;以及,
●PP:-特定的应用(application-specific)功能。
与RTP一样,RTCP包的每一种格式以普通的头开始,跟着不同长度的子头。多个RTCP包可以被连接形成一个复合RTCP包,可以在底层协议的单个包中将该复合包一起发送。
本发明的一个方面在于通过提供混合的硬件和软件的解决方案来代替仅硬件的解决方案或仅软件的解决方案,来改进整体的RTSP/RTP解决方案的执行。任何全硬件的解决方案如果为所有控制情况方案提供,那么它必须相当复杂。相反地,任何具备处理器和处理这种复杂情况的编码能力的仅软件的解决方案还没有被完全开发。对于在过程中的给定流之后的大多数操作,许多用于为给定流按照与之前的包相同的方式持续的处理连续包的操作被使用重复的操作处理,并且不需要计算的能力。
根据本发明的一个有利的实施例,提供了一个混合的解决方案,其中控制处理大部分被一个控制器来设置和安排,该控制器运行可能的复杂和可行的软件程序。然而,专门的硬件使用媒体对象和由软件生成的支持文件来加速传输。
由于它们各自的复杂性和操作的不频繁性,与控制步骤有很大关系的RTSP和RTCP功能,可以由中央处理器上的软件实现而不会使其负荷太重。另一方面,RTP需要对媒体流中输入和输出的包顺次或几乎顺次地以实时的数据率进行处理,并且根据本发明从硬件加速中获益。
此处描述一个用于实现流功能性的特定的子集的操作的例子,即采用带有RTP内容的硬件卸载(offload)的RTSP/RTP。这个功能性通常在个人视频录像机(Personal Video Recorder,简称PVR)中被发现,可以被描述为从端点接受RTP封装的数据的输入流,并且立即或者任意一段时间以后将相同的RTP封装的数据发送到相同的或不同的端点。这一功能的特征是,端点可以是暂时的,并且可以改变或被切换,例如,根据用户的选择。端点的特定性质对于如描述的本发明的操作并非至关紧要的。端点可以是一个初始播放装置或者是最终播放装置,例如视频相机和重放接收器,或者一个中间元件,如压缩/解压缩或格式转换装置,或者是这些和其他元件的任意组合,其他元件是指在流中包数据信号可能会被指引向或指引自的元件。
如图2所示,媒体流装置(streamer)包括三个主要的架构实体,即中央处理器、传输管理器/仲裁器以及网络协议或硬件加速器。这些结构在他们的物理实施例中可以改变,并且与控制处理相比在电路上或多或少的会复杂。由于电路可以这样实施,其中特定的操作元件或多或少是硬线的(hardwired),根据本发明,这类元件的某些功能在这里被定义为适用于RTSP/RTP流量的处理。
中央处理器控制系统进程。网络协议加速器或“硬件加速器”处理资源密集型但可能重复的或反复的进程任务。这种方式中,加速器减轻了中央处理器的高频率低复杂度的操作。基于输入的RTP包头(如图3所示)提供的部分信息,以及当建立流时,控制器39设置的值提供的部分信息,如图4所示的本地头可以悬在包22(图4所示)的RTP头之前。这样数据流处理就如图5中的框图所示,用内容可寻址存储器替换程序影响的本地被编址的头字段(header fields),无需将每一个包通过控制器39传递。
至少对于那些当前正在进行中的流来说,网络硬件加速器包括内容可寻址存储器(CAM)或在该存储器中交叉引用的值的表格。该内容可寻址存储器存储硬件加速的连接的连接参数,包括总体上可能使用该装置的连接的至少一个子集。硬件加速器包括电路,充分的用于确定输入包是否与已经在消息队列信息中建立的流相关,该消息队列信息存储在内容可寻址存储器中。如果消息队列项存在,那么硬件加速器以通过该消息队列项已经确定的方式处理输入包。如果包没有存在的项,那么如果该包将成为被加速的流的一部分,硬件加速器听从中央处理器来建立新的消息队列项。处理包的方式可以包括用本地地址替换包头值,修正包头值以解决特定情况,改变与不同级别的协议相关的值,等等。
流量管理器/仲裁器用于提供内存和磁盘访问仲裁,还管理输入和输出网络的流量。它管理多个队列,这些队列被指引用于各种硬件加速的连接和中央处理器的输入和输出。
本发明的方法以如图4和图6所示的数据流程图来描述。媒体流装置从端点接收RTP包的流,该装置必须被实现,这样可以以高效率和高速度处理数据从而与实时包保持一致,且有足够的适应性灵活性与数据处理要求中的变化保持一致,例如调用或终止新的源端/目的端与端点或中间元件之间的关系,这可能涉及到大量的RTP有效载荷类型、源端和目的端的自动改变。
RTSP和RTCP操作很少发生,以致它们可以在运行在中央处理器上的软件中有效地实现,且执行程序可以复杂,而不会有典型的与数据内容保持一致引起的问题。因此,这些功能可以较佳地在中央处理器上运行的软件中实现。
另一方面,RTP固态流涉及重复的包处理,例如将流中所有的包指引到特定目的端,当流活动的时候,该目的端可能被临时指定。该功能在网络加速器和流量管理器/仲裁器中专门的硬件中处理。
然而,多于一个的流可能同时处于活动状态。为了以一致的方式对于给定流处理包,内容可寻址存储器包含一套适用于该流的值,例如,目的端地址、最近的包的序列号等等。硬件处理器可以包含寄存器,用于存储经由内容可寻址存储器引用的流标识信息到相关的包数据值。通过比较处理(可涉及选通(gating)或样本计算),硬件加速器将输入包上的标识信息匹配到内容可寻址存储器中的项,以及将用在被匹配的包的信息选通到输出。这个处理被用于,例如用从与该包相关的流的内容可寻址存储器中读出的本地地址信息替换包头中的数据值,如替换头地址信息。
值的替换是一个简单的重复的处理,大体上如图6的流程图所示。如果在当前流的一部分遇到下一个包,则它具有一队列项。流标识信息(例如地址信息)被匹配到一个在队列中的项,即在内容可寻址存储器中。如果没有发现项,处理器发信号,并且由该处理器可以建立项,该处理器被编程用于确定适当的队列项值并将其存储在硬件加速器的内容可寻址存储器中(处理器的功能在一个虚线框里显示)。在连续的进一步的处理中,硬件加速器为下一个接收到的包确定项,用来自内容可寻址存储器的值替换原始的头值,并且一直持续到流的末端,于是,在内容可寻址存储器中退出(retire)那个流的队列项。流装置预备使用资源支持新的连接,因此被释放。
中央处理器处理的软件进程包括通过应用程序接口(ApplicationProgram Interface,简称API)与硬件元件的接口连接,该API可以发起、终止以及在特定操作之间切换,例如处理用户输入选择。API使得中央处理器和硬件组件(例如读和写寄存器,访问硬件队列)之间的直接接口变得模糊。
在一个较佳例子中,个人视频录像机(PVR)装置的功能可以通过如下方式来实现,应当理解的是这种描述涉及到非限制性实例。
在中央处理器的程序设计中运行的RTSP功能,监视待接收的SETUP命令,以及可以是包数据的源端或目的端的端点。包括RTSP-SETUP请求的包被网络加速器接收,其中被标识的流与CAM查找表中的项不相匹配。网络加速器指定他们到合适的流量管理器队列(与中央处理器的输入流量相关的队列)。一旦RTSP进程接收到完全的SETUP消息,CAM查找表参数(源端和目的端的IP地址和端口,以及传输协议)根据SETUP消息来确定(部分或全部)。CAM表中的连接表项(entry)被该RTP会话建立。
然后RTSP等待来自相关端点的后续的RECORDED请求。如果(或当)RTSP-RECORDED消息被接收,通过与SETUP消息相同的路径,它被从网络加速器传递到流量管理器再到中央处理器。该RECORDED消息可能包含待记录的流的(时间)范围。此处会话可以被看作已经建立,且网路加速器准备好接收数据。中央处理器基于该范围发送对象的大小(如果该范围没有明确,那么发送最大值),且可用的队列标识QID被提交到流量管理器用于调度。只要该流持续不变,就可以使硬件加速器通过对头值的简单替换来处理包。
可以终止或修改CAM表格记录,例如,如果本地存储装置开始记录输入流,且指引该流到重放装置的记录可以被修改,这样包也可以被指引到磁盘控制器。可选地,联合流与本地存储装置的端点的另一个记录也可以被添加。
RTP终端路由根据情况切换可能改变的操作,以及类似的计算集中的功能可能由于太复杂而不会在相对简单的硬件中执行。同样的实时流数据包的时间压力太严格,以至于不允许带有很大的程序的中央处理器总是以一种及时的方式有效地处理输入的流量(例如空闲时)。本发明实现了一个可选的方法,其中流上的每一个包都被网络加速器接收,该网络加速器将包在连接表中匹配,去除层三和层四头(layer three and four headers),应用本地头,并且发送带有本地头、RTP头和RTP有效载荷的每一个包到流量管理器,用于写到目的端,例如本地磁盘。
输入包的格式是包含32比特数量的本地头(Local Header),包括包和任何需要的标志(flags)的整体长度的值。这些字段(fields)定义每一个RTP包的边界,并且当该包被存入到磁盘中之后,保持有效。当对象以这种格式被存储,被存储的包可以被安排,用于在确认期间向后传递到初始端点,或者可以被指引路由到网络中的另一个端点。流量管理器必须有一个包一个包地读取这些对象的能力,这样它可以从本地头中为每一个包提取出长度字段来用作传输的尺寸。流量管理器将数据的长度比特发送到网络加速器,并且将队列提前到下一个包的开始。
当从流量管理器接收到包时,网络加速器除去本地头,并增加偏移量(offset)。该偏移量最初由中央处理器来确定,并被作为一个字段存储在CAM表格中用于相关的传输,从而有助于确定由硬件加速器置于输出包RTP头中的序列号字段。这使能随机ISS的规定,如在RFC3550中详细说明的。
输出时间戳以可比较的方式来调整。这使能随机ITS的规定,如在RFC3550中详细说明的。
层三和层四的头被类似的构造,并被设置在输出包的头中。输出包被发送到MAC/PHY模块。
该方法的一个优点就是输入的RTP流量可以通过软件来管理。由于用到了各种不同类型的RTP有效载荷类型,或者在定义上可能变化,对它们的支持可以通过本发明的流装置来维持。另外,记录时的显示延迟(delayed-view-while-record)的PVR功能能得到支持。
缺点是当对象以RTP头格式存储时,不是为HTTP传输易取得的。在主机中央处理器(host central processor)上的软件可用于重组原始的媒体对象,为了使得该对象对于非RTP客户端立即可用,或者直到必要的资源是可用的,通过重组地延迟对任意客户端该对象可用。
参考图7,在一个有利的实施例中,本发明被合并到数据操作系统中,包括一个磁盘阵列控制器设备。该设备可以进行存储管理以及为客户电子数字化媒体应用服务,或者其他具有类似特性的应用,例如通信和电话会议。在娱乐应用中,该设备在家庭网络和数据存储设备的阵列之间提供一个接口,通常被具体化为用于存储数字化媒体(视频、音频、图像)的硬磁盘驱动器(Hard Disk Drives,简称HDD)。
该装置较佳地提供集成的10/100/1000以太网MAC端口,用于向着家庭网络或其他局域网(LAN)连接。一个USB 2.0外围附加端口被有利地提供,用于媒体输入装置(例如闪存卡(flash cards))的连通,或者用于通过外部无线LAN适配器的增加连通到无线家庭网络。
较佳的数据操作系统采用多个层和多种功能,用于通过上层协议加速引擎(对于IP/TCP,IP/UDP进程)和会话感知(session-aware)流量管理器,对媒体文件(media archive)高性能的共享访问。该会话感知流量管理器运行,如同除管理在这里讨论过的RTP流之外的中央处理器,使能共享资源的分配,例如根据活动的媒体会话的类型,网络带宽、存储器带宽以及磁盘阵列带宽的分配。例如,一个视频会话接收比图像浏览会话更多的资源。此外,带宽被分配,同样要保证时间敏感性媒体会话,或者对于非时间敏感性应用同样要最优利用带宽,例如媒体文档大批上载或多PC备份应用。
数据操作系统包括带有相关的独立冗余磁盘阵列(Redundant Array ofIndependent Disk,简称RAID)的高性能流。流-RAID模块可以被用于误差保护冗余,并且保护存储在文档中的媒体以防止任意单个HDD的失败。HDD可以是串行ATA(SATA)磁盘,例如包含8个SATA磁盘,以及通过流量管理器/仲裁器模块处理达64之多的同时发生的双向流的能力。
对于本发明,因为数据操作系统是各种可能的应用的一个实例,整体的数据操作系统如图7所示,仅做大致的描述。在该装置中有两个分开的数据路径,即接收路径和传输路径。“接收”路径被认为传输流的方向从其他外部装置到该系统,“传输”路径是数据流的相反方向,在给定流的上下文(context)中,该路径分别地引导在某点从源端并且朝着目的端的方向。
高层处理器(Upper Layer Processor,简称ULP)在数据通信中被连接到/连接自G比特以太网控制器(Gigabit Ethernet Controller,简称GEC)或外围流量控制器(Peripheral Traffic Controller,简称PTC)。该PTC直接连接到用于基于传输的非包的流量管理器/仲裁器(TMA)。包传输如同此处论述的被处理。
在接收数据路径中,GEC或PTC模块典型地从一个物理接口接收以太网包,例如至/自一个更大的网络。该GEC进行各种以太网协议相关的检查,包括包的完整性,多播地址的过滤等等。包被传递到ULP模块进行进一步的处理。
ULP解析层2、层3和层4的被提取以形成地址的头字段。然后连接查找基于该地址被执行。使用该查找的结果,ULP确定关于将接收到的包发送至何处。来自于已经建立的连接的到达包被预先定义的队列标识(QueueIdentification,简称QID)所标注,用于传输被TMA使用的排队目的。来自未知连接的包需要通过与应用处理器(And Application Processor,简称AAP)进一步调查。该包被标识带有特别的QID并被路由到AAP。当它携带媒体内容时,AAP之后到达包的最终的目的端将是用于存储的硬盘,或者当它携带控制消息,那么将是需要进一步调查的AAP,或者该包不能被AAP所识别,可能导致新的队列ID的建立。在以上所述的任何一种情况中,该包都被发送到TMA模块。
TMA将到达的业务存储在共享存储器中。在媒体对象传输的情况中,输入对象数据被存储在存储器中,并被传输到RAID编码器和解码器(RDE)模块,用于磁盘存储。TMA通过向RDE提供适当的控制信息来管理存储程序。朝着AAP检查的的控制业务也被存储在共享存储器中,并且AAP为一给定访问以读取在存储器中的包。AAP还使用这种机制,以重新排列接收到的排列不规则的所有的包。一部分共享存储器和磁盘包含程序指令和AAP用到的数据。TMA通过从磁盘到存储器和从存储器至磁盘传输控制信息,来管理对存储器和磁盘的访问。TMA还可以使能AAP以插入和提取数据到已存在的包流,和从已存在的包流中插入和提取数据。
在传输数据路径中,TMA管理来自磁盘的对象恢复(retrieval)请求,该请求被指定必要时被处理,以通过应用处理器或网络接口发送。依据从应用处理器接收的媒体重放请求,TMA通过多驱动控制器(MDC)和RDE模块接收从磁盘传输来的数据,并将其存储到存储器中。然后TMA根据需要的带宽和媒体类型将数据调度到ULP模块。ULP为每一个输出包用以太网和层3/层4头封装数据。然后这些包基于被指定的目的端口被发送到GEC或PTC模块。
对于接收数据路径上的输入包,网路加速器的连接查找功能部分可以包括地址形成、CAM表查找和连接表查找功能模块。CAM查找地址部分地被形成,作为从输入包头中提取的信息的结果。待被提取的头字段的细节依赖于使用的传输协议。待形成的地址必须表示独一无二的连接。对于大多数普通的互联网业务,例如在IPV4和TCP/UDP协议中携带的,源端IP地址、目的端IP地址、TCP/UDP源端端口号、TCP/UDP目的端端口号和协议类型(所谓的来自包头的“五元组(five tuple)”)定义一个独一无二的连接。其他字段可用于确定是否是不同传输协议(例如IP V6)的包的连接。适当的控制,例如标志(flags)和标识编码(identifying codes)可以在多协议被供应的地方被参考,这样可以使系统成为一个分等级的“协议意识(protocol aware)系统。例如,进程可以被分成三个阶段,每一个阶段对应一级可被支持的协议。第一阶段可以在头解析处理期间,从被提取的字段以及在信息缓存器表目中存储的字段中核查层3协议的版本号,用于在地址形成过程中作为一个步骤的到达包。对于地址形成过程中的第二和第三阶段,提供了一个合成硬件表格。在每一阶段的表格项号依赖于该表格所在的阶段以及在每一阶段被支持的不同协议的数目。每一个表格项总是包括CAM项和位置号码寄存器。每一个位置寄存器总是由一对偏移量大小的字段组成。每一个CAM项为相应的位置寄存器存储特定的协议值。该偏移量指定从包头的起始到被提取的字段被跳过的比特数。大小字段指定被提取的半字节(nibbles)的数量。相同的地址用来访问CAM字段和位置寄存器。
在特定协议标注,头长度可能是不固定的。例如,TCP和IP头长度可以由于“选项(option)”字段而改变。来自于外部标准协议的可能改变的头长度将相关地取代在内部标准协议的字段的位置,包括内部标准头长度本身。为了适应头长度的改变,对于那些包含长度字段的标准,协议的头长度字段可以被提取来作为地址查找程序的一部分。一些协议(例如IP V6和UDP)在头中可能没有长度字段。如果是那样的话,没有头长度可以被提取,但是可能通过其他技术可以被采用,例如在给定的连接中设置并保持固定的头长度。
地址形成过程如图8所示。在地址形成的过程中,包被缓存,并且协议的第一级(例如IP协议的版本号)被标识并被存储在包信息表中。在给定时间,在包信息表中有许多项,在包信息缓存器的头部(header)的项被首先访问。如果长度项存在,则头长度(例如IP头长度)从包信息表中被提取。从第一阶段提取的协议类型编码影响到何处去寻找第二阶段协议值。
CAM支持任何可能的协议和偏移量的组合。确定的第一偏移量大小值引导协议的第二级的提取(例如,本例中IP协议的协议字段)。在每一阶段,位置号码寄存器与CAM项的数量一一对应的登记。在第二阶段,对于每一项有两对位置寄存器。如果存在头长度字段(例如IP头长度),那么根据在第二对位置寄存器中指定的偏移量,该字段被从包头中提取。
在第三阶段的字段提取过程与第二阶段的类似。然而,在第三阶段CAM的访问应当反应从第一阶段和第二阶段中被提取的协议类型的串联,等。现在有8对偏移量大小字段,用于从8个字段中提取值。考虑到协议类型值,从每一项中提取的多个字段被用于标识该项,这样值被串联起来形成最终的地址。
在缓存器中或者在地址形成寄存器中被访问的字段和CAM被网络加速器处理。在ULP中的控制处理器仅读取对于构建查找地址必要的值,用来确定在CAM中需要重视的地址。如果在地址形成过程中CAM查找丢失,那么该过程可以被异常中断,并且输入包用一个错误标志来标注。
如果在每一阶段提取的协议字段具有不同的长度,那么对于不同的协议,可能填充项来获得固定的偏移量大小。没有用到的比特填充存储器地址直到固定大小,为了使能固定长度的CAM查找。
地址形成寄存器的范围可以被摘要。第二阶段有两个寄存器项、两个CAM项和一对用于每一个消息队列项的位置寄存器。第三阶段有8个寄存器项、8个CAM项和8对位置寄存器。每一个位置寄存器包括16比特,10比特用于表示偏移量(覆盖512字节),6比特用于表示大小(表示64个半比特)。
当连接被建立时,即在特定的源端和目的端点之间发出用于特定数据传输的连接开始的信号的数据包的到达时,在地址形成阶段形成的值与控制处理器(即应用处理器)之前存储的信息一起被使用。控制处理器用项增加CAM。在CAM中的每一项都独一无二地决定一个连接。
当该系统被初始化(例如在任意传输连接被建立之前)时,在CAM中没有项。因此,当第一个包到达时,没有匹配地址项被找到以匹配在CAM中的地址消息,该包暂时地会被认作CAM查找丢失。如果是那样的话,在存储器位置上一个特定的队列标识QID被分配到包,存储器位置是为控制处理器(即应用处理器AAP)保留的。
依据分析到达包,该AAP可以确定建立连接的需要。在CAM中一个空闲(free)项(例如,该系统可以同时支持的64个可能的流中的一个)被发现。该空闲项地址被用于为新的流设置连接表。AAP将连接地址写入CAM的空闲项中,这样具有相同地址的随后到达的包将匹配在CAM中的项。这许可随后到达的包被处理而不需要AAP的关注,因为这些包是被讨论过的网络加速器功能所处理的。
当到达包被找到以匹配在CAM中有一项(一个CAM成功结果(CAM hit))的已存在的连接,那么匹配CAM项的地址被用于查找连接表信息、QID和其他信息。在被讨论的例子中,有64个CAM项以支持64个连接。每一个CAM项被分配直到256比特。当然其他特定数量是可能的。
被占用的CAM项和空闲的CAM项都可以访问至控制处理器AAP。控制处理器AAP担负设定、撤销和循环CAM项的责任。
CAM设备本身可以以各种方式实现,通常包括寄存器和门控装置,门控装置使能可能的输入数据值的至少一个子集,用作寻址输入以从存储器中提取相应的输出数据值。随机存取存储器(Random Access Memory,简称RAM)设备典型地通过寻址特定存储器的位置来存储和检索数据,每一个可能的输入值对应一个存储器位置。大量的寻址比特对应大量的存储器位置,这其中存储器项的数量不大,在存储器中找到一给定项的时间需求可以通过硬件门控装置来减少,该硬件门控装置使能与在存储器中存储的数据内容的一部分的数字比较,其本身胜于详细说明存储器地址。用这种方式,被访问的存储器叫做内容可寻址存储器(CAM),并且具有在讨论的类型的应用中具有优势。
在讨论的例子中,CAM可以在被存储的值的宽度从4比特到144比特间改变,并且具有一个从6到1024项的深度。在一个实施例中,如图9所示,提供了两个级联的CAM设备,每一个包括64项乘129比特的设备,用于支持直到64个双向流。在129比特中,128比特用于数据存储,1比特用作为项-有效比特(entry-valid bit)。形成64乘256的CAM的装置在图9中被表示成简化的CAM查找逻辑表格,其中256比特字被分成两个128比特子字(subwords),并且每一个子字对比分开的CAM设备的内容进行比较。在该装置中,128比特子字中的一个或另一个可能匹配在每个CAM设备中的多个项。然而,整个256比特项只能对应于一个独一无二的存储值(stored value)。这个操作通过被整理的寻址和串联这两个CAM设备的比较关系被促进。
当存在用于到达包的CAM成功结果(CAM hit)时,与该到达的地址相匹配的项的CAM地址被用于访问关系到连接的多种信息值。这些信息值列在如下表1中。
表1
域名称   大小(bits) 描述
 QID(队列标识)   6   当没有查找问题时,QID用于流量管理
Header_Keep(头_保持) 1   头-保持(Header-Keep)比特指出当将包发送到TMA时,ULP是否应当去掉层2、层3和层4头。应当注意,这个比特只有当QID被使用时才应用。当错误-QID(Error-QID)被使用时,头一直被保持。
 OOS_QID脱离序列的队列标识) 6   脱离顺序队列ID:这个QID被用于出了序列包,等等。
 Local Header Enable(本地头使能) 1   在设置时,ULP将会预先填充一个本地头到每个到达的包。
对于一些连接,一个本地头被生成,并且被预先填充至每个输入包。这种本地头生成可以由AAP配置。当来自网络中的包到达时,会创建ULP本地头。该本地头具有固定的32比特的大小,在图10中格式被详细说明。该ULP预先填充包长度,包长度通过对每一个接收的包的比特计数而获得。而且,它还将由GEC和它本身从查找中产生的标志插入到本地头中。不考虑包目的端,只要本地头是使能的,ULP就以相同的格式添加该本地头。
本发明通过一个装置作为示例,但是也可以被看作发明的方法。参考图像生成,本发明的流装置(参见图1、2、7)在源端27和目的端29之间指引具有字段24的包数据22,字段24表示为控制值、源端地址、目的端地址和有效载荷类型中的至少一个。根据数据包22的所述字段确定的规则,通信路径32接收到来自服务器27或类似装置的数据包,并且该数据包22的至少一部分内容33被传递到至少一个客户端35。
这些规则包括可选项(alternatives),通过可选项,数据包可能以不同的方式被传递到一个或多个客户端,例如被编址到不同的特定装置,通过不同的协议的处理细节被处理等等。控制处理器39被连接到通信路径上。控制处理器的功能可以全部或部分地在一个或多个ULP和AAP中被提供,或者在附加的控制器中被提供。在任何情况下,建立一个连接或流时,控制处理器至少部分确定可应用到至少两个为处理包的可选的程序。
根据一个发明方面,具有存储器43的网络加速器42被连接到控制处理器39,控制处理器39用表示为至少两个可选的程序的数据加载网络加速器的存储器43,通过该至少两个可选的程序,数据包以不同的方式被传递。程序包括(但不限于)将数据包指引到不同的本地或远处的地址。此后网络加速器42可充分地独立于控制器39操作,以将数据包22传递至客户端35。数据包22具有包含字段的头24(如图3),以及网络加速器42可以为替换和添加所述字段中的至少一种对该字段做出响应,从而在至少两个可选项之间选择。
该装置适用于处理RTP实时协议流。除了包含程序内容的包,例如数据样本或RTP中被压缩的数据程序设计,根据RTSP和RTCP流控制协议中的其中之一,数据包进一步包括控制信息。
在较佳的装置中,网络加速器包含具有被使用的数据值的内容可寻址存储器,例如,当前活动的每一个正在进行的流的本地寻址(addressing)。控制器设置给定流用到的数据值。当可能使用包含内容可寻址存储器或至少连接到内容可寻址存储器的硬件加速器开发高数据速率时,使用该内容可寻址存储器,至少一些相同的数据值被用于相同流的随后的包,而没有实际地选择控制器的计算资源。
运行各自的组分来实现包括用相关的头信息将内容打包的步骤的方法,该头信息表示为至少一个变量(variable),通过该变量打包的内容可选地在一个或多个源端和一个或多个目的端之间被处理,因此打包的内容的处理取决于所述变量;将控制信息包括在流内容中,由此,根据控制信息,可选地处理打包的内容的方式是可变的;建立或重指引,暂停或改变在源端和目的端之间的打包的内容的流,并且,当如此做了,确定一个至少部分来自于控制信息的变量的值,并将所述值存储在网络加速器中,与流的标识相关联。此后,当接收到流的打包的内容时,存储在网络加速器中的与流的标识相关联的值被用于处理接收到的打包的内容。
因此,用来自控制处理器的最小的正在进行的动作,正在进行的流的打包的内容大部分地、可选择地被网络加速器处理。
本发明结合可实现的实施例来进行公开,但是对于附加的权利要求应当成为参考,而非实施例的讨论来确定本发明排他权利被声明的范围。

Claims (16)

1、一种用于指引数据包的流装置,所述数据包具有表示控制值、源端地址、目的端地址和有效载荷类型中的至少一个的字段,该装置包括:
通信路径,用于接收来自服务器的数据包,并沿着该路径,根据来自数据包的所述字段的部分确定的程序,至少数据包的内容部分被传递到至少一个客户端;
其中所述程序包括至少两个可选项,通过所述至少两个可选项,所述数据包可以以至少两种不同的方式传递到所述至少一个客户端;
控制处理器,连接到所述通信路径,其中所述控制处理器是至少部分地用于确定被应用到各自的可选项的所述程序中的一个;
网络加速器,具有一存储器,其中所述控制处理器用于用表示所述至少两个可选项的数据加载所述网络加速器的所述存储器,通过所述至少两个可选项,所述数据包以不同的方式被传输,以及此后,其中所述网络加速器充分地独立于所述控制处理器,用于根据所述程序,将数据包以所述不同的方式传递到至少一个客户端。
2、根据权利要求1所述的流装置,其中所述数据包具有包含所述字段的头,并且所述网络加速器用于为了替换所述字段和添加所述字段中的至少一种,响应所述字段,以在所述至少两个可选项之间选择。
3、根据权利要求1所述的流装置,其中所述数据包以不同的方式被传递到所述至少一个客户端,所述不同的方式包括:通过改变与包相关的寻址信息的方式。
4、根据权利要求3所述的流装置,其中所述数据包被添加本地地址,所述数据包根据规则被传递到所述本地地址。
5、根据权利要求1所述的流装置,其中所述数据包包括根据实时传输协议RTP流协议配置的内容包并包含寻址信息,以及其中所述网络加速器提供给所述内容包补充的和替换寻址的信息中的一个。
6、根据权利要求5所述的流装置,其中,根据实时流协议RTSP和实时传输控制协议RTCP流控制协议中的一个,所述数据包进一步包括控制信息。
7、根据权利要求6所述的流装置,其中,在包括根据实时流协议RTSP和实时传输控制协议RTCP流控制协议中的一个的控制信息的至少一定的所述数据包中的信息根据所述控制处理器的程序设计被采用,用于定义所述规则,通过所述规则,所述内容包被传递到至少一个客户端。
8、根据权利要求7所述的流装置,其中所述网络加速器包括内容可寻址存储器设备,所述内容可寻址存储器设备被所述控制处理器用定义所述规则的信息加载,并且其中所述网络加速器根据所述控制处理器的程序设计,通过从所述存储器设备读取被存储的数据,访问适用于给定包的给定的规则。
9、根据权利要求8所述的流装置,其中所述数据包表示音频数据和视频数据的至少一种,并且其中所述规则应用于音频或视频存储设备、娱乐装置、音频通信设备以及电话会议设备中的一个的不同切换处理中。
10、根据权利要求9所述的流装置,其中所述网络加速器用于根据所述规则,将所述包指引到目的端设备和网络存储装置。
11、根据权利要求9所述的流装置,其中所述网络加速器用于根据所述规则,将所述包指引到目的端设备,所述目的端设备包括:读出设备、存储设备、用于转换包的中间数据处理器、本地终端设备以及远程终端设备。
12、一种与内容的实时参考充分地保持一致的形成流的内容的方法,包括:
用打包具有相关的头信息的所述内容,所述相关的头信息表示至少一个变量,通过所述变量,打包的内容在一个或多个源端和一个或多个目的端之间可选择地被处理,因此取决于所述变量;
将控制信息包含在所述形成流的内容中,因此根据所述控制信息,可选择地处理打包的内容的方式是可变的;
提供一访问所述控制信息的控制处理器,并提供一访问所述打包的内容的网络加速器;
依据在至少一个所述源端和至少一个所述目的端之间建立、重定向、暂停和改变打包内容的流的其中之一,确定一个至少部分来自于所述控制信息的变量的值,并将所述值存储在所述网络加速器中,与所述流的标识相关联;
依据接收的所述流的打包的内容,从所述网络加速器确定存储的值与所述流的标识相关联,并且基于从所述网络加速器确定的所述值,处理在所述一个或多个源端和所述一个或多个目的端之间的所述接收到的打包的内容,因此用来自控制处理器的最小的正在进行的动作,可选择地处理正在进行的流的所述打包的内容。
13、根据权利要求12所述的方法,还包括修正存储在所述网络加速器中的所述值,所述修正由所述控制处理器的操作完成。
14、根据权利要求13所述的方法,其中所述控制处理器修正存储在所述网络加速器中的所述值作为随后接收到的控制信息的处理结果。
15、根据权利要求12所述方法,包括:提供多个在硬件加速器中具有项的标识流,并且其中所述硬件加速器可选择地应用于增加打包的内容,存储在所述硬件加速器中的多个值中的一个与一相应的标识流相关联。
16、根据权利要求15所述的方法,其中包括:提供一包含消息队列的内容可寻址存储器,其中所述标识流的项是可访问的,并且通过将一项与相应的所述标识流中的一个的标识相匹配,来确定所述多个值中的一个。
CNA2006800457326A 2005-10-07 2006-10-06 使用不同元件对流进行媒体数据处理以及控制方法 Pending CN101352012A (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US72446205P 2005-10-07 2005-10-07
US60/724,722 2005-10-07
US60/724,464 2005-10-07
US60/724,573 2005-10-07
US60/724,462 2005-10-07
US60/725,060 2005-10-07
US60/724,463 2005-10-07

Publications (1)

Publication Number Publication Date
CN101352012A true CN101352012A (zh) 2009-01-21

Family

ID=40269758

Family Applications (2)

Application Number Title Priority Date Filing Date
CNA2006800457326A Pending CN101352012A (zh) 2005-10-07 2006-10-06 使用不同元件对流进行媒体数据处理以及控制方法
CNA200680045742XA Pending CN101352013A (zh) 2005-10-07 2006-10-06 用补充命令文件进行rtp出口流的方法和装置

Family Applications After (1)

Application Number Title Priority Date Filing Date
CNA200680045742XA Pending CN101352013A (zh) 2005-10-07 2006-10-06 用补充命令文件进行rtp出口流的方法和装置

Country Status (1)

Country Link
CN (2) CN101352012A (zh)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102447673A (zh) * 2010-09-30 2012-05-09 突触计算机系统(上海)有限公司 一种用于解封装携有封装格式的多媒体文件的方法与设备
CN102474424A (zh) * 2009-07-24 2012-05-23 思杰系统有限公司 用于在电话会议期间在计算机和演讲者之间转换音频传输的系统和方法
CN103269333A (zh) * 2013-04-23 2013-08-28 深圳市京华科讯科技有限公司 基于虚拟化的多媒体加速系统
CN103620628A (zh) * 2011-05-31 2014-03-05 斯迈达Ip有限公司 用于提供和管理在网络中与rfid数据载体链接的信息的方法和装置
CN106575206A (zh) * 2014-09-26 2017-04-19 英特尔公司 计算机系统中的存储器写入管理
CN108475244A (zh) * 2015-12-22 2018-08-31 英特尔公司 加速网络分组处理
CN109189994A (zh) * 2018-06-27 2019-01-11 北京中科睿芯科技有限公司 一种面向图计算应用的cam结构存储系统
CN110971586A (zh) * 2018-09-28 2020-04-07 赛灵思公司 网络接口设备
WO2021037124A1 (zh) * 2019-08-30 2021-03-04 华为技术有限公司 一种任务处理的方法以及任务处理装置
US11362967B2 (en) 2017-09-28 2022-06-14 Barefoot Networks, Inc. Expansion of packet data within processing pipeline
US11425058B2 (en) 2017-04-23 2022-08-23 Barefoot Networks, Inc. Generation of descriptive data for packet fields
US11503141B1 (en) 2017-07-23 2022-11-15 Barefoot Networks, Inc. Stateful processing unit with min/max capability
US11606318B2 (en) 2017-01-31 2023-03-14 Barefoot Networks, Inc. Messaging between remote controller and forwarding element

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110545487B (zh) * 2019-08-20 2021-11-16 中央电视台 组播信号编址方法、传输方法及装置、交换机
CN111245809A (zh) * 2020-01-07 2020-06-05 北京同有飞骥科技股份有限公司 跨层数据处理方法及系统
CN116384305B (zh) * 2023-06-05 2023-08-01 英诺达(成都)电子科技有限公司 数据通信方法、装置、系统、设备及计算机存储介质

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102474424A (zh) * 2009-07-24 2012-05-23 思杰系统有限公司 用于在电话会议期间在计算机和演讲者之间转换音频传输的系统和方法
CN102474424B (zh) * 2009-07-24 2015-02-11 思杰系统有限公司 用于在电话会议期间在计算机和演讲者之间转换音频传输的系统和方法
CN102447673A (zh) * 2010-09-30 2012-05-09 突触计算机系统(上海)有限公司 一种用于解封装携有封装格式的多媒体文件的方法与设备
CN103620628A (zh) * 2011-05-31 2014-03-05 斯迈达Ip有限公司 用于提供和管理在网络中与rfid数据载体链接的信息的方法和装置
US9582690B2 (en) 2011-05-31 2017-02-28 Smartrac Ip B.V. Method and arrangement for providing and managing information linked to RFID data storage media in a network
CN103269333A (zh) * 2013-04-23 2013-08-28 深圳市京华科讯科技有限公司 基于虚拟化的多媒体加速系统
CN106575206A (zh) * 2014-09-26 2017-04-19 英特尔公司 计算机系统中的存储器写入管理
CN108475244A (zh) * 2015-12-22 2018-08-31 英特尔公司 加速网络分组处理
CN114189571B (zh) * 2015-12-22 2024-04-05 英特尔公司 用于实施加速网络分组处理的装置和方法
US11677851B2 (en) 2015-12-22 2023-06-13 Intel Corporation Accelerated network packet processing
CN114189571A (zh) * 2015-12-22 2022-03-15 英特尔公司 加速网络分组处理
US11134132B2 (en) 2015-12-22 2021-09-28 Intel Corporation Accelerated network packet processing
CN108475244B (zh) * 2015-12-22 2022-07-08 英特尔公司 加速网络分组处理
US11606318B2 (en) 2017-01-31 2023-03-14 Barefoot Networks, Inc. Messaging between remote controller and forwarding element
US11425058B2 (en) 2017-04-23 2022-08-23 Barefoot Networks, Inc. Generation of descriptive data for packet fields
US11503141B1 (en) 2017-07-23 2022-11-15 Barefoot Networks, Inc. Stateful processing unit with min/max capability
US11750526B2 (en) 2017-07-23 2023-09-05 Barefoot Networks, Inc. Using stateful traffic management data to perform packet processing
US11362967B2 (en) 2017-09-28 2022-06-14 Barefoot Networks, Inc. Expansion of packet data within processing pipeline
US11700212B2 (en) 2017-09-28 2023-07-11 Barefoot Networks, Inc. Expansion of packet data within processing pipeline
CN109189994B (zh) * 2018-06-27 2021-11-09 北京中科睿芯科技集团有限公司 一种面向图计算应用的cam结构存储系统
CN109189994A (zh) * 2018-06-27 2019-01-11 北京中科睿芯科技有限公司 一种面向图计算应用的cam结构存储系统
CN110971586A (zh) * 2018-09-28 2020-04-07 赛灵思公司 网络接口设备
CN110971586B (zh) * 2018-09-28 2023-11-03 赛灵思公司 网络接口设备和网络接口设备中的方法
WO2021037124A1 (zh) * 2019-08-30 2021-03-04 华为技术有限公司 一种任务处理的方法以及任务处理装置

Also Published As

Publication number Publication date
CN101352013A (zh) 2009-01-21

Similar Documents

Publication Publication Date Title
CN101352012A (zh) 使用不同元件对流进行媒体数据处理以及控制方法
KR100926007B1 (ko) 스트리밍 및 제어 처리를 위한 별도의 구성을 이용한미디어 데이터 프로세싱
US11381625B2 (en) Apparatus and method for transmitting multimedia data in hybrid network
US7447775B1 (en) Methods and apparatus for supporting transmission of streaming data
US8396960B2 (en) Efficient network utilization using multiple physical interfaces
US6263371B1 (en) Method and apparatus for seaming of streaming content
US8880716B2 (en) Network streaming of a single data stream simultaneously over multiple physical interfaces
US8325601B2 (en) Reliable network streaming of a single data stream over multiple physical interfaces
EP1678909B1 (en) Method, system and article for dynamic real-time stream aggregation in a network
CN111083425B (zh) 视频流处理方法、装置、服务器、电子设备及存储介质
US8356109B2 (en) Network streaming of a video stream over multiple communication channels
KR101278632B1 (ko) 인터넷 프로토콜을 사용하여 직렬 버스를 통해 데이터운반을 수행하는 방법 및 그러한 방법에 사용하기 위한장치
US20070067485A1 (en) Method and system for managing video networks
CN102265535A (zh) 以不同编码率将多个可缩放编码视频内容流送到客户端设备的方法和装置
CN110474721B (zh) 视频数据传输方法、装置及计算机可读存储介质
JP2002529966A (ja) データ伝送
US10924524B2 (en) Communication devices, communication data generation method, and communication data processing method
CN110661726A (zh) 一种基于多链路聚合的数据发送方法和装置
US8375139B2 (en) Network streaming over multiple data communication channels using content feedback information
JP4487711B2 (ja) 送信装置および方法、受信装置、通信システム、記録媒体、並びにプログラム
Zimmerman et al. Retransmission-based error control in a many-to-many client-server environment
CN106792216B (zh) 分布式文件系统中流媒体读取方法及服务器
WO2000077999A2 (en) Method and apparatus for dynamic proxy reflecting of streaming content
US20240214324A1 (en) Traffic alarm method and apparatus based on programmable switch, device and medium
Aliyev Multipath RTP for video

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication

Open date: 20090121