CN103313026B - 处理多跳rtp流中的关键分组丢失的系统和方法 - Google Patents

处理多跳rtp流中的关键分组丢失的系统和方法 Download PDF

Info

Publication number
CN103313026B
CN103313026B CN201310177406.2A CN201310177406A CN103313026B CN 103313026 B CN103313026 B CN 103313026B CN 201310177406 A CN201310177406 A CN 201310177406A CN 103313026 B CN103313026 B CN 103313026B
Authority
CN
China
Prior art keywords
packet
media
equipment
rtp
send
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.)
Expired - Fee Related
Application number
CN201310177406.2A
Other languages
English (en)
Other versions
CN103313026A (zh
Inventor
A·亚塞
D·布尔葛叶
A·海拉威
J·P·斯皮尔曼
D·维尔米弗
王晓薇
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.)
Polycom Inc
Original Assignee
Polycom Inc
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 Polycom Inc filed Critical Polycom Inc
Publication of CN103313026A publication Critical patent/CN103313026A/zh
Application granted granted Critical
Publication of CN103313026B publication Critical patent/CN103313026B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems
    • H04N7/152Multipoint control units therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/403Arrangements for multi-party communication, e.g. for conferences

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

本公开涉及处理多跳RTP流中的关键分组丢失的系统和方法,并且尤其是公开了在可能丢失分组的网络中实现的用于减小压缩媒体传送系统的重传需求的方法和系统的示例实施例。每个发送分组的扩展报头可以指示分组的优先级,并且端点可以确定是否希望进行丢失分组的重传。分组在多跳系统中的不同跳上的缓冲可以允许通过比发送视频分组的原始系统更近的跳来满足重传请求。在一个实施例中,通过以7.5帧/秒压缩第一和第二级别和以15帧/秒压缩第三级来建立3个优先级等级以实现可靠的30帧/秒的帧率。

Description

