CN100456834C - H.264多媒体通信的服务质量监测方法 - Google Patents

H.264多媒体通信的服务质量监测方法 Download PDF

Info

Publication number
CN100456834C
CN100456834C CNB2005101139417A CN200510113941A CN100456834C CN 100456834 C CN100456834 C CN 100456834C CN B2005101139417 A CNB2005101139417 A CN B2005101139417A CN 200510113941 A CN200510113941 A CN 200510113941A CN 100456834 C CN100456834 C CN 100456834C
Authority
CN
China
Prior art keywords
report
service quality
qos
multimedia communication
rtcp
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
CNB2005101139417A
Other languages
English (en)
Other versions
CN1863313A (zh
Inventor
宋彬
罗忠
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.)
SnapTrack Inc
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CNB2005101139417A priority Critical patent/CN100456834C/zh
Priority to EP06804952.7A priority patent/EP1936868B1/en
Priority to PCT/CN2006/002733 priority patent/WO2007045166A1/zh
Publication of CN1863313A publication Critical patent/CN1863313A/zh
Priority to US12/104,832 priority patent/US20080192646A1/en
Application granted granted Critical
Publication of CN100456834C publication Critical patent/CN100456834C/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]

Landscapes

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

Abstract

本发明涉及多媒体通信的服务质量监测，公开了一种H.264多媒体通信的服务质量监测方法，使得H.264多媒体通信的QoS监测能在带内实现，降低QoS监测所带来的额外开销。本发明中，直接采用高层媒体协议H.264本身的扩展消息机制来承载QoS报告信息，避免使用额外的信道，实现一种“带内”QoS报告机制；利用H.264的消息扩展机制如SEI消息等自定义用户数据来传输QoS报告，监测H.264多媒体通信传输质量，不仅不影响H.264协议现有设备通信，而且降低额外带宽开销；在采用H.264带内报告的基础上，还提供了多种保护措施，改善现有RTCP/UDP的不可靠现状。

Description

H.264多媒体通信的服务质量监测方法
技术领域
本发明涉及多媒体通信的服务质量监测，特别涉及H.264多媒体通信的服务质量监测。
背景技术
随着计算机互联网(Internet)和移动通信网络的飞速发展，流媒体技术的应用越来越广泛，从网上广播、电影播放到远程教学以及在线的新闻网站等都用到了流媒体技术。当前网上传输视频、音频主要有下载(Download)和流式传输(Streaming)两种方式。流式传输是连续传送视/音频信号，当流媒体在客户机播放时其余部分在后台继续下载。流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差，以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系。
尤其是随着第三代移动通信系统(3rd Generation，简称“3G”)的出现和普遍基于网际协议(Internet Protocol，简称“IP”)的网络迅速发展，视频通信正逐步成为通信的主要业务之一。而双方或多方视频通信业务，如可视电话、视频会议、移动终端多媒体服务等，更对多媒体数据流的传输及服务质量提出苛刻的要求。不仅要求网络传输实时性更好，而且等效的也要求视频数据压缩编码效率更高。
鉴于媒体通信的需求现状，国际电信联盟标准部(InternationalTelecommunication Union Telecommunication Standardization  Sector，简称“ITU-T”)继制定了H.261、H.263、H.263+等视频压缩标准后，于2003年正式发布了H.264标准。这是ITU-T和国际标准化组织(InternationalStandardization Organization，简称“ISO”)的运动图像专家组(Moving PictureExperts Group，简称“MPEG”)一起联合制定的适应新阶段网络媒体传输及通信需求的高效压缩编码标准。它同时也是MPEG-4标准第10部分的主要内容。
制定H.264标准的目的在于更加有效地提高视频编码效率和它对网络的适配性。事实上由于其优越性，H.264视频压缩编码标准很快就已经逐渐成为当前多媒体通信中的主流标准。大量的采用H.264多媒体实时通信产品(如会议电视，可视电话，3G移动通信终端)和网络流媒体产品先后问世，是否支持H.264已经成为这个市场领域中决定产品竞争力的关键因素。可以预测，随着H.264的正式颁布和广泛使用，基于IP网络和3G、后3G无线网络的多媒体通信必然进入一个飞跃发展的新阶段。
如前所述多媒体通信不仅要求媒体压缩编码效率高，而且要求网络传输的实时性。目前多媒体流传输基本上都是采用实时传输协议(Real-timeTransport Protocol，简称“RTP”)及其控制协议(Real-time Transport ControlProtocol，简称“RTCP”)。RTP是针对Internet上多媒体数据流的一个传输协议，由互联网工程任务组(Internet Engineering Task Force，简称“IETF”)发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在用户数据包协议(UserDatagram Protocol，简称“UDP”)上，但也可以在传输控制协议(TransportControl Protocol，简称“TCP”)或异步传输模式(Asynchronous Transfer Mode，简称“ATM”)等其他协议之上工作。
RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。RTCP负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故适合传送网上的实时数据。
而H.264多媒体数据在IP网络上传输，不例外的也是基于UDP和其上层的RTP协议。RTP本身在结构上对于不同的媒体数据类型都能够适用，但是在多媒体通信中不同的高层协议或媒体压缩编码标准(如H.261，H.263，MPEG-1/-2/-4，MP3等)，IETF都会制定针对该协议的RTP净荷(Payload)打包方法的规范文件，详细规定RTP封装大包的方法，对于该具体协议是经过优化的。同样的，对于H.264也存在对应的IETF标准是RFC 3984：RTPPayload Format for H.264Video。该标准目前是H.264视频码流在IP网络上传送的主要标准，应用很广泛。在视频通信领域，各主流厂商的产品都是基于RFC 3984的，也是目前仅有的H.264/RTP传输方式。
事实上，H.264和以往其它的视频压缩编码协议不同的关键地方在于H.264定义了一个新的层面，称为网络抽象层(Network Abstract Layer，简称“NAL”)。H.264为了增加其视频编码层(Video Coding Layer，简称“VCL”)和下面具体的网络传送协议层的分离和无关性，带来更大的应用灵活性，定义了NAL这个新的层面，该层在ITU-T早期的视频压缩编码协议比如H.261，H.263/H.263+/H.263++中都是没有的。然而，如何在NAL和RTP协议承载协同工作中针对H.264的优点设计效率更高、更好的方案，使得RTP对于H.264的承载性能更好，是一个很值得研究和有很大应用价值的问题。
这里简单介绍H.264多媒体数据在NAL层的处理其NAL层的数据单元格式。NAL层位于VCL和RTP之间，规定要把视频码流按照定义的规则和结构，分割成一连串的NAL数据单元(NAL Units，简称“NALU”)。在RFC3984中定义了RTP净荷对于NALU的封装格式。
一个NALU在RTP的净荷中的封装结构，前面第一个字节为NALU头信息，之后为NALU的数据内容，多个NALU首尾相接的填充到RTP包的净荷中，在最后还有可选的RTP填充，这是RTP包格式规定的内容，是为了使得RTP包的长度符合某种特定要求(比如达到固定长度)，可选的RTP填充数据一般都填零。
NALU头信息即第1个字节，也称为八位组(Octet)，其共有三个字段，意义和全称分别描述如下：
F字段定义为禁止位(forbidden_zero_bit)，占1bit，用于标识语法错等情况，如果有语法冲突则置为1，当网络识别此单元中存在比特错误时，可将其设为1，以便接收方丢掉该单元，主要用于适应不同种类的网络环境(比如有线无线相结合的环境)；
NRI字段定义为NAL参考标识(nal_ref_idc)，占2bits，用于指示NALU数据的重要程度，其值为00表示NALU的内容不用于重建帧间预测的参考图像，而非00则表示当前NALU是属于参考帧的条带(slice)或序列参数集(Sequence Parameter Set，简称“SPS”)、图像参数集(Picture ParameterSet，简称“PPS”)等重要数据，该值越大表示当前NAL越重要；
Type字段定义为NALU类型(Nal_unit_type)，共5bits，可以有32种NALU的类型，其值和具体类型的对应关系在表1中详细给出。
表1NALU头信息中Type字段取值与类型对应关系表
  Type值   NALU内容的类型
  0   未指定
  1   非IDR图像的编码slice
  2   编码slice数据划分A
  3   编码slice数据划分B
  4   编码slice数据划分C
  5   IDR图像中的编码slice
  6   SEI(补充增强信息)
  7   SPS(序列参数集)
  8   PPS(图像参数集)
  9   接入单元定界符
  10   序列结束
  11   码流结束
  12   填充数据
  13-23   保留
  24-31   未指定