处理多跳RTP流中的关键分组丢失的系统和方法
相关申请的交叉引用
本申请要求2012年2月10日提交的申请号为61/597,524、发明名称为“SYSTEM ANDMETHOD FOR HANDLING CRITICAL PACKETS LOSS IN MULTI-HOP RTP STREAMING”的美国临时专利申请的优先权,上述申请的全部内容以引用的方式并入本文中。
技术领域
本发明涉及视频通信,尤其是,涉及多点视频会议领域。
背景技术
视频会议能够使相互之间距离遥远的个体进行面对面的会议。可以使用音频和视频通信来执行视频会议。视频会议可以在最少两个站点(点对点)之间,或者在多个站点(多个点)之间进行。会议站点可以包括一个参与者(用户,与会者)或者多个参与者(用户,与会者)。视频会议还可以被用于共享文件、演示、信息,以及诸如此类。
例如,参与者可以通过视频会议端点(EP)来参加视频会议。端点(EP)可以是例如网络终端。端点能够为其它终端和/或多点控制单元(MCU)提供实时、双向、音频/视频/数据通信。端点(EP)可以提供不同形式的信息/数据,包括音频;音频和视频;数据、音频和视频等等。可以相互替换地使用术语“终端”、“站点”和“端点”。在本公开中,术语端点可以被用作上面那些术语的代表性术语。
端点可以包括显示单元(屏幕),在其上可以显示来自一个或多个远程站点的视频图像。示例端点包括系列端点,每一个都可以从Polycom公司获得(POLYCOM、VSX和HDX都是Polycom公司的注册商标)。视频会议端点可以将来自本地站点的音频、视频,和/或数据发送至一个或多个远程站点,以及在其屏幕(显示单元)上显示从远程站点(一个或多个)接收到的视频和/或数据。
在端点的屏幕上显示的视频图像可以以所设置的布局被显示。界面可以包括一个或多个用于显示视频图像的区块。区块可以是接收端点的屏幕的预定部分,接收端点被分配给从参加视频会议会话的站点之一接收的视频图像。在两个参与者之间的视频会议中,区块可以覆盖端点屏幕的整个显示区域。在每个站点中,区块可以显示从其它站点接收的视频图像。
在本地站点和多个远程站点之间的视频会议中的视频显示模式的例子可以是切换模式。切换模式可以是,每次只有来自远程站点之一的视频/数据被显示在本地站点的屏幕上。依赖于会议的动态,所显示的视频可以被切换至从另一站点接收的视频。
与切换模式相反,在持续存在(CP)会议中,本地端点处的与会者(参与者)可以同时观察来自参加视频会议的不同端点的多个其他与会者。每个站点可以被显示在布局的不同区块中,布局被显示在本地屏幕上。区块可以是相同大小或者不同大小。显示在屏幕上的站点的组合及其与布局的区块的关联在参加相同会话的不同站点之间改变。此外,在持续存在的布局中,来自站点的接收视频图像可以被缩放,上移或者下移,和/或裁切,以适合给其分配的区块大小。应该注意到,可以相互替换地使用术语“与会者”、“用户”和“参与者”。在本公开中,术语与会者可以被用作上面那些术语的代表性术语。
MCU可以被用于管理视频会议。MCU是会议控制实体,通常位于网络节点中或者终端中,其接收来自端点的多个信道,以及根据某种标准,处理音频和/或视频信号,并将它们分配给所连接的一组信道。
示例MCU包括Polycom公司提供的MGC-100和(RMX2000是Polycom公司的注册商标)。某些MCU可以由两个逻辑单元组成:媒体控制器(MC)和媒体处理器(MP)。端点和MCU更详尽的定义可以在国际电信联盟(“ITU”)标准中找到,包括H.320、H.324和H.323标准。关于诸如ITU标准或者会话发起协议(SIP)的视频会议标准和协议的补充信息分别可以在ITU网站www.itu.int或者在Internet工程任务组(IETF)网站www.ietf.org中找到。
其它视频会议系统可以使用媒体中继会议系统(MRC)。在MRC中,媒体中继MCU(MRM)从每个参与媒体中继端点(MRE)接收一个或多个流。MRM将从会议中的其它端点接收的多个视频流集合中继到每个参与端点。每个接收端点使用多个流来生成与布局相符的CP视频图像。CP视频图像被呈现给MRE用户。MRE可以是会话中的与会者终端,其能够从MRM接收中继的媒体,并根据来自MRM的指令传送压缩媒体。在公开号为2010/0194847的美国专利申请中详细描述了MRM,其为了所有目的通过引用合并于本文中。为了本公开的目的,可以相互替换地使用术语端点和MRE。
在某些MRC系统中,发送MRE以两个或更多个质量层、等级发送其视频图像。在某些系统中,在单个流上携带两个或更多个层。在其它MRC系统中,每个层与不同的流关联。这些系统可以提供布局中的不同窗口大小、每个接收端点使用的不同分辨率、不同的帧率(frame rate)等等。此外,多个层可以被用于克服分组丢失。质量在帧率、分辨率和/或信噪比(SNR)等等方面不同。
遍及本公开,术语视频流表示在多媒体会议会话、媒体流或任何使用压缩多媒体流传递的应用中的任何压缩媒体(例如,音频和/或视频)传输。媒体已经由可伸缩译码编码器压缩。进一步地,发送的压缩媒体可以包括多个层,各层的媒体质量相互不同。不同层可以由所公开的实施例不同地处理。同样,本文使用的术语可伸缩译码(Scalable-Coding,SC)表示多层媒体编码的示例。
视频流正变得越来越受欢迎。而且,越来越多的视频流的源以及视频会议系统传输多个层,其中各层的压缩视频质量相互不同。可以在多个域中表示质量,诸如时域(例如,帧/秒)、空间域(例如,高清晰度(HD)或通用中间格式(CIF)),和/或用质量(例如,明锐度)表示。用于视频流和多质量层的视频压缩标准包括H.264AVC、H.264附件G、MPEG-4等等。这些压缩标准可以被称为SC标准。关于诸如H.264的压缩标准的更多信息可以在ITU网站www.itu.int或者www.mpeg.org上找到。
某些视频压缩技术使用两类帧,内帧(intra-frame)和间帧(inter-frame)。内帧是与仅包含在相同帧内的信息相关地、而不与视频序列中的任何其它帧相关地被压缩的视频帧。间帧是既与包含在相同帧内的信息相关地、也与视频序列中的一个或多个其它帧(参考帧)相关地被压缩的视频帧。间帧可以包括预测帧(P帧)和/或双向预测帧(B帧)。在视频会议中,由于B帧引入了等待时间而通常不使用B帧。在以下描述中,间帧被用作术语P帧的代表性术语。
在因特网协议(IP)网络上携带的通常视频会议会话的媒体(例如,音频和视频)使用实时传输协议(RTP)作为媒体分组的传输协议。协同使用RTP协议与实时控制协议(RTCP)。RTCP被用于监控传输统计和服务质量(QoS),并协助多个流的同步。另外,RTP分组通过UDP/IP运送。本领域公知的是,UDP/IP是无连接协议,其不可靠且遭受分组丢失。作为用于识别分组丢失的手段之一,在视频会议流的源端的通用RTP处理器在将媒体分组发送至它们的目的端之前,为每个媒体分组添加序列号。
在压缩视频流的目的端,RTP处理器根据接收分组的序列号对其进行分类,并向相关解码器传递压缩媒体。为了克服分组丢失,RTP处理器在连接的两端可以使用不同的前向纠错技术。进一步地,位于连接两端的视频编码器/解码器使用不同的恢复方法以克服分组丢失。然而,另一个恢复方法可以包括向流的源端发送对一个或多个丢失分组的重传请求。
发明内容
在实时通信中,诸如在视频会议中,重传可以包括对内帧编码并将其发送给所有呈现视频图像的端点,尽管重传帧是由端点之一请求的。内帧的发送增加了网络上的带宽消耗,并且由于帧率的临时减小而降低了用户体验。
在使用多个媒体跳(media-hop)的会话中分组丢失通常是很常见的。媒体跳可以是两个或更多个端点之间的中间节点。例如,媒体跳可以是MCU、MRM、媒体网关等等。为了本公开的目的,术语MCU、MRM、媒体网关和媒体跳可以依赖于上下文被相互替换地使用。在涉及多个媒体跳的会话中,分组在路径的任何部分都会丢失。因此,在到第一跳的途中丢失的分组可以被第二跳所请求,也可以被包括在流的目的端处的终端的一个或多个连续跳所请求。在这种情况下,由其后跟随着多个重传分组的多个不必要重传请求将增加网络和连接两端的端点的负载。
公开了一种方法和系统的示例实施例,其试图增强视频会议会话的与会者的体验,并减小由会话造成的带宽消耗。不同方法可以被用在媒体流系统中,其中媒体压缩技术传递多个可伸缩层。例如,公开的技术可以被实现在视频会议会话中,其中的视频压缩是基于SC的。示例SC压缩标准可以是H.264附件G,通常被称为SVC。在SC中,由于层之间的依赖性,不同层具有不同的重要等级。例如,对于时间可伸缩性(temporal scalability),其中使用了3层(T0,T1和T2),每层与不同的帧率相关,如图1A所示。图1A中的X轴表示RTP流中的帧,这些帧以SC编码,帧率为30帧每秒(F/s)。为了以30F/s传递压缩视频,压缩流包括向目的端发送的3层。
第一层是基层(BL)。对于时间可伸缩性,BL可以被称为T0。BL(T0)包括压缩帧,所述压缩帧是以7.5F/s压缩的,并且基于参考帧来压缩每个帧,该参考帧是在对相同层BL(T0)中其前一个帧进行编码时创建的。因此,帧#5,其是该层BL(T0)中的第二个帧,基于参考帧而被压缩,该参考帧是在对该层的第一个帧(帧#1)进行编码时创建的。帧#9,其是该层BL(T0)的第三个帧,基于参考帧而被压缩,该参考帧是在对该层的第二个帧(帧#5)进行编码时创建的,以此类推。
第二层是第一增强层(EL1)。对于时间可伸缩性,EL1可以被称为T1。EL1(T1)包括压缩帧,该压缩帧是以7.5F/s并且在相对于第一层BL(T0)移位两帧的情况下而被压缩的。每个帧基于参考帧而被压缩,该参考帧是在对第一层BL(T0)中的前一帧进行编码时创建的。因此,帧#3,其是层EL1(T1)的第一个帧,基于层BL(T0)的第一个帧(帧1)而被压缩。帧#7,其是层EL1(T1)的第二个帧,基于层BL(T0)的第二个帧(帧5)而被压缩,以此类推。因此,包括层BL(T0)和EL1(T1)的帧的流可以以15F/s的帧率被解码和呈现。
第三层是第二增强层(EL2)。对于时间可伸缩性,第三层可以被称为T2。EL2(T2)可以包括以15F/s压缩的压缩帧,其中该层的第一个帧(帧2)位于BL(T0)的第一个帧(帧1)和EL1(T1)的第一个帧(帧3)之间。EL2(T2)的每个奇数帧基于参考帧而被压缩,该参考帧是在对第一层BL(T0)中的前一帧进行编码时创建的。EL2(T2)的每个偶数帧基于参考帧而被压缩,该参考帧是在对第二层EL1(T1)中的前一帧进行编码时创建的。因此,帧#2,其是层EL2(T2)的第一个帧,基于层BL(T0)的第一个帧(帧1)而被压缩。帧#4,其是层EL2(T2)的第二个帧,基于层EL1(T1)的第一个帧(帧3)而被压缩,以此类推。因此,包括层BL(T0)、EL1(T1)和EL2(T2)的帧的流可以以30F/s的帧率被解码和呈现。
基于上述压缩不同层的方法,可以在层之间分配优先级。基层BL(T0)的帧是最关键的帧且具有最高优先级;因为其它两层EL1和EL2(对于时间可伸缩性而言是T1和T2)中每一层的帧解码依赖于BL(T0)中的前一帧。EL1(T1)的帧关键程度较低,仅EL2(T2)的帧的解码基于EL1(T1)的帧。类似地,EL2(T2)的帧比EL1(T1)的帧的关键程度更低。丢失携带EL2(T2)的帧一一例如帧8一一的压缩数据的分组将减小所呈现图像的质量一小段时间(~30毫秒),直到接收到下一帧,帧9,为止,帧9属于层BL(T0)。但是,如果携带BL(T0)的帧13的数据的分组丢失了,就会发生持久的伪像,因而需要内帧以恢复丢失的分组。
示例实施例可以修改携带SC压缩数据的分组的RTP报头以包括扩展报头。扩展报头可以包括指示由该分组携带的压缩视频的优先级的字段。该字段可以被称为PrID字段,其中Pr0表示最高优先级。在一些实施例中,发送端点(其是压缩流的源端)可以定义优先级等级。在一些实施例中,在会话期间优先级等级可以改变。例如,可以依赖于接收重传请求的频率来改变优先级等级。携带基层BL(T0)的压缩视频数据的分组可以用最高优先级Pr0来标记。携带EL2(T2)的压缩视频数据的分组可以用最低优先级Pr2来标记。在某些会话中,只接收到很少的重传请求,发送端点可以给层T0和T1都标以最高优先级Pr0。进一步地,沿着从源端至目的端的路径的媒体跳适于丢弃具有较低优先级的RTP分组,并传送具有较高优先级的RTP分组。示例媒体跳可以是媒体GW、MCU、MRM、桥等等。
进一步地,在RTPSC分组的目的端,与具有较高优先级的丢失分组相比,RTP处理器适于不同地响应具有较低优先级的丢失分组。
在其它示例实施例中,RTP扩展报头可以进一步包括新字段,其可以与序列号相关联。对于每个携带Pr0帧的压缩数据的RTP分组,可以由流的源端将第一序列号增加。在从源端至RTP分组的接收端点的所有路径中,该字段的值保持不变。该序列号可以被称为原始Pr0序列号(OPr0SN),OP r0SN使连接到SC流的目的端的解码器的RTP处理器能够识别丢失的Pr0分组。如果发现关键分组,诸如BL(T0)分组,丢失,可以生成对于I帧的请求。
第二个序列号可以被称为跳Pr0序列号(HPr0SN)。由沿着流的路径的每个媒体跳替换HPr0SN。HPr0SN使连接到下一跳的RTP处理器能够识别在RTP处理器之前的最后一段丢失的Pr0分组。从一跳到下一跳,该字段发生变化。每个跳可以使用另一序列计数器,因此从一跳到另一跳,HPr0SN的值可以动态变化。对于每个被发送或者重传Pr0分组,每个跳增加其序列号,即其HPr0SN的值。
另外,每个跳的RTP处理器可以适于检查该字段。如果发现关键分组(Pr0),诸如BL(T0)分组,被下一个RTP接收器丢失,RTP接收器可以发送重传请求至其使用RTCP重传请求的发送器。使用HPr0SN字段识别丢失的关键分组(Pr0)并请求重传丢失的关键分组有效地消除了重传低优先级丢失分组的开销流量。进一步地,每一跳可以适于操纵已发送关键分组的临时存储设备,以便在本地响应对于关键分组(Pr0)的重传请求,这发生在其出口和下一个RTP接收器之间。示例临时存储器可以存储几十个至几百个最后发送的Pr0分组。示例存储器可以是随机存取存储器(RAM),其中它的地址位可以是HPr0SN的最后几位(例如6、8或者10位)。
然而,在替代性示例实施例中,HPr0SN可以用于对所有层的分组计数。在这种实施例中,下一跳的RTCP可以独立于丢失分组的层,通过请求丢失分组的重传来响应丢失分组,只要其发生在来自前一跳的段中。
第三个序列号可以被称为原始序列号(OSN)。OSN由压缩流的源端控制,并且遍及所有跳,OSN都将保持不变。对于每个发送分组,独立于其优先级,在由分组携带的可伸缩层上独立地增加OSN。OSN使流的目的端处的RTP处理器能够在将分组发送到视频解码器之前将这些分组组织起来,其中压缩SC流在该目的端上被解码。
本领域通常技术人员将认识到,尽管公开的实施例涉及时间可伸缩性;但本公开不限于时间可伸缩性,而是对于其它类型的可伸缩性也是可以实现的,举例来说,诸如空间可伸缩性。
所公开系统的实施例可以将丢失分组的重传仅限于具有高优先级(Pr0)的分组。因此,所公开的系统和方法可以减小带宽消耗,并且减少对于内帧的重传请求,以改进与会者的体验。
考虑到附图和详细说明,本发明的这些方面和其它方面将会是显而易见的。前述概要并非意味着概括了本公开的每个潜在实施例或每个方面,并且通过阅读实施例的详细说明、附图和所附权利要求,本公开的其它特征和优点将变得显而易见。
此外,尽管详细描述了特定示例实施例,以向本领域通常技术人员说明本发明构思,但这些实施例容易受到各种修改和具有可替换形式。因此,附图和所记载的说明并非意味着以任何方式限制本发明构思的范围。
附图说明
图1A示出了根据一个或多个公开实施例的在使用3层时间可伸缩性时30F/s的压缩视频流可能SC结构的示例示意图;
图1B示出了根据示例实施例的包括多种电子视频会议系统的多媒体会议系统100;
图2A描述了根据示例实施例的发送端点的示例RTP处理器的相关元件的框图;
图2B描述了根据示例实施例的接收端点的示例RTP处理器的相关元件的框图;
图3A描述了根据中间媒体跳的实施例的中间媒体跳的发送RTP处理器的实施例的相关元件的框图;
图3B描述了根据中间媒体跳的实施例的中间媒体跳的接收RTP处理器的实施例的相关元件的框图;
图4示出了发送EP-RTP处理器的实施例的发送任务的相关模块的流程图;
图5A和5B示出了可以由在压缩SC流的目的端端点处的示例RTP处理器的接收部实现的接收方法的相关模块的流程图;
图6示出了在接收压缩SC流时可以由中间媒体跳的示例RTP处理器实现的示例方法的相关模块的流程图;和
图7示出了在发送压缩SC流时可以由中间媒体跳的示例RTP处理器实现的示例方法的相关模块的流程图。
具体实施方式
现在转到附图,描述了本公开的不同实施例,其中遍及几个图,同样的标号表示同样的元件。为了方便起见,只有相同组的某些元件被标记了标号。附图的目的是描述不同的实施例,而不是为了制造。因此图中所示特征的选择仅仅是为了方便和清楚的呈现。而且,本公开中使用的语言的选择主要是为了可读性和指导性的目的,而不是为了叙述或限制本发明的主题,确定该发明的主题必需依赖于权利要求。
说明书中提到“一个实施例”或者“一实施例”意指与实施例结合所描述的特定特征、结构或者特性包含在本发明的至少一个实施例中,并且多次提到“一个实施例”或者“一实施例”不应该被理解为全部都必需指示相同的实施例。
尽管下面的一些描述中记载了与软件或者固件有关的术语,但实施例可以按需用软件、固件或者硬件,包括软件、固件和硬件的任意组合,来实现本文中所描述的特征和功能。在下面的描述中,单词“单元”、“元件”、“模块”和“逻辑模块”可以相互替换地使用。任何被指定为单元或者模块的东西可以是独立的单元或者专用或集成模块。单元或者模块可以是模块化的或者具有模块化方面,以允许其可以被简单地移除或者由另一相似的单元或者模块代替。每个单元或者模块可以是软件、硬件和/或固件中的任一个,或者是它们的任意组合,最终导致一个或多个处理器被编程来执行单元或者模块所有的功能。另外,相同或者不同类型的多个模块可以由单处理器来实现。逻辑模块的软件可以包含在计算机可读介质上,诸如读/写硬盘、CDROM、闪存、ROM、或者其它存储器或者存储器等等。为了执行某个任务,按需将软件程序加载到合适的处理器。在本公开中,术语任务、方法和处理可以相互替换地使用。
图1A示出了在使用3层时间可伸缩性时30F/s的SC压缩视频流的压缩帧之间的关系。参见以上针对图1A的讨论。
图1B示出了根据本公开一个实施例的多媒体会议系统100。系统100可以包括网络110、一个或多个媒体中继MCU(MRM)120和多个媒体中继端点(MRE)130。在系统100的其它实施例中,MRM120可以是多点控制单元(MCU),且多个MRE130可以是视频会议端点(EP)。网络110可以是任何分组交换网络、IP网络,或者它们的任意组合。会话管理通信可以基于诸如H.323、SIP等的协议,媒体传输协议可以基于带RTCP的RTP,并可以使用媒体压缩标准,诸如音频压缩标准G.711和G.719和/或用于视频流和多质量流的视频压缩标准:H.264AVC、H.264附件G、MPEG-4等等。
每个EP或者MRE 130能够提供至另一端点130或者MCU 120的实时、双向音频和/或视频通信。EP130可以是会话中的与会者的终端,其能够从MCU接收压缩媒体并根据来自MCU的指令传递压缩音频和视频数据。视频会议端点和MCU的常规操作对于本领域通常技术人员来说是公知的,因而在此将不再进一步地描述。
示例MRE 130可以向MRM传递一个或多个压缩视频流,并从MRM 120接收一个或多个所选压缩视频流。MRE对接收的一个或多个压缩视频流进行解码,并可以将解码后的流加入显示在MRE 130的屏幕上的视频图像。MRM 120是媒体中继MCU,其从多个MRE 130接收多个压缩视频流,选择一个或多个压缩视频流集合并向参与媒体中继会议(MRC)会话的多个MRE 130中继一个或多个压缩视频流集合。希望了解更多关于MRE、MRM和MRC的信息的读者可以阅读公开号为US2010/0,194,847的美国专利申请,其内容通过引用而并入本文中。
除了上面公开的示例EP或MRE 130的常规操作之外,EP/MRE 130还可以被配置为包括两类RTP处理器。一类RTP处理器可以被称为发送-端点-RTP处理器(TERP)。每个TERP可以被可通信地耦合在视频流的编码器(图中未示出)与端点的网络接口卡(图中未示出)之间。TERP的实施例可以获得压缩视频网络抽象层(NAL)数据单元的流,将NAL单元汇聚到RTP分组中,并在将RTP分组发送到网络接口之前增加扩展RTP报头至RTP分组。并行地,携带最高优先级层(Pr0)的压缩视频的RTP分组可以被存储在临时存储器中。在发送端点和下一媒体跳之间丢失Pr0分组(即,分组丢失)的情况下,存储的分组可以被用于重传。
扩展RTP报头可以包括通用RTP报头的字段,诸如序列号(SN)、时间戳等等的字段。另外,扩展RTP报头可以包括附加的4个字段的扩展,其由所公开技术的示例实施例使用。一个字段,被称为PrID,可以指示由RTP分组携带的压缩视频层的优先级等级。其中Pr0指示最高优先级。另一个字段可以分配给序列号,其被称为原始序列号(OSN)。遍及所有中间媒体跳,OSN将保持不变。对于分组的第一次传输,独立于该分组优先级,TERP增加OSN。OSN使流的目的端的RTP处理器能够在发送分组至视频解码器(未示出)之前将这些分组组织起来,压缩SC流在该RTP处理器中被解码。
下一个字段可以被分配给另一个新的序列号,其可以针对携带关键帧(Pr0帧)的压缩数据的每个RTP分组而被增加。在从源EP的TERP至RTP分组的接收端点的所有路径上,该字段的值保持不变。该序列号可以被称为原始-Pr0-序列号(OPr0SN)。针对第一次发送的每个关键(Pr0)RTP分组,增加OPr0SN。OPr0SN使连接到SC流的目的端的解码器的RTP处理器(图中未示出)能够识别丢失的Pr0分组。如果发现关键分组,诸如BL(T0)分组,被丢失,可以生成对于内帧(I帧)的请求。
第4个字段可以被分配给被称为跳-Pr0-序列号(HPr0SN)的序列号。可以由沿着流的路径的每个媒体跳替换HPr0SN。HPr0SN使在下一媒体跳处的RTP处理器能够识别在该段上丢失的Pr0分组。然后,HPr0SN值可以被该媒体跳使用来请求重传丢失的一个或多个关键分组。在下面结合图2A和图4公开了TERP实施例的更多详细信息。
第二类RTP处理器可以被称为接收-端点-RTP处理器(RERP)。示例RERP可以被可通信地耦合在端点的网络接口卡(图中未示出)和端点处的视频流的解码器(图中未示出)之间。RERP的实施例可以获得携带压缩视频NAL数据单元的RTP分组的流。RERP的实施例可以解析扩展RTP报头。基于HPr0SN的值,RERP可以确定关键分组是否在最后的媒体跳和接收EP之间的最后网络段中丢失。如果是,则向最后的媒体跳发送重传请求。
RERP可以根据扩展RTP报头的OSN字段将接收到的RTP分组组织起来,OPr0SN可以被检查以确定关键分组是否丢失,如果是,对内帧的请求可以被发送至作为该流的源端的编码器(图中未示出)。组织好的RTP分组可以被解析成压缩NAL数据单元。压缩NAL数据单元可以被发送至解码器(图中未示出)。适用于处理扩展RTP报头的示例MRE130可以包括多个RERP,每一个从MRM120中继的压缩视频流对应一个RERP。在下面结合图2B和图5A-5B公开了RERP的实施例的更多详细信息。
根据本公开配置的MCU的实施例可以包括多个RERP模块和多个TERP模块。每个RERP模块可以被可通信地耦合在分配给端点的网络接口卡(图中未示出)和包括解码器的输入端口(图中未示出)之间。输入端口也被分配给该端点。每个RERP可以执行与上面公开的EP的RERP单元相似的任务。来自输入端口解码器的解码视频可以被传送到输出端口。输出端口可以获得来自多个输入端口的解码视频,裁剪解码视频并组成CP视频图像。CP视频图像可以被输出端口的SC视频编码器(图中未示出)压缩。每个输出端口可以被分配给接收EP。
来自每个输出端口的压缩CP视频图像的NAL数据单元可以被传送到TERP模块,其被分配给相同的接收EP作为输出端口,并被可通信地耦合到被分配给相同EP的网络接口卡(图中未示出)。如上面公开的,每个TERP可以执行与EP的TERP单元相似的任务。
根据本公开配置的MRM120的实施例可以包括一个或多个中间-媒体-跳-接收-RTP处理器(IMHRRP)和一个或多个中间-媒体-跳-发送-RTP处理器(IMHTRP)。每个IMHRRP可以被分配给从MRE 130接收的压缩SC视频流,并可以被中继至一个或多个其它MRE。在通用RTP处理器的其它任务中,IMHRRP的实施例可以从所分配的MRE获得压缩SC视频的RTP分组,并解析扩展RTP报头。基于HPr0SN字段,可以确定关键分组是否在最后一段丢失。如果是,IMHRRP可以基于HPr0SN发送重传请求至之前的媒体跳。IMHTRP的实施例可以检查扩展报头的PrID字段。如果Pr0ID字段是Pr0,则IMHTRP可以增加其HPr0SN并用IMHTRP的HPr0SN计数器的新值代替RTP报头中的HPr0SN字段的值。如果Pr0ID值不是Pr0,则HPr0SN计数器不增加,其前一个值被载入到扩展RTP报头的HPr0SN字段。SN值可以被新的值代替,并且RTP分组可以被传送至一个或多个MRE130。携带最高优先级层(Pr0)的压缩视频的RTP分组可以被存储在临时存储器中。如果在MRM120和下一媒体跳或者MRE之间丢失了Pr0分组,则存储的分组可以被用于重传。在下面结合图3A-3B、6和7公开了关于MRM120的更多详细信息。
图2A示出了发送EP的一个实施例的发送-EP-RTP-处理器(TERP)200的相关元件的框图。EP可以是通用视频会议端点,其从MCU或者MRE接收CP视频图像,该CP视频图像自身组成CP图像。在其它元件中,MRE的实施例可以包括一个或多个TERP200。每个TERP200可与MRE的编码器(图中未示出)关联。TERP200的实施例可以包括NAL累加器210、RTP报头创建器215、发送缓冲器220、重传Pr0缓冲器(ReX Pr0缓冲器)225、发送RTP管理器230和4个序列计数器235a-d。例如,当相关EP加入视频会议时,每个序列计数器可以被设置为随机生成的数。
一个序列计数器235a可以对通用RTP序列号计数,该计数器可以被称为LastSN,并且对于第一次从端点发送的或者响应于接收到重传请求发送的每个RTP分组,增加LastSN。LastSN的值可以被写入发送RTP分组的报头的SN字段。另一个序列计数器235b可以对由相关EP的关联编码器(图中未示出)压缩的原始RTP分组计数。序列计数器235b可以被称为LastOSN,并且对于第一次从端点发送的每个原始(非重传的)RTP分组增加LastOSN。LastOSN的值可以被写入发送RTP分组的扩展报头的OSN字段。另一个序列计数器235c可以对携带Pr0帧的压缩数据的原始RTP分组计数。序列计数器235c可以被称为LastOPr0SN,并且对于第一次从端点发送的且携带Pr0帧的压缩数据的每个原始(非重传的)RTP分组,增加LastOPr0SN。LastOPr0SN计数器的值可以被写入发送RTP分组的扩展报头的OPr0SN字段。最后一个序列计数器235d可以对从EP发送的且携带Pr0帧的压缩数据的RTP分组计数。该序列计数器235d可以被称为LastHPr0SN,并且对于从端点发送或者重传的且携带Pr0帧的压缩数据的每个原始和重传RTP分组,增加LastHPr0SN。LastHPr0SN计数器的值可以被写入RTP分组的扩展报头的HPr0SN字段。
TERP 200的实施例可以从其关联编码器(图中未示出)接收压缩NAL单元的流。NAL单元的流可以携带具有不同优先级的两个或更多个等级的压缩NAL单元。所获得的NAL单元流可以被汇聚到NAL累加器210,直到满足完成RTP分组的RTP协议的条件。RTP分组的示例条件可以是作为RTP分组的有效载荷携带的字节的数目;另一个条件可以是视频帧的结束,还有另一个条件可以是具有其它优先级等级的NAL等等。当这样的条件发生时,一个或多个汇聚NAL可以作为RTP分组的有效载荷被传送到报头创建器215的队列。
在报头创建器215的一个实施例中,分组的通用RTP报头可以被添加到分组的有效载荷。通用RTP报头的扩展字段可以被设置为指示扩展RTP字段的存在。在其它的字段中,通用RTP报头可以包括写入在时间戳字段中的捕获时间。接下来,LastSN计数器235a的值可以被复制到RTP报头的SN字段等等。
除了通用报头,还可以增加扩展报头字段。可以从编码器接收压缩数据的可伸缩层,分组的优先级等级可以被定义为Pr0、Pr1等等。在一个实施例中,分组的优先级等级可以基于接收的重传请求的频率。当接收到多个重传请求时,只有携带压缩帧的基层的分组可以被定义为Pr0。当接收到少数的重传请求时,携带基层和第一增强层的压缩层的分组可以被定义为Pr0分组。在某些实施例中,根据重传请求频率,可以在会议会话期间改变优先级等级。Pr值可以被存储在扩展RTP报头的Pr字段。
进一步地,3个序列计数器的值,LastOSN、LastOPr0SN和LastHPr0SN(分别为235b、235c和235d)可以被分别复制到扩展RTP报头中的适当字段,字段OSN、OPr0SN和HPr0SN。组成的具有扩展RTP报头的RTP分组可以由报头创建器215经由发送缓冲器220传送到网络接口卡(图中未示出)。其中网络接口卡与压缩视频流相关联。并行地,携带关键帧(Pr0)的压缩视频数据的RTP分组可以被存储在ReX-Pr0缓冲器225中。
ReX-Pr0缓冲器225可以是RAM设备,其中ReX-Pr0缓冲器225中的每个地址可以存储带有扩展RTP报头的Pr0压缩视频的整个RTP分组。存储Pr0RTP分组的地址可以反映分组的扩展RTP报头的HPr0SN字段的最后几个比特。例如,最后几个比特的数量可以是HPr0SN字段的最后6-10位。
发送RTP管理器230可以管理TERP200的整个处理。在RTP连接的发起期间,发送RTP管理器230可以分配和设置4个序列计数器235a-d。每个序列计数器235a-d可以被设置为随机数,并根据发送RTP分组的种类(nature)而增加。在一些实施例中,一个或多个序列计数器可以被设置为特定的数。例如,LastHPr0SN可以被设置为0。另外,RTP管理器可以与RTP连接的接收器侧的RTP管理器模块通信,以控制RTP连接。与连接的接收侧的管理器模块的通信可以通过使用RTCP通信协议来完成。
在会议会话期间,RTP管理器230可以接收来自接收器的RTP管理器的RTCP重传请求。重传请求的例子是可以包括重传请求列表(ReXReqList)。ReXReqList可以具有所请求的Pr0分组的列表。该列表可以包括丢失关键分组(Pr0)的HPr0SN字段的值。基于ReXReqList,RTP管理器230可以搜索ReX-Pr0缓冲器225,查找具有相同HPr0SN值的分组。如果所请求的Pr0分组存储在ReX-Pr0缓冲器225中,则那些分组可以从ReX-Pr0缓冲器225中找回并传送给报头创建器215。
在报头创建器215中,SN和HPr0SN字段可以根据LastSN235a和LastHPr0SN235d计数器的当前值而被更新。扩展RTP报头的OSN和OPr0SN字段的值可以保持不变。然后,LastSN235a和LastHPr0SN235d计数器可以被增加,并且所请求分组可以经由发送缓冲器220被重传。如果一个或多个所请求的Pr0分组不存在于ReX-Pr0缓冲器225中,则RTP管理器230发送内帧请求(Intra request)至关联编码器(图中未示出)。在下面结合图4公开了关于TERP200的操作的更多信息。
现在参考图2B,其示出了接收-EP-RTP处理器(RERP)250的实施例的相关元件的框图。接收EP可以是通用视频会议端点,该端点从MCU或者MRE接收CP视频图像,其自身组成CP图像。在其它元件中,MRE的实施例可以包括一个或多个RERP250。每个RERP250可以与例如直接地或者通过MRM从发送MRE接收的接收压缩流和用于解码接收流的解码器(图中未示出)相关联。RERP250的实施例可以包括抖动缓冲器255、组织OSN缓冲器(OOSNB)260、关键层验证器262、NAL缓冲器265、RTP报头解析器270和接收RTP管理器275。
RERP250的实施例可以从与相关流关联的网络接口卡(图中未示出)获得携带压缩视频NAL数据单元的RTP分组的流。获得的RTP分组可以被存储在抖动缓冲器255中。报头解析器270可以解析存储在抖动缓冲器255中的RTP分组的扩展RTP报头。基于扩展字段PrID和HPr0SN的值,可以判定在该路径中来自最后一个媒体跳的一个或多个Pr0关键分组是否丢失。如果检测到HPr0SN中的空隙,则经由接收RTP管理器275向发送EP的发送RTP管理器230(图2A)发送带有一个或多个丢失Pr0分组的重传列表的请求。
来自抖动缓冲器255的RTP分组可以基于它们的OSN扩展字段的值,被传送和存储到OOSNB260中。关键等级验证器262的实施例可以基于其OSN值,从OOSNB260获得下一个分组,然后扩展RTP报头的OPr0SN字段的值可以被检查,以确定关键分组(Pr0)是否丢失。如果检测到OPr0SN中的空隙,则经由接收RTP管理器275使用RTCP连接向发送EP的关联编码器(图中未示出)发送内帧请求。然后,获得的RTP分组可以被分解为一个或多个NAL单元,NAL单元可以被存储在NAL缓冲器265中。基于它们在NAL缓冲器265中的命令,关联解码器可以获得NAL单元,图中未示出。在通用端点中,关联解码器可以解码接收的压缩CP视频图像,解码的CP视频图像可以被显示在EP显示单元(图中未示出)。在MRE中,来自关联解码器的解码视频图像可以被传送到CP图像创建器(图中未示出),在CP图像创建器中该解码视频图像可以被置于CP视频图像的一段中,并作为CP视频图像的一部分在MRE显示单元上呈现。
接收RTP管理器275可以管理RERP250的整个处理。在发起RTP连接期间,接收RTP管理器275可以分配并设置RERP250的资源。另外,接收RTP管理器275可以经由RTCP连接与RTP连接的发送侧的发送RTP管理器模块通信,以控制RTP连接。例如,发送侧可以是EP、MRE、MCU或者MRM。
在会议会话期间,接收RTP管理器275可以向发送侧的发送RTP管理器发送RTCP重传请求。重传请求的例子可以包括重传请求列表(ReXReqList)。ReXReqList可以有所请求的Pr0分组的列表。该列表可以包括丢失关键分组(Pr0)的HPr0SN字段的值。另外,如果在向关联解码器(图中未示出)传送压缩视频之前检测到丢失关键分组,则接收RTP管理器275可以发送对于内帧的请求。在下面结合图5A-5B公开了关于RERP250的操作的更多信息。
MCU为媒体跳的一个例子,其从多个EP接收多个压缩视频流;解码压缩数据;组成一个或多个CP视频图像;压缩一个或多个CP视频图像并发送一个或多个压缩CP视频图像至多个EP。根据所公开技术的实施例,这样的MCU可以被调整。这样的MCU的实施例可以包括多个RERP250。每个RERP250可以被可通信地置于网络接口卡和与来自EP的压缩视频流关联的解码器之间。另外,MCU的实施例可以包括多个TERP200。每个TERP200可以被可通信地置于编码器和与压缩CP视频流关联的网络接口卡之间,其中压缩CP视频流被发送到一个或多个EP。
图3A描述了根据中间媒体跳的实施例的中间-媒体-跳-发送-RTP处理器(IMHTRP)300的实施例的相关元件的框图。中间媒体跳可以是MRM,其将来自多个MRE的多个压缩视频流中继出去,并将多个压缩视频流中继至多个MRE。在其它元件中,MRM的实施例可以包括一个或多个IMHTRP300。每个IMHTRP300可以与MRM和MRE之间的RTP连接相关联。IMHTRP300的实施例可以包括输入缓冲器310、RTP报头修改器320、媒体跳(MH)发送缓冲器325、MH重传Pr0缓冲器(ReX Pr0缓冲器)330、发送-MH-RTP管理器340和两个MH序列计数器335a、335b。例如,当建立相关RTP时,每个MH序列计数器335a、335b可以被设置为随机生成数。在一些实施例中,一个或多个序列计数器可以被设置为特定的数。例如,LastHPr0SN可以被设置为0。
一个MH序列计数器335a可以对通用RTP序列号计数,该计数器可以被称为LastSN,并且对于从IMHTRP 300第一次发送的、或者响应于接收到重传请求而发送的每个RTP分组,增加LastSN。LastSN的值可以被写入发送RTP分组的报头的SN字段。另一个序列计数器235b可以对从IMHTRP300发送的携带关键帧(Pr0帧)的压缩数据的RTP分组计数。这个序列计数器235b可以被称为LastHPr0SN,并且对于携带从IMHTRP 300发送或者重传的Pr0帧的压缩数据的每个原始或者重传的RTP分组,增加LastHPr0SN。LastHPr0SN计数器的值可以被写入发送RTP分组的扩展报头的HPr0SN字段中。
IMHTRP 300的实施例可以从中间媒体跳的内部元件(图中未示出)接收压缩RTP分组的流,并且目标是相关RTP连接。RTP分组的流可以携带具有不同优先级的两个或更多个层的压缩NAL单元。获得的RTP分组可以被存储在输入缓冲器310中,报头修改器320可以从输入缓冲器310取出每个RTP分组。
在报头修改器320的一个实施例中,分组的RTP报头可以被修改。MH LastSN计数器335a的值可以被写入RTP报头的SN字段中,替代之前的值,等等。序列计数器MHLastHPr0SN335b的值可以被写入扩展RTP报头的HPr0SN字段,替代之前的值。可以在第一次向相关连接发送分组时或者针对重传分组,进行HPr0SN字段的修改。可以从报头修改器320经由MH发送缓冲器325向网络接口卡(图中未示出)发送具有扩展RTP报头的RTP分组。网络接口卡可以与相关RTP连接相关联。并行地,携带关键帧(Pr0)的压缩视频数据的RTP分组可以被存储在MH ReX-Pr0缓冲器330中。
MH ReX-Pr0缓冲器330可以是RAM设备,其中MH ReX-Pr0缓冲器330的RAM中的每个地址可以存储Pr0压缩视频和扩展RTP报头的整个RTP分组。可以存储Pr0RTP分组的地址可以反映分组的扩展RTP报头的HPr0SN字段的最后几位。例如,最后几位的数目可以是HPr0SN字段的最后6-10位。
发送-MH-RTP管理器340可以管理IMHTRP300的整个处理。在RTP连接的发起期间,发送-MH-RTP管理器340可以分配和设置两个MH序列计数器335a、335b。每个MH序列计数器335a、335b可以被设置为随机数或者是0,并根据发送RTP分组的种类而增加。另外,MH RTP管理器340可以与RTP连接的接收器侧的RTP管理器模块通信,以控制RTP连接。可以使用RTCP通信协议来完成与连接的接收侧的管理器模块的通信。
在会议会话期间,MH RTP管理器340可以从连接的接收器侧的RTP管理器接收RTCP重传请求。重传请求的例子可以包括重传请求列表(ReXReList)。ReXReList可以具有所请求的Pr0分组的列表。该列表可以包括丢失关键分组(Pr0)的HPr0SN字段的值。基于ReXReList,MH RTP管理器340可以搜索MH ReX-Pr0缓冲器330,以查找具有相同HPr0SN值的分组。如果所请求的Pr0分组被存储在MH ReX-Pr0缓冲器330中,则那些分组可以从MH ReX-Pr0缓冲器330找回,并向报头修改器320传送。
在报头修改器320中,SN和HPr0SN的字段可以根据MH LastSN335a和MHLastHPr0SN335b计数器的当前值而被更新。扩展RTP报头的OSN和OPr0SN字段的值保持不变。然后,MHLastSN335a和MH LastHPr0SN335b计数器可以被增加,并且所请求分组可以经由MH发送缓冲器325而被重传。如果一个或多个所请求的Pr0分组不存在于MH ReX-Pr0缓冲器330中,则MHRTP管理器340可以发送内帧请求至发起相关流的端点。在一些实施例中,一个或多个序列计数器可以在更新RTP报头中的相关字段之前被增加。在下面结合图7公开了关于IMHTRP300操作的更多信息。
现在参考图3B,示出了中间-媒体-跳-接收-RTP处理器(IMHRRP)350的实施例的相关元件的框图。中间媒体跳可以是MRM,其从多个MRE中继多个压缩视频流,并中继多个压缩视频流至MRE。在其它元件中,MRM的实施例可以包括一个或多个IMHRRP350。每个IMHRRP350可以与MRM和发送MRE或者沿路径的另一个MRM之间的RTP连接相关联。IMHRRP350的实施例可以包括缓冲器360、MH-RTP-报头解析器370和MH-接收-RTP管理器380。
IMHRRP 350的实施例可以从与相关RTP连接关联的网络接口卡(图中未示出)获得携带压缩视频NAL数据单元的RTP分组的流。所获得的RTP分组可以被存储在缓冲器360中。例如,缓冲器360可以是循环存储器,用于存储多个获得的RTP分组。
MH-报头解析器370可以从缓冲器360取得下一个RTP分组,解析取得的RTP分组的扩展RTP报头,并传送取得的RTP分组至中间媒体跳的内部单元(图中未示出)。
基于扩展字段PrID和HPr0SN的值,MH报头解析器370的实施例可以确定是否在路径的最后一段中来自发送MRE或MRM的Pr0分组,即关键分组,丢失。
如果检测到HPr0SN中的间隙,接收-MH-RTP管理器380可以确定哪一个或者哪些关键分组丢失,并且可以经由接收-MH-RTP管理器380通过RTCP连接向发送MRE的发送RTP管理器230(图2A)或者前一中间MH的发送MH RTP管理器340发送具有一个或多个丢失Pr0分组的重传列表的请求。
接收-MH-RTP管理器380可以管理IMHRRP 350的整个处理。在RTP连接的发起期间,接收-MH-RTP管理器380可以分配和设置IMHRRP 350的资源。另外,接收-MH-RTP管理器380可以与发送RTP管理器模块230(图2A)或者RTP连接的发送侧的发送MH-RTP管理器340经由RTCP连接通信,以控制RTP连接。
在会议会话期间,接收-MH-RTP管理器380可以(分别地)发送RTCP重传请求至发送EP或者媒体跳的发送-RTP管理器230或者340。重传请求的例子可以包括重传请求列表(ReXReqList)。ReXReqList可以具有所请求的Pr0分组的列表。该列表可以包括丢失关键分组(Pr0)的HPr0SN字段的值。在下面结合图6公开了关于IMHRRP350的操作的更多信息。
现在参考图4,示出了发送-EP-RTP-处理器(TERP)200的发送任务400的相关模块的流程图。TERP200可以与作为压缩SC流的源端的EP或者MRE相关联,该压缩SC流在与TERP200关联的RTP连接上传送。方法400可以在建立发送EP/MRE和下一媒体跳之间的RTP连接期间被发起402。RTP连接可以在建立会议会话期间或者在加入正在进行的会话时被发起。
在发起之后,TERP200的资源可以被分配404和设置。例如,4个序列计数器235a-235d(图2A)可以被分配。例如,每个计数器(LastSN、LastOSN、LastOPr0SN和LastHPr0SN)可以被设置为随机数或者0。另外,诸如但不限于ReX-Pr0缓冲器225(图2A)的缓冲器可以被分配和重置,诸如LastIDR的寄存器可以被分配和重置,等等。
下一发送-RTP管理器230(图2A)可以检查410Rex请求列表中的条目是否存在于其队列中。如果否,方法400可以进行至模块412。如果在410,Rex请求存在,则可以找回请求并清除该条目,所找回的请求可以被解析,并且在430判定所请求的HPr0SN的值是否比存储在LastIDR寄存器中的值小。LastIDR寄存器存储携带Pr0内帧的起始部分的第一分组的HPr0SN字段的值。如果在430,该值较小,这表明内帧已经在由丢失分组携带的压缩Pr0视频数据之后被发送,则不需要重传丢失分组,并且方法400可以返回模块410。
如果在430,该值不是较小,则ReX-Pr0缓冲器225(图2A)可以被检查432,并判定所请求的Pr0分组是否存在于ReX-Pr0缓冲器225中。如果所请求分组不存在于ReX-Pr0缓冲器225中,则解码器刷新请求(内帧请求)被发送436至相关流的编码器,且方法400返回模块410。如果在432,请求列表中提及的Pr0分组存在于ReX-Pr0缓冲器225中,则所请求的Pr0分组被取得,并从ReX-Pr0缓冲器225中移除434,并且方法400进行至模块440,以处理所取得的所请求分组。
现在回到模块410,如果在ReX请求列表中不再有条目,则NAL累加器210(图2A)可以被检查412以确定414是否有足够的字节用于RTP分组的有效载荷。如果在414,没有足够的字节,则方法400可以返回模块410以便能够汇聚来自相关编码器的附加NAL单元。如果在414有足够的字节用于RTP分组的有效载荷,则通过从NAL累积器210取得NAL单元而组装成有效载荷,并且该有效载荷被传送到报头创建器215(图2A)用于将RTP报头以及扩展报头组装到有效载荷,以建立416RTP分组。可以根据从编码器接收的信息而设置PrID。
OSN序列计数器LastOSN的值可以被增加,并且LastOSN的新值可以被写入418到扩展RTP报头的OSN字段中。接着,在420判定有效载荷的内容是否包括Pr0帧,即关键帧,的压缩视频。如果否,则LastOPr0SN的值保持不变,其值被复制428至扩展RTP报头的OPr0SN字段,且方法400进行到模块442。
如果在420,RTP分组的有效载荷携带关键帧的压缩数据,则LastOPr0SN计数器的值被增加422,并且新值被复制到扩展RTP报头的OPr0SN字段。接着,基于压缩视频数据的解析报头,在424判定RTP分组是否携带内帧的起始部分。如果不是,方法400进行到模块440。如果是,则序列计数器LastPr0SN的值加1被复制426到寄存器LastIDR,其在模块430中被用于处理重传请求,且方法400进行到模块440。
在模块440,序列计数器LastPr0SN被增加。序列计数器LastPr0SN的值被复制422到扩展RTP报头的HPr0SN字段,并且序列计数器LastSN被增加442,且LastSN的新值被复制到RTP报头的SN字段。
基于扩展RTP报头的Pr0ID字段,在450判定分组是否携带关键帧的数据。如果在450为否,则方法400进行到模块454并经由网络接口卡(图中未示出)在相关RTP连接上发送新的RTP分组至下一个媒体跳。在发送RTP分组之后,方法400返回到模块410,启动新的循环。如果在450,分组携带关键帧的数据,则方法400在ReX Pr0缓冲器255(图2A)中存储452RTP分组的副本,并经由网络接口卡(图中未示出)在相关RTP连接上发送454新的RTP分组至下一个媒体跳。然后,方法400返回模块410,启动新的循环。在RTER200(图2A)的一些实施例中,RTP分组存储在ReX Pr0缓冲器255中的地址可以反映分组的扩展RTP报头的HPr0SN字段的值。
图5A示出了示例组织方法500的相关模块的流程图。组织方法500可以由接收-EP-RTP-处理器(RERP)250的实施例来实现。RERP250可以与压缩SC流的目的端处的接收EP或者接收MRE相关联,压缩SC流通过与RERP250相关的RTP连接被传送。方法500可以在建立接收EP/MRE和前一媒体跳之间的RTP连接期间被发起502。RTP连接可以在建立会议会话期间或者在将接收EP加入到正在进行的会话时被发起。
在发起之后,RERP 250的资源可以被分配504和设置。可以分配和重置资源,诸如但不限于OOSNB 260(图2B)、NAL缓冲器262、抖动缓冲器255、寄存器N、寄存器Last_Pr0等等。
可以从抖动缓冲器255(图2B)取得下一个接收RTP分组。分组的扩展RTP报头可以被解析506,并且HPr0SN和PrID字段的值可以被找回。找回的HPr0SN值和写入在寄存器Last_Pr0中的值之间的差可以被计算508,并且结果可以被存储到寄存器‘N’中。
在将差值存储在‘N’中之后,在510判定‘N’的值是否小于或等于0。如果该值小于或等于0,这表明在路径上从最后一个媒体跳和接收EP乱序接收到分组,那么在512另外判定取得的PrID的值是否为0,这表明当前分组是否携带关键帧的数据。如果在512为是,则可以检查514重传请求列表(ReXReqList),并且对于具有相同HPr0SN值的重传RTP分组的请求可以从重传请求列表中被移除。然后方法500可以进行到模块530。如果在512取得的PrID的值不是0,这表明其不是关键分组,则方法500可以进行到模块530。
在模块530上,接收RTP管理器275(图2B)可以在RTCP连接上发送基于ReXReqList的重传请求至在RTCP连接的另一侧上的RTP管理器。然后,接收的RTP分组可以被转发532至OOSNB 260(图2B),由方法5000(图5B)处理,方法500返回模块506。
在一些实施例中,每当接收到内帧时就清除列表,或者基于列表中每个条目的年龄清除列表,等等。然而在一些实施例中,在模块532复制分组,即具有相同OSN的分组,可以从OOSNB 260(图2B)中丢弃。
现在返回模块510,如果‘N’的值大于0,则在516判定取得的PrID的值是否为0,这指示当前分组携带关键帧的数据。如果在516 PrID不为0,这表明来自前一媒体跳的一个或多个关键分组沿着最后一段丢失,然后可以更新518 ReXReqList。该更新可以通过写所请求分组的列表来完成,所请求分组的扩展RTP报头的HPr0SN字段的值等于存储在Last_Pr0寄存器中的值加上1、加上2、加上3...直到加上存储在寄存器‘N’中的值。在更新ReXReqList之后,替代寄存器Last_Pr0的前一个值,存储524当前接收的RTP分组的扩展RTP报头的HPr0SN字段的值,方法500进行到模块530。
如果在516,取得的PrID的值为0,这表明当前分组携带关键帧的数据,则在520另外判定‘N’的值是否等于1。如果在520为是,这表明没有关键分组丢失,则方法500可以进行到模块524。如果在520为否,这表明直到这个一,一个或多个关键分组已丢失,因此可以更新522 ReXReqList。该更新可以通过写所请求分组的列表来完成,所请求分组的扩展RTP报头的HPr0SN字段的值等于存储在Last_Pr0寄存器的值加上1、加上2、加上3...直到加上存储在寄存器‘N’中的值减1。在更新ReXReqList之后,替代寄存器Last_Pr0的前一个值,存储524当前接收的RTP分组的扩展RTP报头的HPr0SN字段的值,并且方法500进行到模块530。
图5B显示了Pr0验证方法5000的实施例的例子的相关模块的流程图。Pr0验证方法5000可以由接收-EP-RTP-处理器(RERP)250的一个实施例来实现。RERP 250可以与压缩SC流的目的端上的接收EP或者接收MRE相关联,该压缩SC流经与RERP250关联的RTP连接而被传送。方法5000可以在建立接收EP/MRE和前一媒体跳之间的RTP连接期间被发起550。RTP连接可以在建立会议会话期间或者在将接收EP加入到正在进行的会话时而被发起。
在发起之后,涉及方法5000的RERP 250的资源可以被分配522和设置。可以分配和重置资源,诸如但不限于:关键级别验证器262(图2B)、寄存器和诸如但不限于OOSNB260(图2B)、NAL缓冲器262、寄存器M、寄存器Last_OPr0等等的缓冲器。
来自OOSNB 260(图2B)的下一个接收的RTP分组可以被取得。分组的扩展RTP报头可以被解析554,且OPr0SN和PrID字段的值可以被找回。OPr0SN的找回值和写入在寄存器Last_OPr0中的值之间的差可以被计算556,其结果可以被存储在寄存器‘M’中。
在将差值写入在寄存器‘M’中之后,在560判定取得的PrID的值是否为0,这指示当前分组携带关键帧的数据。如果在560为是,则在564另外判定‘M’的值是否等于1。如果在564为是,这表明从接收的压缩视频流的原始源端直到压缩视频流的接收目的端,没有丢失关键分组,则替代寄存器Last_OPr0的前一个值,写入570当前接收的RTP分组的扩展RTP报头的OPr0SN字段的值,且方法5000进行到模块572。在模块572,接收的RTP分组可以被转发至NAL缓冲器265(图2B),RTP分组可以从NAL缓冲器265被转发至接收EP的解码器。解码器可以处理压缩视频流,其被承载在相关的RTP连接上。然后,方法5000返回至模块554,以在OOSNB260中处理下一个RTP分组。
如果在560取得的PrID的值不为0,这表明当前分组不是关键分组,则在562另外判定‘M’的值是否等于0。如果在562为是,这表明从接收的压缩视频流的原始源端直到压缩视频流的接收目的端,没有丢失关键分组,则替代寄存器Last_OPr0的前一个值,写入570当前接收的RTP分组的扩展RTP报头的OPr0SN字段的值,并且方法5000进行到模块572。在模块572,接收RTP分组可以被转发至NAL缓冲器265(图2B),RTP分组可以从NAL缓冲器265被转发至接收EP的解码器。解码器可以处理压缩视频流,其被承载在相关的RTP连接上。然后,方法5000返回至模块554,以在OOSNB 260中处理下一个RTP分组。
现在返回模块564或者562,如果寄存器‘M’的值分别不等于1或者0,这表明丢失了一个或多个关键分组,并且内帧请求可以由接收RTP管理器275(图2B)发送568。内帧请求可以通过RTPC连接被发送至相关压缩视频流的源端的发送RTP管理器。内帧请求可以通过一个或多个中间媒体跳被传送。然后,方法5000可以进行到模块570。
在方法5000的一些实施例中,在将RTP分组转发572至解码器之后,处理可以等待一段时间,以便克服发送帧内的抖动。等待时期可以在几毫秒的范围内,例如在5至20毫秒之间。
图6示出了示例中间-媒体-跳-接收方法600的相关模块的流程图。方法600可以由IMHRRP350(图3B)的实施例来实现。IMHRRP350可以与位于压缩视频流的源端和该压缩SC视频流的接收目的端之间的中间-媒体-跳相关联。例如,中间-媒体-跳可以是位于两个或更多个MRE之间的MRM。方法600可以在建立媒体跳和EP/MRE之间的RTP连接期间被发起602,该EP/MRE是视频SC流或者前一媒体跳的源端。例如,可以在建立会议会话期间或者在将发送EP/MRE加入到正在进行的会话中发起RTP连接。
发起之后,IMHRRP 350的资源可以被分配604和设置。可以分配和重置资源,诸如但不限于缓冲器360(图3B)、寄存器N’、寄存器Last_Pr0'等等。可以从缓冲器360(图3B)取得下一个接收RTP分组。分组的扩展RTP报头可以被解析606,HPr0SN和PrID字段的值可以被找回。HPr0SN的找回值和写入在寄存器Last_Pr0中的值之间的差可以被计算608,其结果可以被存储在寄存器N’中。
在将差值存储在N’中之后,可以在610判定N’的值是否小于或等于0。如果该值小于或等于0,这表明在路径上从最后一个媒体跳和接收EP乱序接收到分组,那么可以在612另外判定取得的PrID的值是否为0,这表明当前分组携带关键帧的数据。如果在612为是,则可以检查614重传请求列表(ReXReqList),并且时于具有相同HPr0SN值的重传RTP分组的请求可以从重传请求列表中被移除。然后方法600可以进行到模块630。如果在612取得的PrID的值不是0,这表明不是关键分组,则方法600可以进行到模块630。
在模块630,可以在RTCP连接上从接收MH-RTP管理器380(图3B)发送基于ReXReqList的重传请求至在RTCP连接的另一侧的RTP管理器。然后,接收的RTP分组可以被转发632至媒体跳的一个或多个其它内部单元(图中未示出),并且方法600返回模块606以处理缓冲器360中的下一个RTP分组。在一些实施例中,可以在每次接收到内帧时,或者基于列表中每个条目的年龄等等,清除ReXReqList。在另一些实施例中,在模块630复制分组,即具有相同OSN的分组,可以从OOSNB260(图2B)中被丢弃。
现在返回模块610,如果‘N”的值大于0,则判定616取得的PrID的值是否为0,这指示当前分组携带关键帧的数据。如果在616,PrID不为0,这表明来自前一媒体跳或EP/MRE的一个或多个关键分组沿着最后一段丢失,则可以更新618ReXReqList。该更新可以通过写所请求分组的列表来完成,所请求分组的扩展RTP报头的HPr0SN字段的值等于存储在Last_Pr0'寄存器中的值加上1、加上2、加上3...直到加上存储在寄存器‘N”中的值。在更新ReXReqList之后,替代寄存器Last_Pr0’的前一个值,存储624当前接收的RTP分组的扩展RTP报头的HPr0SN字段的值,并且方法600进行到模块630。
如果在616,取得的PrID的值为0,这表明当前分组携带关键帧的数据,则另外判定620‘N”的值是否等于1。如果在620为是,这表明没有关键分组丢失,则方法600可以进行到模块624。如果在620为否,这表明直到这个一,一个或多个关键分组已丢失,因此可以更新622ReXReqList。该更新可以通过写所请求分组的列表来完成,所请求分组的扩展RTP报头的HPr0SN字段的值等于存储在Last_Pr0'寄存器中的值加上1、加上2、加上3...直到加上存储在寄存器‘N”中的值减1。在更新ReXReqList之后,替代寄存器Last_Pr0的前一个值,存储624当前接收的RTP分组的扩展RTP报头的HPr0SN字段的值,并且方法600进行到模块630。
图7示出了中间-媒体-跳-发送方法700的例子的相关模块的流程图。方法700可以由IMHTRP300(图3A)的实施例来实现。IMHTRP300可以与位于压缩视频流的源端和该压缩SC视频流的接收目的端之间的中间-媒体-跳相关联。例如,中间-媒体-跳可以是位于两个或更多个MRE之间的MRM。方法700可以在建立媒体跳和EP/MRE之间的RTP连接期间被发起702,该EP/MRE是视频SC流的目的端或者下一媒体跳。例如,RTP连接可以在建立会议会话期间或者在将发送EP/MRE加入到正在进行的会话时而被发起。
发起之后,IMHTRP300的资源可以被分配704和设置。例如,两个MH序列计数器335a-335d(图3A)可以被分配。每个计数器(LastSN和LastPr0SN)可以被设置为随机数或者0。另外,诸如但不限于MH-ReX-Pr0缓冲器330(图3A)的缓冲器可以被分配704和重置,诸如LastIDR的寄存器可以被分配和重置,等等。
接着,MH-发送-RTP管理器340(图3A)可以检查710Rex请求条目是否在其队列中。如果不是,方法700可以进行到模块712。如果在710ReX请求条目被找到,则找回该请求并清除条目,找回的请求被解析,并且基于所请求的HPr0SN的值是否小于存储在LastIDR寄存器中的值,进行判定720。LastIDR寄存器存储携带Pr0内帧的起始部分的第一分组的HPr0SN字段的值。如果在720该值较小,这表明内帧已经被发出,并可以在创建由丢失分组携带的压缩Pr0视频数据之后被接收,因此不需要重传丢失分组,并且方法700可以返回模块710。
如果在720,该值不是较小,则MH-ReX-Pr0缓冲器330(图3A)可以被检查722,并且基于在列表的条目中所提及的Pr0分组是否存在于MH-ReX-Pr0缓冲器330中进行判定。如果所请求的分组不存在于MH-ReX-Pr0缓冲器330中,则解码器刷新请求(内帧请求)可以通过RTP连接被发送726至压缩SC视频流的源端,并且方法700返回至模块710。如果在722,在请求列表的条目中提及的Pr0分组存在于MH-ReX-Pr0缓冲器330中,则所请求的Pr0分组可以被取得并从ReX-Pr0缓冲器330中移除724,且方法700可以进行到模块730,以处理取得的所请求分组。
现在返回模块710,如果队列中没有未决的ReX请求,则输入缓冲器310(图3A)可以被检查712,且来自IMHTRP300的内部模块(图中未示出)的下一个RTP分组可以被取得。RTP报头和取得的分组的扩展报头可以被解析,且HPr0SN字段和PrID的值可以被找回712。接着,在714判定有效载荷的内容是否包括Pr0帧(即关键帧)的压缩视频。如果在714为否,则方法700可以进行到模块732。
如果在714,分组携带关键帧的数据,则RTP分组的报头可以被检查以确定716RTP分组是否携带新的关键内帧的起始部分。如果在716,分组没有携带新的关键内帧的起始部分,则方法700进行到模块730。如果在716,分组携带新的关键内帧的起始部分,则LastPr0SN的值加上1的和可以被写入718寄存器LastIDR,替代寄存器LastIDR的前一数据。
在模块730,序列计数器LastPr0SN可以被增加。序列计数器LastPr0SN的值可以被写入732扩展RTP报头的HPr0SN字段中。另外,LastSN序列计数器可以被增加734,且新的值可以被写入通用RTP报头的SN字段。
接着,基于扩展RTP报头的Pr0ID字段判定740分组的有效载荷是否携带关键帧的压缩视频。如果否,RTP分组经由网络接口卡(图中未示出)通过相关RTP连接被发送744至下一个媒体跳或者接收EP/MRE。如果在740,分组携带关键帧的压缩视频,则RTP分组的副本可以被存储在MH-ReX-Pr0缓冲器330(图3A)中,并且分组经由网络接口卡(图中未示出)通过相关RTP连接被发送744至下一个媒体跳或者接收EP/MRE。在发送RTP分组至其目的端之后,方法700可以返回至模块710以启动新的循环。
在本公开的说明书和权利要求书中,“包含”、“包括”、“具有”等等以及它们的变化被用于指示动词的宾语不一定是动词的主语的成员、部件、单元、或者部分的完整列表。
如上所述,所公开的实施例可以包括一种方法,包括:在媒体发送设备处获得多个传输协议(TP)分组的流,所述多个TP分组的流携带由可伸缩译码(SC)编码器创建的压缩媒体数据单元,所述多个TP分组中的每一个具有分配的优先级等级,其中所述多个TP分组的流包括至少一个具有第一优先级等级的分组和至少一个具有第二优先级等级的分组;分配第一序列号给所述多个TP分组中每一个TP分组的多个报头字段的第一报头字段,其中对于具有第一优先级等级的每个TP分组,所述第一序列号是改变的;及向一个或多个媒体接收设备发送所述多个TP分组。
同样,SC编码器也可以被包括在始发媒体发送设备中。另外,可以在始发媒体发送设备处分配第二序列号给第二报头字段,所述第二序列号指示具有第一优先级等级的分组的原始序列号。在最后的媒体接收设备处所述第二序列号可以被用来识别来自任一在前网络段的一个或多个丢失的第一优先级等级分组。始发媒体发送设备可以分配第三序列号给第三报头字段,所述第三序列号指示所有TP分组的原始序列号,其中所述第三序列号字段还可以被用于在不考虑优先级等级的情况下对TP分组重新排序。
始发媒体发送设备可以包括具有SC编码器的端点或媒体中继端点(MRE),所述SC编码器对由所述MRE或者甚至是多点控制单元(MCU)生成的媒体进行压缩,并且SC编码器对来自视频图像的持续存在(CP)视频图像进行编码,其中所述视频图像是从多个端点接收的第一序列号可以被第一媒体接收设备使用来识别一个或多个丢失的TP分组,并经由与所述第一媒体接收设备关联的网络段请求重传,其中所述第一媒体接收设备是从一个或多个媒体接收设备中选择的。
另外,公开的方法和系统可以被配置成在源重传缓冲器中存储一个或多个发送的TP分组;从接收设备接收对于重传特定TP分组的请求;在源重传缓冲器中搜索特定TP分组;和响应于所述请求向接收设备重传特定TP分组。可选地,只有具有第一优先级等级的TP分组才被存储在源重传缓冲器中,且重传请求可以从接收TP分组以显示持续存在(CP)的视频图像的端点接收。在一些情况下,如果在源重传缓冲器中没有找到特定TP分组,则从始发媒体发送设备请求内帧会是有益的。当然,上面公开的一些方法可以在包括中间媒体跳的媒体发送设备上实现。
应当理解,上面的描述是说明性的,而不是限制性的。上述的装置、系统和方法可以以很多方式改变,包括改变步骤的顺序和所使用的精确实施方式。所述的实施例包括不同的特征,本公开的所有实施例中并不需要所有的特征。而且,本公开的一些实施例仅使用一些特征或者这些特征的可能组合。本领域的通常技术人员将会想到在所述实施例中记载的特征的不同组合。此外,本公开的一些实施例可以由与根据公开者的不同示例实施例相关联地记载的特征和元件的组合来实现。本发明的范围仅由下列权利要求及其等同限定。