可见，NALU的头信息的一个字节中给出的信息主要包含NALU的有效性、重要性等级，根据这些信息可以确定RTP所承载的数据重要性。在NAL层将H.264的视频比特流按照一定的规则分割形成NALU流，比如可以把一帧图像作为一个NALU，也可以把一个条带(Slice)作为一个NALU。从表1中看出NALU封装的不一定都是与图像直接相关的编码数据，还有比如补充增强信息(Supplement Enhancement Information，简称“SEI”)等用于控制扩展功能等特殊的数据信息。这些扩展功能的消息在本发明的实现中占重要作用，其具体技术细节在发明正文中还将详述。
在简要介绍了H.264多媒体数据在NAL层数据格式及各种类型的数据之后，下面将继续给出与本发明涉及的领域相关的技术背景内容。
H.264视频是未来多媒体通信的主要协议，未来的多媒体通信应用的网络主要是以IP为代表的数据包交换网络和无线网络。这两大类网络都无法提供很好的服务质量(Quality of Service，简称“QoS”)保证，因此视频在网络上传送必然会受到各种传送错误如丢包的影响，从而使得通信质量降低。这里面的一个最主要的问题是IP网络实现“尽力”(best effort)传输，并不能保证传输视频信号的QoS。特别是对经过高效压缩编码的H.264码流，问题更为突出。IP网络上的尽力传输不能保证实时视频通信的QoS，具体表现在三个方面：数据包丢失、时延和时延抖动。其中，数据包丢失对恢复视频的质量影响最大，由于H.264压缩编码算法使用运动估值和运动补偿技术，一旦有数据包丢失存在，不仅影响当前解码图像，而且会影响后续解码图像，即误码扩散。误码扩散对恢复视频质量的影响非常大，只有结合编码端和解码端联合抗误码，才能完全避免误码扩散。
错误弹性(Error Resilience)是指传送机制具有预防错误发生或者在错误发生后能够以一定能力纠正的能力(错误强度在一定范围内，可以完全纠正；超过一定范围，只能部分纠正)。在未来的广泛(可以说无所不在)的多媒体通信环境中，一种视频传送机制是否具有错误弹性将是非常关键的。
存在多种错误弹性机制，比如前向纠错(Forward Error Correction，简称“FEC”)、自动重发请求(Automatic Retransmission Request，简称“ARQ”)、错误掩盖(Error Concealment)、信源信道联合编码(Joint Source-ChannelCoding，简称“JSCC”)、交织(Interleaving)及消除误码扩散等。对于H.264视频在数据包网络上传送，FEC是一种很实用的技术，效果很好。该方法主要采用多种纠错编码来对于要保护的数据进行编码，实质是形成数据冗余，从而增加抗御错误的能力。当然，其它的错误弹性机制也是有它们各自优点的。
但是，不论采取哪种传送质量保护机制，一个必须首先解决的问题是QoS监测，即了解网络的QoS情况、获得关于传送质量的报告信息，比如丢包率，延时，抖动等数值。只有了解了网络传送质量情况，才能选择正确的保护方法。在质量完全好或者仅仅受到轻微影响的时候，就不适宜采用保护能力很强的方法，因为保护能力强的代价是开销大、降低效率多；只有当传送质量受到比较严重影响的时候，才能够采用保护能力强的方法。
如前所述，当前H.264/RTP的多媒体通信框架下，主要通过运用配合控制协议RTCP来完成QoS监测的，以及基于此的拥塞控制和流量控制。RTCP主要用于RTP协议的控制和报告。报告的主要内容就是和QoS相关的信息。RTCP采取的报告方法是周期性报告，即周期性向两方或多方会话(Session)中的所有参与方传输控制数据包，报告采用和RTP数据包同样的分发机制。底层协议提供数据和控制数据包的多路复用(例如各自使用单独的UDP端口号等)。在RFC3550文件中，建议为RTCP而增加的会话带宽为媒体带宽的5％。
下面介绍RTCP数据包的类型和结构。RTCP中定义了以下几种RTCP数据包类型来携带多种控制信息：发送方报告(Sender Report，简称“SR”)，有关主动发送方的传输和接收的统计信息；接收方报告(Receiver Report，简称“RR”)从不是主动发送方的参与方接收统计信息；资源描述项(SourceDescription，简称“SDES”)，里面包括CNAME；参与方结束(退出)标识(BYE)；专用功能(Application-specific function，简称“APP”)。
RTCP发送和接收报告的包结构如图1所示，可以按内容类型分为三段，最前面的是头信息，接着是发送方信息，其次是报告内容块，最后的是特定层面(Profile)的扩展(所谓层面表示针对某种特定应用场景需要而制定的具体规则特例)。图1中示出的各个具体字段的意义及全称详细描述如下：
V字段为版本信息(Version，简称“V”)，占2位，当前RTP/RTCP的版本号为V＝2；
P字段为填充标志位(Padding)，占1位，如果P置位，则表示这个RTCP数据包在尾部包含一些不属于控制信息的附加的填充字节，但这些字节计算在长度字段中；
RC字段为接收报告计数(Reception Report Count，简称“RC”)，占5位，数据包中包含的接收报告块的数目，允许为0；
PT字段为数据包类型(Payload Type，简称“PT”)，占8比特，取值200的时候标识这是一个SR数据包；
长度(Length)字段，占16位，等于RTCP数据包以32-比特字(32bit Word)为单位的长度减1，包含头和任何填充；
发送方的SSRC，占32位，指示这个SR数据包的发起者的同步源标识符(Synchronous Source Identifier，简称“SSRC”)，这里的同步源唯一标识一个媒体数据源，比如一路视频的源；
NTP timestamp字段为网络时间协议时间戳(Network Time Protocol，简称“NTP”)，占64位，当该报告发送之后，指示了wallclock(绝对日期和时间)，与RTP时间戳结合使用；
RTP timestampe字段为RTP时间戳，占32位，即RTP协议产生的时间戳；
发送方的数据包计数字段，占32位，指示从发送建立到产生这个SR数据包期间发送方传输的RTP数据包总数；
发送方字节计数字段，共32位，指示从发送建立到产生这个SR数据包期间，发送方在RTP数据包中传输载荷(Payload)的总字节数(不包括头或填充)，该字段可以用来估算载荷的平均速率；
之后的字段包含了0个或多个接收报告块，具体块个数依赖于从上个报告发送方得知的其它源数目，每一个接收报告块传递从单个同步源收到的RTP数据包的统计信息，这些统计信息包括：
碎片丢失(fraction lost)占8位，表示继上一个报告发送后，来自该源的媒体的丢失碎片数；累积丢失包数，占24位，表示开始接收以来累积丢包的数目；
其次就是接收到的扩展最大序号、到达时延抖动，都反映网络传输状况；
上一个SR(Last SR，简称“LSR”)占32位，是指该源上一个SR报告的时间戳标记，取值为上一个SR的NTP的中间32位；
自上一个SR以来的时延(Delay since Last SR，简称“DLSR”)，占32位，是指自上一个SR到这个SR期间的时间间隔长度，这个参数是用来计算QoS报告的关键参数。
接收报告(RR)数据包格式同发送报告(SR)的区别是：数据包类型字段的值为201；没有发送方信息部分。
根据RTP/RTCP协议标准，RTCP完成四项功能如下：
基本功能，为实时多媒体数据传送质量提供反馈报告机制，这是RTP作为传输层协议的有机组成部分，这种反馈功能通过RTCP来传递发送方报告(SR)和接收方报告(RR)来实现；
RTCP为每一个RTP源传送一个永久传输层标识，称为规范名(CanonicalName，简称“CNAME”)，SSRC标识在发现冲突或程序重启时可能发生改变，因此接收方需要通过CNAME来跟踪每个参与方；
前两项功能需要所有的参与方都发送RTCP数据包，因此为了让RTP能按比例地增加参与方的数目，必须控制RTCP数据包的速率；
第四项为可选功能，即传送尽可能少的控制信息。
可见，现有技术方案中即采用RTCP协议传送QoS报告，按照RTCP协议规定的报告内容来报告这些QoS信息，基于此实现对H.264等承载媒体的QoS监测。
然而应该指出的是，RTCP在带来能够提供QoS报告机制的同时，因为采用周期性报告方法，导致了额外网络带宽的开销，最高可以达到5％。如果网络出现拥塞(Congestion)，导致传送QoS下降，那么RTCP产生的额外流量将使得问题更加恶化。虽然RTCP协议在开发的时候就意识到这个问题，从而提供了一个可选功能：要求传送尽可能少的控制信息。但是，如果传送过少的话，就要影响报告的精确程度。这是一个矛盾。
在实际应用中，上述方案存在以下问题：采用辅助控制协议RTCP的QoS报告机制实现对H.264多媒体通信的QoS监测没有完全利用H.264多媒体的优点，RTCP是一种通用的QoS报告机制，但对于特定的比如H.264这样具有自身特殊性和特定功能的媒体类型并不适用，因为它没有充分利用H.264本身的优点。
其次，RTCP相对于RTP是另外的信道，在H.323等具体协议框架下实现，需要开通额外的逻辑通道，采用所谓的“带外”监测方法，这带来了对网络传输带宽的额外开销，导致矛盾的产生，违背了QoS机制中部分目的是为了解决网络拥塞的问题和弥补带宽不足的缺陷，反而在一些网络状况不佳的情况下进一步恶化该问题。
同时，RTCP周期性报告机制也带来带宽的开销，并且随着通信方数量的增多开销会急剧增长，同样在网络出现拥塞时，RTCP流量会引起问题的恶化。
另外，RTCP数据包一般是不采用任何保护机制来保护的，并且RTCP基于UDP协议，是一种无连接(connection-less)的传送协议，因此无法保证报告数据包的正确到达，导致QoS机制本身的可靠性不够。
造成这种情况的主要原因在于，H.264/RTP的多媒体通信框架采用了一种通用的配合控制协议RTCP来传输QoS报告，以实现QoS监测，然而由于RTCP本身的带外重开逻辑通道来传输QoS报告，影响了网络状况，导致了矛盾的产生。
发明内容
有鉴于此，本发明的主要目的在于提供一种H.264多媒体通信的服务质量监测方法，使得H.264多媒体通信的QoS监测能在带内实现，降低QoS监测带来的额外开销。
为实现上述目的，本发明提供了一种H.264多媒体通信的服务质量监测方法，包含以下步骤：
通信终端统计生成所述H.264多媒体通信的服务质量报告；
所述通信终端用H.264扩展消息承载所述服务质量报告，发给其它通信终端；
所述通信终端根据其他通信终端发来的所述服务质量报告执行服务质量策略。
其中，所述H.264扩展消息为补充增强信息；
所述服务质量报告在所述补充增强信息中的封装格式如下：
第1个字节为载荷类型字段，用于指示载荷为对应服务质量报告；
第2、3个字节为载荷长度字段，用于指示对应服务质量报告长度；
第4个字节及以后为载荷，用于填充对应服务质量报告。
此外在所述方法中，所述服务质量报告分为发送方报告和接收方报告，由所述载荷类型字段指示区分。
此外在所述方法中，当所述服务质量报告为实时传输控制协议报告，该服务质量报告被填充于所述补充增强信息的载荷中时，所述补充增强信息的载荷包含：
版本信息字段，占2位，取值为二进制值“11”；
填充字段，占1位，用于指示是否有填充内容；
接收报告数字段，占5位，用于指示该服务质量报告中所报告接收报告块数目；
发送方同步源标识符字段，占32位，用于标识该服务质量报告的发送方；
当所述服务质量报告为发送方报告时，还包含发送方信息块，用于描述该服务质量报告的发送方的相关信息；
包含至少一块所述接收报告块，用于描述来自不同源的多媒体统计信息；
包含特定层面扩展，用于特定层面的保留功能扩展。
此外在所述方法中，用于承载所述服务质量报告的所述补充增强信息进一步由抽象网络层单元承载；
所述通信终端根据所述服务质量报告传输的可靠性要求设置该抽象网络层单元的网络抽象层参考标识。
此外在所述方法中，所述通信终端根据当前网络状态和高层应用需求来动态调整所述服务质量报告的统计生成及发送的周期。如果需要频繁检测这些数据，则报告周期要短，否则报告周期可以长。如果网络状况良好，则在一个预定长度的时间段内停止报告。在该预定长度的时间段结束后，重新启动一次报告，并根据该报告的信息来判断网络状况。如果网络状况仍然良好，继续在下一个预定长度的时间段内停止报告，重复这个过程；否则根据网络状况，来确定当前合适的报告周期，进行报告。
此外在所述方法中，当所述通信终端用所述补充增强消息混合承载至少一种媒体流的服务质量报告时，
该服务质量报告中包含所承载的至少一种媒体流相应的所述接收报告块。
通过比较可以发现，本发明的技术方案与现有技术的主要区别在于，直接采用高层媒体协议H.264本身的扩展消息机制来承载QoS报告信息，避免使用额外的信道，实现一种“带内”QoS报告机制；利用H.264的消息扩展机制如SEI消息等自定义用户数据来传输QoS报告，监测H.264多媒体通信传输质量，不仅不影响H.264协议现有设备通信，而且降低额外带宽开销；
通过H.264的“带内”报告机制的使用，可以作为一个多媒体通信的可选机制，这表明其不排斥RTCP报告机制的应用，兼容现有的RTCP控制协议，在两者共存的情况下也能够降低RTCP的报告流量；
在采用H.264带内报告的基础上，还提供了多种保护措施，改善现有RTCP/UDP的不可靠现状，通过设置传输QoS报告的H.264数据为重要数据，提高其重要等级，即能充分利用现有H.264的保护机制来加强对QoS报告的保护，提高QoS监测的可靠性；
此外通过H.264的带内QoS机制还可以给其他媒体数据提供QoS监测功能，实现多种媒体、多种数据的QoS监测。
这种技术方案上的区别，带来了较为明显的有益效果，即通过利用H.264的消息扩展机制，提供媒体网络传送QoS的报告机制，在带内实现QoS监测，降低带宽开销，且降低系统实现的复杂性，提高通信效率；
H.264带内QoS监测兼容现有的RTCP带外监测，具备兼容性且能降低RTCP报告流量，降低对RTCP的依赖性，提高多媒体网络传输效率；
采用H.264现有的重要数据保护机制，大大加强QoS报告和监测机制的可靠性；
通过该报告机制不但能够报告H.264视频的质量，还能够报告其它媒体比如音频的质量。这在各种媒体通信中均具有价值；
综上所述，本发明提供的带内QoS监测可以提高目前H.264视频网络传送质量的报告机制的效果和效率，从而能够提升H.264视频网络传送质量，提升基于H.264的多媒体通信产品的性能和市场竞争力，带来巨大的经济效益，有很高的实用价值。
附图说明
图1是基于RTCP协议的QoS报告数据包格式示意图；
图2是根据本发明的实施方式的承载QoS报告的SEI封装格式示意图；
图3是H.264SEI域中的RTCP的RR报告信息的结构。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。
先简单介绍本发明的基本思路。从前文描述可见，RTCP承担了QoS报告机制，但它其实是一种通用的报告方法，可以用于报告QoS，也可以用于报告其它信息。对于特定的视频通信应用，用RTCP来报告却不一定是最合适的。在某些时候，如果QoS信息的发送方和接收方都能使用更高层的协议比如H.264来通信，则完全可以考虑用H.264来承载报告的内容。本发明就是基于这个出发点，直接采用H.264来承载QoS报告信息，可以避免使用额外的信道，实现了一种“带内”报告机制。
由H.264高层协议来传输QoS报告的另一个依据是，在目前的视频通信应用中，对于网络传送的适应措施，主要基于终端来实现，而不是网络中间设备比如路由器，交换机或者网关来实现。因此QoS报告的封装提取并不依赖于底层协议，只需终端能够理解提取H.264中承载的QoS报告信息就能实现QoS监测，因此可以不依赖于下层的RTCP等协议。
当然，通过采用H.264的“带内”报告机制，并不意味着排斥RTCP报告机制的应用，两种机制可以选择使用，也可以共存，H.264的使用反而能够降低RTCP的报告流量。
另外，如果采用H.264“带内”报告方式，则H.264的数据包可以采取多种保护措施，并且对于承载QoS报告的H.264数据包，可以认为是重要的数据，根据不等保护(Unequal Protection，简称“UEP”)的原则，可以对其采用高强度的保护措施。从而可以保证报告数据的正确到达，提高QoS监测的可靠性。
为了更具体生动地给出本发明的精髓和实质，下面给出本发明的几个实施方式的技术实现细节的阐述。本发明的第一实施方式就是基于H.264的扩展消息机制来承载QoS报告的，大致分为以下三个基本步骤：
首先，各个多媒体通信终端统计生成H.264多媒体通信的QoS报告，这些报告的内容可以与RTCP的SR、RR报告内容相同，当然也可以不同，但是所描述的有关H.264媒体通信的服务质量及网络状态等信息是一致的；
然后，终端用H.264扩展消息承载这些QoS报告，发给其他通信终端，H.264扩展消息机制前面已提及，典型的有SEI等，本发明所采用的基本上就是SEI消息，当然随着以后H.264的扩展也可以使用其它扩展消息承载；
在发送QoS报告的同时终端也接收到其它终端发来的QoS报告，事实上每个终端都将根据这些QoS报告执行QoS策略。
本发明的第二实施方式就是以SEI消息承载QoS报告的，以现有的RTCP的QoS报告为例，可以直接将RTCP的SR、RR报告的主要内容，作为H.264SEI消息的载荷，从而用扩展SEI消息来承载这些信息。下面首先介绍SEI消息的结构及文法等相关资料。
H.264中提供了多种可以进行消息扩展的机制，其中比较适合本发明使用的是SEI。H.264中定义了补充增强信息(SEI)，它的数据表示区域与视频编码数据独立，它的使用方法在H.264协议中NAL的描述中给出。H.264码流的基本单位是NALU，NALU可以承载各种H.264数据类型，比如视频序列参数(Sequence parameters)、图像参数(Picture parameters)、Slice数据(即具体图像数据)、以及SEI消息数据。SEI用于传递各种消息，支持消息扩展。因此SEI域内用于传送为特定目的而自定义的消息，而不会影响基于H.264视频通信系统的兼容性。承载SEI消息的NALU叫做SEI NALU。一个SEI NALU含有一个或多个SEI消息。每个SEI消息含有一些变量，主要是载荷类型(payloadType)和载荷大小(payloadSize)，这些变量指明了消息载荷的类型和大小。在H.264Annex D.8，D.9中定义了一些常用的H.264SEI消息的文法和语意。
NALU中包含的载荷叫做原始字节序列载荷(Raw-Byte SequencePayload，简称“RBSP”)，SEI是RBSP的一种类型。按照H.2647.3的定义，SEI RBSP的文法如表2所示：
表2H.264的SEI的RBSP文法结构
  sei_rbsp(){   C   Descriptor
    Do
     sei_message()   5
    while(more_rbsp_data())
    rbsp_trailing_bits()   5
  }
可见，一个NALU中的SEI RBSP是可以包含多个SEI消息的。一个SEI消息的结构如表3所示：
表3H.264消息文法结构
  sei_message(){   C   Descriptor
    payloadType＝0
    while(next_bits(8)＝＝0xFF){
      ff_byte/*equal to 0xFF*/   5   f(8)
      payloadType+＝255
    }
    last_payload_type_byte   5   u(8)
    payloadType+＝last_payload_type_byte
    payloadSize＝0
    while(next_bits(8)＝＝0xFF){
      ff_byte/*equal to 0xFF*/   5   f(8)
      payloadSize+＝255
    }
    last_payload_size_byte   5   u(8)
    payloadSize+＝last_payload_size_byte
    sei_payload(payloadType，payloadSize)   5
  }
H.264Annex D.8定义了保留用于今后扩展的SEI消息的文法消息结构如表4所示：
表4H.264预留SEI消息载荷部分文法结构
  reserved_sei_message(payloadSize){   C   Descriptor
    for(i＝0；i＜payloadSize；i++)
      reserved_sei_message_payload_byte   5   b(8)
  }
在本发明相关实施方式的描述中，SEI的数据表示区域简称为SEI域。每个SEI域包含一个或多个SEI消息，而SEI消息又由SEI头信息和SEI有效载荷组成。SEI头信息包括两个字段：一个给出SEI消息中载荷的类型，另一个给出载荷的大小。当载荷类型在0到255之间时用一个字节0x00到0xFE表示，当类型在256到511之间时用两个字节0xFF00到0xFFFE表示，当类型大于511时表示方法以此类推，这样用户可以自定义任意多种载荷类型。其中类型0到类型18标准中已定义为特定的信息如缓存周期、图像定时等。由此可见H.264中定义的SEI域可根据需求存放足够多的用户自定义信息。对于不支持解析这些用户自定义信息的H.264解码器，会自动丢弃SEI域中的数据。因此，在SEI域内记入有用的自定义信息不会影响基于H.264视频通信系统的兼容性。
基于这种思想，在本发明的第二实施方式中，定义具体的SEI扩展消息专门用于承载QoS报告。H.264规定，SEI信息存放在一类NALU中，如前所述其Type＝6。本发明在SEI域中存放类似RTCP的SR和RR报告消息，既保证了传输效率，又能有效地反馈信道状态及解码信息，便于编码端和解码端交互式抗数据包丢失。具体结构如图2所示，其中除了头信息按照SEI消息结构来安排以外，其它QoS报告内容都借鉴RTCP的SR、RR报告的格式。
用于承载QoS报告的SEI消息的头信息包含以下字段：
第1个字节(字节0)为载荷类型字段(SEI Type)，用于指示载荷为对应QoS报告，本实施方式中，SEI Type＝200表示存放在SEI域中的是类似RTCP中的发送报告(SR)，而SEI Type＝201表示其为接收报告(RR)；
第2、3个字节(字节1、2)为载荷长度字段(SEI Packet-Length)，用于指示对应QoS报告长度，这个长度与RTCP的QoS报告中的长度字段采用相同的定义；
第4个字节及以后为SEI消息的载荷，也即用于填充对应QoS报告。
QoS报告也分为发送方报告和接收方报告，由载荷类型字段指示区分，即SEI Type取值不同，QoS报告的具体内容可以与RTCP的SR、RR报告相同，比如图3中所示：
版本信息字段(V)，占2位，本例取值为二进制11即V＝3，表示与以前版本的区别；
填充字段(P)，占1位，用于指示是否有填充内容，与RTCP相同；
接收报告数字段(RC)，占5位，用于指示该QoS报告中所报告接收报告块数目；
发送方SSRC字段，占32位，用于标识该服务质量报告的发送方；
对于发送方报告，这里还包含发送方信息块，用于描述该报告的发送方的相关信息；
之后包含多块接收报告块，用于描述来自不同源的多媒体统计信息，每块包含源的标识符和多媒体流的相关统计指标，在前面RTCP中已经描述了各种指标的意义；
最后包含特定层面扩展，用于特定层面的保留功能扩展。
可见，图3中给出的QoS报告内容与RTCP基本相同。RTCP的基本内容RR和SR写入SEI域后，可以不需要专门的逻辑信道传递RTCP信息，节省了部分带宽开销。事实上，本发明的精髓在于用SEI消息进行带内承载，至于QoS报告的如何统计生成，只要能实现QoS监测的发明目的，都不影响本发明的实质和范围。
在实现QoS报告之后，即可在此基础上进行多种QoS策略，比如利用RTCP的累计数据包丢失字段，它们在双向视频通信(终端既有编码器又有解码器)中可用于反馈解码信息，便于交互式抗数据包丢失。
另外，在QoS报告中有到达时延抖动和发送方字节计数等字段，它们都可用于感知网络状态。其中，速率控制算法可根据到达时延抖动字段中的信息，进一步保证编码端速率接近恒定；发送方字节计数字段可以估算载荷的平均速率，便于发送端根据网络状态重新设定编码器参数，包括调整目标帧率、恢复图像质量和原始图像的分辨率等等。
为了改进RTCP传输的可靠性不足，在采用H.264“带内”报告方式后，H.264的数据包可以采取多种保护措施，并且对于承载QoS报告的H.264数据包，可以认为是重要的数据，根据不等保护的原则，可以对其采用高强度的保护措施。从而可以保证报告数据的正确到达。比如用于承载QoS报告的SEI应该进一步由NALU承载，而如前所述NALU是有一个头信息可以设置该内容的重要程度的，因此通信终端可以根据QoS报告传输的可靠性要求来设置该NALU的nal_ref_idc字段，可以设为1，2，3等，在错误弹性编码中即会根据这一字段的等级不同而采取不同强度的保护措施。
通信终端还可以根据当前网络状态和高层应用需求来动态调整基于SEI消息的QoS报告的发送周期。缺省情况下，将RTCP信息写入SEI域的时间间隔(即报告周期)与RFC3550中建议RTCP传输间隔一致。当然，根据特定应用的需要(特定的保护方法等)，可能报告周期不一定和RFC 3550规定的完全一样，而是可以调整。报告周期根据特定应用的需要确定。比如，报告数据的一个重要用途是动态估计网络的性能：丢包率、延迟、抖动等。如果需要频繁检测这些数据，则报告周期要短，否则报告周期可以长。在网络状况良好的时候，可以停止报告。
另外，用SEI消息不仅可以传输H.264视频的QoS报告，还可以混合承载多种媒体流的QoS报告，只需在QoS报告后面加入各种媒体流相应的接收报告块即可。比如音频流等，只要在SR报告中增加其源的SSRC具体的报告块内容。
前面也提到，除了采用SEI进行带内监测之后，通信终端还可以选择现有的RTCP传输，也可以同时使用H.264扩展消息、RTCP中的一种或两种来传送承载QoS报告。
熟悉本发明的技术人员可以理解，上述实施方式的描述中，关于字段的具体分配方式、取值方式均给出例子，但在具体应用中完全可以按要求和发明原理进行重新设置或取值，并不影响本发明的实质和范围。
虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (8)