Claims (28)

1.一种媒体发送方法,包括:
在媒体发送设备处获得多个传输协议(TP)分组的流,所述多个TP分组的流携带由可伸缩译码(SC)编码器创建的压缩媒体数据单元,所述多个TP分组中的每一个具有分配的优先级等级,其中所述多个TP分组的流包括至少一个具有第一优先级等级的分组和至少一个具有第二优先级等级的分组;
分配第一序列号给所述多个TP分组中每一个TP分组的多个报头字段的第一报头字段;及
向一个或多个媒体接收设备发送所述多个TP分组;
其中媒体发送设备是始发媒体发送设备和最后的媒体接收设备之间的中间节点;
其中所述第一序列号由沿着流路径的每个中间节点针对第一优先级的每个TP分组替换;
其中所述第一序列号可以被第一媒体接收设备使用来识别在所述媒体发送设备和所述第一媒体接收设备之间的网络段丢失的一个或多个丢失的TP分组,并请求从所述媒体发送设备重传所述丢失的TP分组,其中所述第一媒体接收设备是从一个或多个媒体接收设备中选择的;以及
其中每个第一优先级等级TP分组反映基层帧的压缩视频数据。
2.如权利要求1所述的方法,其中始发媒体发送设备是包括所述SC编码器的媒体发送设备。
3.如权利要求2所述的方法,进一步包括:
在所述始发媒体发送设备处分配第二序列号给第二报头字段,所述第二序列号指示具有第一优先级等级的分组的原始序列号。
4.如权利要求3所述的方法,其中在所述最后的媒体接收设备处所述第二序列号被用来识别来自任一在前网络段的一个或多个丢失的第一优先级等级分组。
5.如权利要求2所述的方法,进一步包括:
在所述始发媒体发送设备处分配第三序列号给第三报头字段,所述第三序列号独立于TP分组的优先级指示TP分组的原始序列号。
6.如权利要求5所述的方法,其中所述第三序列号字段被用于在不考虑优先级的情况下在最终接收设备处对TP分组重新排序。
7.如权利要求2所述的方法,其中所述始发媒体发送设备是具有SC编码器的媒体中继端点(MRE),所述SC编码器对由所述MRE生成的媒体进行压缩。
8.如权利要求2所述的方法,其中所述始发媒体发送设备包括多点控制单元(MCU),并且所述SC编码器对来自视频图像的持续存在(CP)视频图像进行编码,其中所述视频图像是从多个端点接收的。
9.如权利要求1所述的方法,其中所述第一优先级等级包括高优先级等级。
10.如权利要求1所述的方法,其中媒体发送设备或一个或多个媒体接收设备包括多点会议设备。
11.如权利要求1所述的方法,进一步包括:
在源重传缓冲器中存储一个或多个发送的TP分组;
从接收设备接收对于重传特定TP分组的请求;
在所述源重传缓冲器中搜索所述特定TP分组;和
响应于所述请求向接收设备重传所述特定TP分组。
12.如权利要求1所述的方法,其中只有具有第一优先级等级的TP分组被存储在源重传缓冲器中。
13.如权利要求1所述的方法,其中从接收TP分组以显示持续存在(CP)视频图像的端点接收所述重传请求。
14.如权利要求11所述的方法,进一步包括:
如果在所述源重传缓冲器中没有找到所述特定TP分组,则向起始端媒体发送设备请求内帧。
15.如权利要求1所述的方法,其中所述SC编码器按照视频标准进行编码。
16.如权利要求15所述的方法,其中所述视频标准包括H.264附件G(SVC)。
17.如权利要求1所述的方法,其中所述SC编码器执行包括时间可伸缩性的可伸缩译码编码。
18.如权利要求1所述的方法,其中传输协议(TP)包括实时传输协议(RTP)。
19.如权利要求1所述的方法,其中对于被发送或重传的每个具有第一优先级等级的发送TP分组,增加所述第一序列号。
20.一种媒体发送设备,包括:
网络接口;
存储器;和
可通信地耦合到所述网络接口和所述存储器的处理器,其中所述处理器被配置成:
获得多个传输协议(TP)分组的流,所述流携带由可伸缩译码(SC)编码器创建的压缩媒体数据单元,所述多个TP分组的每一个具有分配的优先级等级,其中所述多个TP分组的流包括至少一个具有第一优先级等级的分组和至少一个具有第二优先级等级的分组;
分配第一序列号给所述多个TP分组中每一个TP分组的多个报头字段的第一报头字段,其中所述第一序列号对于具有第一优先级等级的每个TP分组是改变的;及
向一个或多个媒体接收设备经由所述网络接口发送所述多个TP分组;
其中媒体发送设备是始发媒体发送设备和最后的媒体接收设备之间的中间节点;
其中所述第一序列号由沿着流路径的每个中间节点针对第一优先级的每个TP分组替换;
其中所述第一序列号可以被第一媒体接收设备使用来识别在所述媒体发送设备和所述第一媒体接收设备之间的网络段丢失的一个或多个丢失的TP分组,并请求从所述媒体发送设备重传所述丢失的TP分组,其中所述第一媒体接收设备是从一个或多个媒体接收设备中选择的;以及
其中所述SC编码器执行包括至少时间可伸缩性的可伸缩译码编码,其中每个第一优先级等级TP分组反映基层帧的压缩视频数据。
21.如权利要求20所述的媒体发送设备,进一步包括SC编码器。
22.如权利要求20所述的媒体发送设备,其中所述第一优先级等级包括高优先级等级。
23.如权利要求20所述的媒体发送设备,其中媒体发送设备或一个或多个媒体接收设备包括多点会议设备。
24.如权利要求20所述的媒体发送设备,其中所述处理器被进一步配置成分配第二序列号给第二报头字段,所述第二序列号指示具有第一优先级等级的分组的原始序列号。
25.如权利要求24所述的媒体发送设备,其中所述处理器被进一步配置成分配第三序列号给第三报头字段,所述第三序列号指示所有TP分组的原始序列号。
26.如权利要求20所述的媒体发送设备,其中对于被发送或重传的每个具有第一优先级等级的发送TP分组,增加所述第一序列号字段。
27.一种媒体发送方法,包括:
获得多个传输协议(TP)分组的流,所述流携带由可伸缩译码(SC)编码器创建的压缩媒体数据单元,所述多个TP分组的每一个具有分配的优先级等级,其中所述多个TP分组的流包括至少一个具有第一优先级等级的分组和至少一个具有第二优先级等级的分组;
分配第一序列号给所述多个TP分组中每一个TP分组的多个报头字段的第一报头字段,其中所述第一序列号对于具有第一优先级等级的每个TP分组是改变的;及
向一个或多个媒体接收设备发送所述多个TP分组;
在源重传缓冲器中存储一个或多个发送的TP分组;
从接收设备接收对于重传特定TP分组的请求;
在所述源重传缓冲器中搜索所述特定TP分组;和
响应于所述请求向接收设备重传所述特定TP分组;
其中媒体发送设备是始发媒体发送设备和最后的媒体接收设备之间的中间节点;
其中所述第一序列号由沿着流路径的每个中间节点针对第一优先级的每个TP分组替换;
其中所述第一序列号可以被第一媒体接收设备使用来识别在所述媒体发送设备和所述第一媒体接收设备之间的网络段丢失的一个或多个丢失的TP分组,并请求从所述媒体发送设备重传所述丢失的TP分组,其中所述第一媒体接收设备是从一个或多个媒体接收设备中选择的;以及
其中每个第一优先级等级TP分组反映基层帧的压缩视频数据。
28.如权利要求27所述的方法,其中存储一个或多个发送的TP分组进一步包括仅存储具有第一优先级等级的TP分组。
CN201310177406.2A 2012-02-10 2013-02-08 处理多跳rtp流中的关键分组丢失的系统和方法 Expired - Fee Related CN103313026B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261597524P 2012-02-10 2012-02-10
US61/597,524 2012-02-10

Publications (2)

Publication Number Publication Date
CN103313026A CN103313026A (zh) 2013-09-18
CN103313026B true CN103313026B (zh) 2017-03-01

Family

ID=47678632

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201310177406.2A Expired - Fee Related CN103313026B (zh) 2012-02-10 2013-02-08 处理多跳rtp流中的关键分组丢失的系统和方法

Country Status (5)

Country Link
US (1) US9131110B2 (zh)
EP (1) EP2627054B1 (zh)
JP (1) JP5588527B2 (zh)
KR (1) KR101458852B1 (zh)
CN (1) CN103313026B (zh)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9843489B2 (en) * 2013-06-12 2017-12-12 Blackfire Research Corporation System and method for synchronous media rendering over wireless networks with wireless performance monitoring
US9131110B2 (en) 2012-02-10 2015-09-08 Polycom, Inc. System and method for handling critical packets loss in multi-hop RTP streaming
CN103945449B (zh) * 2013-01-18 2018-12-04 中兴通讯股份有限公司 Csi测量方法和装置
CN103475835B (zh) * 2013-09-18 2016-10-05 华为技术有限公司 一种音视频会议录制内容的处理方法及装置
US20160227229A1 (en) * 2015-02-04 2016-08-04 Harris Corporation Mobile ad hoc network media aware networking element
CN105898328A (zh) * 2015-12-14 2016-08-24 乐视云计算有限公司 包含自参考编码的参考帧集设置方法及装置
US10230948B2 (en) * 2016-02-03 2019-03-12 Mediatek Inc. Video transmitting system with on-the-fly encoding and on-the-fly delivering and associated video receiving system
US10148582B2 (en) * 2016-05-24 2018-12-04 Samsung Electronics Co., Ltd. Managing buffers for rate pacing
US10869032B1 (en) 2016-11-04 2020-12-15 Amazon Technologies, Inc. Enhanced encoding and decoding of video reference frames
US10484701B1 (en) 2016-11-08 2019-11-19 Amazon Technologies, Inc. Rendition switch indicator
US10264265B1 (en) 2016-12-05 2019-04-16 Amazon Technologies, Inc. Compression encoding of images
US10681382B1 (en) * 2016-12-20 2020-06-09 Amazon Technologies, Inc. Enhanced encoding and decoding of video reference frames
CN109687934B (zh) * 2017-10-18 2020-05-26 上海交通大学 基于媒体内容的自适应系统码fec方法、装置及系统
CN108307194A (zh) * 2018-01-03 2018-07-20 西安万像电子科技有限公司 图像编码的传输控制方法及装置
CN111246290B (zh) * 2018-11-29 2022-07-05 中国电信股份有限公司 图像接收处理方法和装置
US11477138B2 (en) * 2020-12-23 2022-10-18 Nokia Solutions And Networks Oy Packet reordering in packet switched networks
KR20220124031A (ko) 2021-03-02 2022-09-13 삼성전자주식회사 영상 패킷을 송수신하는 전자 장치 및 이의 동작 방법
CN115209231B (zh) * 2022-09-07 2024-03-22 腾讯科技(深圳)有限公司 数据传输方法、装置、设备和计算机可读存储介质

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3168894B2 (ja) * 1995-12-26 2001-05-21 三菱電機株式会社 データ伝送装置およびデータ伝送方法
JP3450771B2 (ja) * 1998-11-30 2003-09-29 松下電器産業株式会社 データ伝送方法,及びデータ送信装置
US6263022B1 (en) * 1999-07-06 2001-07-17 Philips Electronics North America Corp. System and method for fine granular scalable video with selective quality enhancement
US6870816B1 (en) * 2000-03-01 2005-03-22 Motorola, Inc. Self-organizing network with decision engine and method
US6757248B1 (en) * 2000-06-14 2004-06-29 Nokia Internet Communications Inc. Performance enhancement of transmission control protocol (TCP) for wireless network applications
JP3590949B2 (ja) * 2000-08-17 2004-11-17 松下電器産業株式会社 データ伝送装置およびデータ伝送方法
JP4070420B2 (ja) * 2001-03-23 2008-04-02 フェニックス電機株式会社 超高圧放電灯の点灯方法と点灯装置
US7159108B2 (en) * 2002-10-04 2007-01-02 International Business Machines Corporation Anonymous peer-to-peer networking
US20060291468A1 (en) * 2005-06-22 2006-12-28 Rajendra Bopardikar Selective re-transmission of lost multi-media data packets
US8767818B2 (en) * 2006-01-11 2014-07-01 Nokia Corporation Backward-compatible aggregation of pictures in scalable video coding
CN101174995B (zh) * 2006-11-03 2010-05-12 中兴通讯股份有限公司 一种多媒体服务性能监测的方法和系统
KR101015888B1 (ko) * 2007-09-11 2011-02-23 한국전자통신연구원 스케일러블비디오 코딩에서 우선순위를 할당하기 위해 비디오 패킷의 왜곡값을 계산하는 장치 및 방법
US8699383B2 (en) * 2007-10-19 2014-04-15 Voxer Ip Llc Method and apparatus for real-time synchronization of voice communications
US8250181B2 (en) * 2007-10-19 2012-08-21 Voxer Ip Llc Method and apparatus for near real-time synchronization of voice communications
US8099512B2 (en) * 2007-10-19 2012-01-17 Voxer Ip Llc Method and system for real-time synchronization across a distributed services communication network
JP5142828B2 (ja) * 2008-05-29 2013-02-13 キヤノン株式会社 送信装置、送信方法及びプログラム
US8228363B2 (en) 2009-01-30 2012-07-24 Polycom, Inc. Method and system for conducting continuous presence conferences
EP2437440A1 (en) * 2010-10-01 2012-04-04 Koninklijke Philips Electronics N.V. Device and method for delay optimization of end-to-end data packet transmissions in wireless networks
US9131110B2 (en) 2012-02-10 2015-09-08 Polycom, Inc. System and method for handling critical packets loss in multi-hop RTP streaming