1.一种H.264多媒体通信的服务质量监测方法，其特征在于，包含以下步骤：
通信终端统计生成所述H.264多媒体通信的服务质量报告；
所述通信终端用H.264扩展消息承载所述服务质量报告，发给其它通信终端；
所述通信终端根据其他通信终端发来的所述服务质量报告执行服务质量策略。
2.根据权利要求1所述的H.264多媒体通信的服务质量监测方法，其特征在于，所述H.264扩展消息为补充增强信息；
所述服务质量报告在所述补充增强信息中的封装格式如下：
第1个字节为载荷类型字段，用于指示载荷为对应服务质量报告；
第2、3个字节为载荷长度字段，用于指示对应服务质量报告长度；
第4个字节及以后为载荷，用于填充对应服务质量报告。
3.根据权利要求2所述的H.264多媒体通信的服务质量监测方法，其特征在于，所述服务质量报告分为发送方报告和接收方报告，由所述载荷类型字段指示区分。
4.根据权利要求3所述的H.264多媒体通信的服务质量监测方法，其特征在于，当所述服务质量报告为实时传输控制协议报告，该服务质量报告被填充于所述补充增强信息的载荷中时，所述补充增强信息的载荷包含：
版本信息字段，占2位，取值为二进制值“11”；
填充字段，占1位，用于指示是否有填充内容；
接收报告数字段，占5位，用于指示该服务质量报告中所报告接收报告块数目；
发送方同步源标识符字段，占32位，用于标识该服务质量报告的发送方；
当所述服务质量报告为发送方报告时，还包含发送方信息块，用于描述该服务质量报告的发送方的相关信息；
包含至少一块接收报告块，用于描述来自不同源的多媒体统计信息；
包含特定层面扩展，用于特定层面的保留功能扩展。
5.根据权利要求2所述的H.264多媒体通信的服务质量监测方法，其特征在于，用于承载所述服务质量报告的所述补充增强信息进一步由抽象网络层单元承载；
所述通信终端根据所述服务质量报告传输的可靠性要求设置该抽象网络层单元的网络抽象层参考标识。
6.根据权利要求2所述的H.264多媒体通信的服务质量监测方法，其特征在于，所述通信终端根据当前网络状态和高层应用需求来动态调整所述服务质量报告的统计生成及发送的周期。
7.根据权利要求6所述的H.264多媒体通信的服务质量监测方法，所述服务质量报告的统计生成及发送的周期的动态调整包含：
如果需要频繁检测报告的数据，则将报告周期设置得较短，否则将报告周期设置得较长；
如果网络状况良好，则在一个预定长度的时间段内停止报告，在该预定长度的时间段结束后，重新启动一次报告，并根据该报告的信息来判断网络状况，如果网络状况仍然良好，继续在下一个预定长度的时间段内停止报告，重复这个过程；否则根据网络状况，来确定当前合适的报告周期，进行报告。
8.根据权利要求3所述的H.264多媒体通信的服务质量监测方法，其特征在于，当所述通信终端用所述补充增强消息混合承载至少一种媒体流的服务质量报告时，该服务质量报告中包含所承载的至少一种媒体流相应的接收报告块。
CNB2005101139417A 2005-10-17 2005-10-17 H.264多媒体通信的服务质量监测方法 Expired - Fee Related CN100456834C (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CNB2005101139417A CN100456834C (zh) 2005-10-17 2005-10-17 H.264多媒体通信的服务质量监测方法
EP06804952.7A EP1936868B1 (en) 2005-10-17 2006-10-17 A method for monitoring quality of service in multimedia communication
PCT/CN2006/002733 WO2007045166A1 (fr) 2005-10-17 2006-10-17 Methode pour surveiller une qualite de service dans une communication multimedia
US12/104,832 US20080192646A1 (en) 2005-10-17 2008-04-17 Method for Monitoring Quality of Service in Multimedia Communications

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CNB2005101139417A CN100456834C (zh) 2005-10-17 2005-10-17 H.264多媒体通信的服务质量监测方法

Publications (2)

Publication Number Publication Date
CN1863313A CN1863313A (zh) 2006-11-15
CN100456834C true CN100456834C (zh) 2009-01-28

Family

ID=37390617

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB2005101139417A Expired - Fee Related CN100456834C (zh) 2005-10-17 2005-10-17 H.264多媒体通信的服务质量监测方法

Country Status (4)

Country Link
US (1) US20080192646A1 (zh)
EP (1) EP1936868B1 (zh)
CN (1) CN100456834C (zh)
WO (1) WO2007045166A1 (zh)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1926104B1 (en) * 2006-11-27 2016-06-29 Thomson Licensing Encoding device, decoding device, recording device, audio/video data transmission system
US8959239B2 (en) * 2006-12-29 2015-02-17 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for reporting streaming media quality
US20110196976A1 (en) * 2008-10-21 2011-08-11 Mitsubishi Electric Corporation Communication system and communication device
WO2010069372A1 (en) 2008-12-17 2010-06-24 Telefonaktiebolaget Lm Ericsson (Publ) Monitoring media services in telecommunications networks
WO2011068355A2 (ko) * 2009-12-01 2011-06-09 삼성전자 주식회사 상호 계층 최적화를 이용한 멀티미디어 데이터 패킷을 송신하는 방법 및 장치
US8471890B1 (en) * 2009-12-30 2013-06-25 Insors Integrated Communications Adaptive video communication channel
US20120057629A1 (en) * 2010-09-02 2012-03-08 Fang Shi Rho-domain Metrics
CN102833219B (zh) * 2011-06-16 2015-06-03 华为技术有限公司 向客户端传输数据文件的方法和装置
JP5716712B2 (ja) * 2012-07-24 2015-05-13 横河電機株式会社 パケット転送装置及び方法
US9426462B2 (en) 2012-09-21 2016-08-23 Qualcomm Incorporated Indication and activation of parameter sets for video coding
US10164929B2 (en) 2012-09-28 2018-12-25 Avaya Inc. Intelligent notification of requests for real-time online interaction via real-time communications and/or markup protocols, and related methods, systems, and computer-readable media
US9363133B2 (en) 2012-09-28 2016-06-07 Avaya Inc. Distributed application of enterprise policies to Web Real-Time Communications (WebRTC) interactive sessions, and related methods, systems, and computer-readable media
KR102048480B1 (ko) * 2012-10-11 2020-01-08 삼성전자주식회사 동적인 네트워크 환경에서 멀티미디어 데이터 특징 정보를 송수신하는 장치 및 방법
US9294458B2 (en) 2013-03-14 2016-03-22 Avaya Inc. Managing identity provider (IdP) identifiers for web real-time communications (WebRTC) interactive flows, and related methods, systems, and computer-readable media
US10205624B2 (en) 2013-06-07 2019-02-12 Avaya Inc. Bandwidth-efficient archiving of real-time interactive flows, and related methods, systems, and computer-readable media
US9525718B2 (en) 2013-06-30 2016-12-20 Avaya Inc. Back-to-back virtual web real-time communications (WebRTC) agents, and related methods, systems, and computer-readable media
US9065969B2 (en) 2013-06-30 2015-06-23 Avaya Inc. Scalable web real-time communications (WebRTC) media engines, and related methods, systems, and computer-readable media
US9112840B2 (en) 2013-07-17 2015-08-18 Avaya Inc. Verifying privacy of web real-time communications (WebRTC) media channels via corresponding WebRTC data channels, and related methods, systems, and computer-readable media
US9614890B2 (en) 2013-07-31 2017-04-04 Avaya Inc. Acquiring and correlating web real-time communications (WEBRTC) interactive flow characteristics, and related methods, systems, and computer-readable media
US9531808B2 (en) 2013-08-22 2016-12-27 Avaya Inc. Providing data resource services within enterprise systems for resource level sharing among multiple applications, and related methods, systems, and computer-readable media
US10225212B2 (en) * 2013-09-26 2019-03-05 Avaya Inc. Providing network management based on monitoring quality of service (QOS) characteristics of web real-time communications (WEBRTC) interactive flows, and related methods, systems, and computer-readable media
US10263952B2 (en) 2013-10-31 2019-04-16 Avaya Inc. Providing origin insight for web applications via session traversal utilities for network address translation (STUN) messages, and related methods, systems, and computer-readable media
US9769214B2 (en) 2013-11-05 2017-09-19 Avaya Inc. Providing reliable session initiation protocol (SIP) signaling for web real-time communications (WEBRTC) interactive flows, and related methods, systems, and computer-readable media
US10129243B2 (en) 2013-12-27 2018-11-13 Avaya Inc. Controlling access to traversal using relays around network address translation (TURN) servers using trusted single-use credentials
US9749363B2 (en) 2014-04-17 2017-08-29 Avaya Inc. Application of enterprise policies to web real-time communications (WebRTC) interactive sessions using an enterprise session initiation protocol (SIP) engine, and related methods, systems, and computer-readable media
US10581927B2 (en) 2014-04-17 2020-03-03 Avaya Inc. Providing web real-time communications (WebRTC) media services via WebRTC-enabled media servers, and related methods, systems, and computer-readable media
US9912705B2 (en) 2014-06-24 2018-03-06 Avaya Inc. Enhancing media characteristics during web real-time communications (WebRTC) interactive sessions by using session initiation protocol (SIP) endpoints, and related methods, systems, and computer-readable media
RU2598337C2 (ru) * 2014-12-19 2016-09-20 Закрытое акционерное общество "Лаборатория Касперского" Система и способ выбора средств перехвата данных, передаваемых по сети
GB2533775B (en) 2014-12-23 2019-01-16 Imagination Tech Ltd In-band quality data
CN109416822B (zh) * 2016-06-15 2023-10-20 Sk电信有限公司 用于在移动环境中报告qos/qoe的方法及其设备
CN112616069A (zh) * 2020-12-01 2021-04-06 上海连尚网络科技有限公司 一种流媒体视频播放、生成方法及设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1304831A2 (en) * 2001-08-16 2003-04-23 Sonera Oyj Monitoring and transmission of QoS-data in a telecommunication network
CN1440176A (zh) * 2002-02-13 2003-09-03 松下电器产业株式会社 利用实时传输协议和实时传输控制协议传输数据包的方法
US20050094557A1 (en) * 2003-11-04 2005-05-05 Ming-Chun Chen Method of controlling signal transmission in a local area network
CN1625174A (zh) * 2003-12-02 2005-06-08 明基电通股份有限公司 局域网络传输控制方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8576878B2 (en) * 2002-06-04 2013-11-05 Nokia Corporation Method for controlling parties in real-time data communication
ATE522068T1 (de) * 2003-09-02 2011-09-15 Nokia Corp Übertragung von informationen, die sich auf eine dienstgüte beziehen
US7609762B2 (en) * 2003-09-07 2009-10-27 Microsoft Corporation Signaling for entry point frames with predicted first field
US8351514B2 (en) * 2004-01-16 2013-01-08 General Instrument Corporation Method, protocol, and apparatus for transporting advanced video coding content
US20070014346A1 (en) * 2005-07-13 2007-01-18 Nokia Corporation Coding dependency indication in scalable video coding
EP2375749B1 (en) * 2005-10-11 2016-11-23 Nokia Technologies Oy System and method for efficient scalable stream adaptation
WO2007046957A1 (en) * 2005-10-12 2007-04-26 Thomson Licensing Method and apparatus for using high-level syntax in scalable video encoding and decoding

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1304831A2 (en) * 2001-08-16 2003-04-23 Sonera Oyj Monitoring and transmission of QoS-data in a telecommunication network
CN1440176A (zh) * 2002-02-13 2003-09-03 松下电器产业株式会社 利用实时传输协议和实时传输控制协议传输数据包的方法
US20050094557A1 (en) * 2003-11-04 2005-05-05 Ming-Chun Chen Method of controlling signal transmission in a local area network
CN1625174A (zh) * 2003-12-02 2005-06-08 明基电通股份有限公司 局域网络传输控制方法

Also Published As

Publication number Publication date
CN1863313A (zh) 2006-11-15
EP1936868A1 (en) 2008-06-25
WO2007045166A1 (fr) 2007-04-26
EP1936868B1 (en) 2013-05-01
EP1936868A4 (en) 2009-01-21
US20080192646A1 (en) 2008-08-14

Similar Documents

Publication Publication Date Title
CN100456834C (zh) H.264多媒体通信的服务质量监测方法
CN100466725C (zh) 多媒体通信方法及其终端
CN1934865B (zh) 调整编码器和解码器中缓冲器的大小的方法及装置
CN100407726C (zh) H.264多媒体数据实时传送方法
CN100558167C (zh) 多媒体视频通信方法及系统
CN109150876B (zh) 一种视频无线传输的qos方法、装置及系统
US8127040B2 (en) Signaling buffer parameters indicative of receiver buffer architecture
WO2007045141A1 (fr) Procede de prise en charge de transmission de donnees multimedias avec tolerance aux erreurs
CN101611551A (zh) 用于视频通信系统中的差错弹性的改进系统和方法
CN102036071A (zh) 用于视频通信系统中的差错弹性和随机接入的系统和方法
CN104270594B (zh) 数据包发送与接收的方法及设备
CN101646074B (zh) 视频数据的实时传输方法
US20150071307A1 (en) Communication interface and method for robust header compression of data flows
US7852853B1 (en) System and method for transmitting video information
CN102523486A (zh) 一种在视频调度系统中实现动态码流带宽自适应的方法
EP1725036A1 (en) A method and a video server for embedding audiovisual packets in an IP packet
Standard Transport of high bit rate media signals over IP networks (HBRMT)
CN106303537B (zh) 一种openh264多码流传输方法
CN104025605A (zh) 用于多媒体内容的复用流传输的系统和方法
US8243826B2 (en) Encoded stream transmitter
Wang et al. RFC 6184: RTP Payload Format for H. 264 Video
CN100474923C (zh) 用于实时流式传输服务的mpeg-4编码模式选择方法
KR20050099078A (ko) 실시간 스트리밍 서비스 시 부호화 모드 선택 방법
CN100518304C (zh) 与视频信息包损耗对应的解码方法
Klemets RTP payload format for video codec 1 (VC-1)

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
C41 Transfer of patent application or patent right or utility model
TR01 Transfer of patent right

Effective date of registration: 20160504

Address after: California, USA

Patentee after: SNAPTRACK, Inc.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd.

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

Granted publication date: 20090128

Termination date: 20211017

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