Also Published As

Publication number Publication date
EP2627054B1 (en) 2018-12-19
KR20130092509A (ko) 2013-08-20
KR101458852B1 (ko) 2014-11-12
JP5588527B2 (ja) 2014-09-10
JP2013211835A (ja) 2013-10-10
US20130208079A1 (en) 2013-08-15
US9131110B2 (en) 2015-09-08
EP2627054A1 (en) 2013-08-14
CN103313026A (zh) 2013-09-18

Similar Documents

Publication Publication Date Title
CN103313026B (zh) 处理多跳rtp流中的关键分组丢失的系统和方法
US11503250B2 (en) Method and system for conducting video conferences of diverse participating devices
CN101505316B (zh) 重排和复用属于互相关会话的多媒体流的包的方法和设备
US8228982B2 (en) Adaptive video streaming system and method
CN102668554B (zh) 用于交互式同步视频观看的系统和方法
CN102036071B (zh) 用于视频通信系统中的差错弹性和随机接入的系统和方法
US20100111165A1 (en) Network flow-based scalable video coding adaptation device and method
US9426423B2 (en) Method and system for synchronizing audio and video streams in media relay conferencing
CN101573883A (zh) 用于在可分级视频编码中信令并执行时间级切换的系统和方法
EP1407596A1 (en) Video stream switching
CN104735470A (zh) 一种流媒体数据传输方法及装置
US8928728B2 (en) Systems, methods, and media for controlling a presentation of data images in a video stream
Rønningen A protocol stack for futuristic multimedia
Kitamura et al. A study on the correlation between QoE of 4K super high definition video streamings and QoS of network
Lloret et al. A network management algorithm based on 3D coding techniques for stereoscopic IPTV delivery
Ahmad et al. Open source wavelet based video conferencing system using SIP

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20170301

CF01 Termination of patent right due to non-payment of annual fee