CN100558167C - 多媒体视频通信方法及系统 - Google Patents

多媒体视频通信方法及系统 Download PDF

Info

Publication number
CN100558167C
CN100558167C CN 200610139177 CN200610139177A CN100558167C CN 100558167 C CN100558167 C CN 100558167C CN 200610139177 CN200610139177 CN 200610139177 CN 200610139177 A CN200610139177 A CN 200610139177A CN 100558167 C CN100558167 C CN 100558167C
Authority
CN
China
Prior art keywords
video data
frame
video
receiving terminal
unit
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
CN 200610139177
Other languages
English (en)
Other versions
CN101166270A (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 CN 200610139177 priority Critical patent/CN100558167C/zh
Publication of CN101166270A publication Critical patent/CN101166270A/zh
Application granted granted Critical
Publication of CN100558167C publication Critical patent/CN100558167C/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

本发明涉及通信领域,公开了一种多媒体视频通信方法及系统,提高了H.264视频网络传送质量的检测和报告机制的效果和效率。本发明中,接收端以带内方式反馈传送质量监测信息,避免了额外信道的使用。接收端仅在接收出错时反馈传送质量监测信息,减少了带宽的开销,提供了反馈的实时性。使用SEI扩展消息以带内方式反馈传送质量监测信息,可以完全兼容现有的H.264协议。发送端计算视频数据的优先级指标,并根据信道劣化程度,在当前帧或下一帧中选择优先级指标最高的N个单位的视频数据经帧内编码后发送给接收端,用于接收端的错误消除。

Description

多媒体视频通信方法及系统
技术领域
本发明涉及通信领域,特别涉及多媒体视频通信技术。
背景技术
国际电信联盟-电信标准部(International Telecommunication UnionTelecommunication Standardization Sector,简称“ITU-T”)联合ISO/IEC MPEG国际标准组织制定的H.264视频压缩编码标准,目前已经逐渐成为多媒体通信中的主流标准。大量的采用H.264多媒体实时通信产品(如会议电视,可视电话,3G移动通信终端)和网络流媒体产品先后问世。是否支持H.264已经成为这个市场领域中决定产品竞争力的关键因素。回顾H.264的发展历史,我们发现,随着第三代移动通信(The Third Generation,简称“3G”)系统的出现和IP(Internet Protocol)网络的迅速发展,视频通信正逐步成为通信的主要业务之一。ITU-T继制定了H.261、H.263、H.263+等视频压缩标准后,于2003年正式发布了H.264标准,它同时也是MPEG-4第10部分的主要内容。制定H.264标准的目的在于更加有效地提高视频编码效率和它对网络的适配性,因此可以预测,随着H.264的正式颁布和广泛使用,基于IP网络和3G,B3G甚至4G无线网络的多媒体通信必然进入一个飞跃发展的新阶段。H.264在IP网络上传送,一般基于用户数据报协议(User DatagramProtocol,简称“UDP”)和其上层的实时传送协议(RealTime Transfer Protocol,简称“RTP”),该标准是互联网工程任务组(Internet Engineering Task Force,简称“IETF”)制定的。RTP协议应用非常广泛,IP网络上的实时应用(视频,音频等多媒体实时通信)基本都采用RTP协议来传送。RTP在结构上对于不同的媒体数据类型都能够适用,但是对于每种具体的更高层协议,比如H.261,H.263,MPEG-1/-2/-4,MP3等,IETF都会制定针对该协议的RTP净荷(Payload)打包协议,详细规定RTP封装打包的方法,对于该具体协议是经过优化的。对于H.264,也存在对应的IETF标准是RFC 3984:RTP PayloadFormat for H.264Video(用于H.264视频的RTP净荷格式)。该标准目前是H.264视频码流在IP网络上传送的主要标准,应用很广泛。在视频通信领域,各主流厂商的产品都是基于RFC 3984的。
H.264视频是未来多媒体通信的主要协议,未来的多媒体通信应用的网络主要是以IP为代表的数据包交换网络和无线网络。这两大类网络都无法提供很好的服务质量(Quality of Service,简称“QoS”),因此视频在网络上传送必然会受到各种传送错误而丢包的影响,从而使得通信质量降低。我们知道,一个最主要的问题是IP网络实现“尽力”(best effort)传送,并不能保证传送视频信号的QoS。特别是对经过高效压缩编码的H.264码流,问题更为突出。IP网络上的尽力传送不能保证实时视频通信的QoS,具体表现在三个方面:数据包丢失、时延和时延抖动。其中,数据包丢失对恢复视频的质量影响最大,由于H.264压缩编码算法使用运动估值和运动补偿技术,一旦有数据包丢失存在,不仅影响当前解码图像,而且会影响后续解码图像,即误码扩散。误码扩散对恢复视频质量的影响非常大,只有结合编码端和解码端联合抗误码,才能完全避免误码扩散。
错误弹性(Error Resilience)是指传送机制具有预防错误发生或者在错误发生后能够以一定能力纠正的能力(错误强度在一定范围内,可以完全纠正;超过一定范围,只能部分纠正)。在未来的广泛的多媒体通信环境中,一种视频传送机制是否具有错误弹性将是非常关键的。
目前存在多种错误弹性机制,比如前向误码校正(Forward ErrorCorrection,简称“FEC”),自动请求重发(Automatic Retransmission Request,简称“ARQ”),Error Concealment(错误掩盖),信源信道联合编码(JointSource-Channel Coding,简称“JSCC”),交织(Interleaving),消除误码扩散等等。对于H.264视频在数据包网络上传送,FEC是一种很实用的技术,效果很好。该方法主要采用多种纠错编码来对于要保护的数据进行编码,实质是形成数据冗余,从而增加抗御错误的能力。当然,其它的错误弹性机制也是有它们各自有点的。但是,不论采取哪种传送质量保护机制,一个必须解决的问题是了解网络的QoS情况,获得关于传送质量的报告信息,比如丢包率,延时,抖动等数值。只有了解了网络传送质量情况,才能选择正确的保护方法。在质量完全好或者仅仅受到轻微影响的时候,就不适宜采用保护能力很强的方法,因为保护能力强的代价是开销大,降低效率多;只有当传送质量受到比较严重影响的时候,才能够采用保护能力强的方法。
H.264标准的一个显著特点就是将系统分为两个独立的层:即视频编码层(VCL)和网络适配层(NAL)。前者的主要任务是进行高效的视频数据编码压缩;后者则是根据网络特性对数据进行封装打包,实现视频QOS与网络QOS的适配。
实时传送控制协议(RealTime Transfer Control Protocol,简称“RTCP”)是RTP协议的一个配合协议,也由IETF制定。RTCP主要用于RTP协议的控制和报告。报告的主要内容就是和QoS相关的信息。RTCP采取的报告方法是周期性报告。即周期性向会话(Session可以理解成一个多方通信中的会议)中的所有参与方传送控制数据包,和RTP数据包采用同样的分发机制。底层协议必须提供数据和控制数据包的多路复用(例如使用单独的UDP端口号等)。在RFC3550中,建议为RTCP而增加的会话带宽固定为5%。RTCP完成四项功能:
1、基本功能-为实时多媒体数据传送质量提供反馈报告机制,这是RTP作为传送层协议的有机组成部分。这种反馈功能通过RTCP来传递发送方报告(SR)和接收方报告(RR)来实现。
2、RTCP为每一个RTP源传送一个永久传送层标识,称为规范名(CNAME)。同步源(Synchronization Rsource,简称“SSRC”)标识在发现冲突或程序重启时可能发生改变,因此接收方需要通过CNAME来跟踪每个参与方。
3、前两项功能需要所有的参与方都发送RTCP数据包,因此为了让RTP能按比例地增加参与方的数目,必须控制RTCP数据包的速率。
4、第四项为可选功能——传送尽可能少的控制信息。
在通信领域中,信令(也可称为消息等)有两种传送方式,将信令与数据在同一信道中传送称为带内方式,信令独立于数据传送信道之外传送称为带外方式。
RTCP使用了带外传送方式,RTCP相对于RTP是另外的信道,在H.323等具体协议框架下实现时,需要开通额外的逻辑通道,从而消耗了额外的资源。
另,RTCP在带来能够提供QoS报告机制的同时,因为采用周期性报告方法,导致了额外网络带宽的开销,最高可以达到5%。如果,网络出现劣化(Congestion),导致传送QoS下降,那么RTCP产生的额外流量将使得问题更加恶化。虽然RTCP协议在开发的时候就意识到这个问题,从而提供了一个可选功能:要求传送尽可能少的控制信息。但是,如果传送过少的话,就要影响报告的精确程度,这是一个矛盾。
发明内容
有鉴于此,本发明的主要目的在于提供一种多媒体视频通信方法及系统,以提高H.264视频网络传送质量的检测和报告机制的效果和效率。
为实现上述目的,本发明提供了一种多媒体视频通信方法,包含以下步骤:
接收端以带内方式向发送端反馈已收到的视频数据的传送质量监测信息,使所述发送端根据带内反馈的所述传送质量监测信息调整需要向所述接收端发送的视频数据的压缩编码属性;
其中,当所述接收端监测到收到的视频数据发生错误时,反馈的所述传送质量监测信息中包含用于定位传送出错的视频数据的标识和指示信道劣化程度的信息。
其中,所述发送端将所述传送质量监测信息承载在补充增强信息SEI扩展消息中,以带内方式反馈给所述发送端。
此外在所述方法中,所述SEI扩展消息承载的传送质量监测信息至少包含以下之一:
出错帧序号、出错宏块序号、实时传送协议RTP包丢失率、即时刷新帧刷新标志。
此外在所述方法中,所述RTP包丢失率通过以下步骤获得:
收到RTP包时,根据接收的结果向用于统计的队列中写入表示正确或错误的标志;
当所述队列满时,将该队列中表示错误的标志数目除以队列的长度得到所述RTP包丢失率。
此外在所述方法中,所述用于统计的队列的长度按照如下方式进行计算和设置:
队列的长度=统计周期×接收端的平均接收码率/每个RTP包的长度。
此外在所述方法中,所述发送端通过以下步骤确定向所述接收端发送的用来进行错误消除的视频数据:
所述发送端根据信道劣化程度,在当前视频帧或者紧接着的下一个视频帧中选择优先级指标最高的N个单位的视频数据进行帧内编码,将帧内编码后的视频数据作为所述用来进行错误消除的视频数据发送给所述接收端。
此外在所述方法中,通过以下方式根据信道劣化程度确定N的大小:
在先设定m个门限β1到βm,m+1个正整数N1到Nm+1,其中m为正整数,βi<βi+1,1≤i≤m-1;
如果表示信道劣化程度的指标小于β1,则N取值为N1
如果表示信道劣化程度的指标大于等于βi并小于βi+1,1≤i≤m-1,则N取值Ni+1
如果表示信道劣化程度的指标大于等于βm,则N取值Nm+1
其中,表示信道劣化程度的指标值越大表示信道越差。
此外在所述方法中,所述信道劣化程度以RTP包丢失率来指示;
所述出错的视频数据的标识为视频帧序号和/或宏块序号;
所述单位为宏块。
此外在所述方法中,所述优先级指标满足以下条件之一或其任意组合:
所述优先级指标是宏块的运动剧烈程度的递增函数;
所述优先级指标是宏块对于后续视频帧中其它宏块的影响程度的递减函数;
所述优先级指标是用于判决预测编码类型的代价函数值的递减函数;
所述优先级指标是宏块在当前帧之前预定数目的各帧中被刷新成帧内编码方式的次数的递减函数。
此外在所述方法中,所述优先级指标是以下四个函数中的一个或者多个的加权线性组合,并且每个函数对应的加权系数为非负数:
一个关于宏块的运动剧烈程度的递增函数;
一个关于宏块对于后续视频帧中其它宏块的影响程度的递减函数;
一个关于用于判决预测编码类型的代价函数值的递减函数;
一个关于宏块在当前帧之前预定数目的各帧中被刷新成帧内编码方式的次数的递减函数。
此外在所述方法中,如果所述出错的视频数据是帧间预测编码帧,则所述发送端根据RTP包丢失率,从出错位置开始,每次选取优先级指标最高的N个宏块经帧内编码后发送给所述接收端。
此外在所述方法中,如果所述出错的视频数据是帧内编码帧,且RTP包丢失率小于在先设置的第一门限,则所述接收端立即暂停解码,通过所述SEI扩展消息请求所述发送端重新发送即时刷新帧;
所述发送端将视频帧进行及时刷新编码,然后把该即时刷新帧作为所述用来进行错误消除的视频数据发送给所述接收端。
此外在所述方法中,如果所述出错的视频数据是帧内编码帧,且RTP包丢失率大于在先设置的第一门限,则禁止所述接收端因本次接收出错向所述发送端请求重新发送即时刷新帧。
本发明还提供了一种多媒体视频通信系统,接收端包含:以带内方式向发送端反馈已收到的视频数据的传送质量监测信息的反馈单元;
发送端包含:以带内方式接收所述接收端反馈的传送质量监测信息的单元,和根据反馈的传送质量监测信息调整需要向该接收端发送的视频数据的压缩编码属性的单元;
其中,所述反馈单元在所述接收端监测到收到的视频数据发生错误时,反馈的所述传送质量监测信息中包含用于定位传送出错的视频数据的标识和指示信道劣化程度的信息。
其中,所述发送端将所述传送质量监测信息承载在补充增强信息SEI扩展消息中,以带内方式反馈给所述发送端;
所述SEI扩展消息承载的传送质量监测信息至少包含以下之一:
出错帧序号、出错宏块序号、RTP包丢失率、即时刷新帧刷新标志。
此外在所述系统中,所述接收端还包含计算RTP包丢失率的单元,该单元包含:
用于统计的队列;
收到RTP包时,根据接收的结果向所述队列写入表示正确或错误的标志的模块;
当所述队列满时,将该队列中表示错误的标志数目除以队列的长度得到所述RTP包丢失率的模块;
其中,所述队列的长度=统计周期×接收端的平均接收码率/每个RTP包的长度。
此外在所述系统中,所述发送端还包含:
用于计算视频数据的优先级指标的单元;
根据信道劣化程度,通过对于当前视频帧或者紧接着的下一个视频帧中的多个单位的视频数据的优先级指标的计算,在当前视频帧或者紧接着的下一个视频帧中选择优先级指标最高的N个单位的视频数据,通知用于视频压缩编码的单元对于这N个单位的视频数据进行帧内编码,以作为接收端进行错误消除的视频数据的单元。
此外在所述系统中,所述接收端还包含:判断出错的视频数据帧预测编码类型的类型判断单元;和判断RTP包丢失率是否小于在先设置的第一门限的劣化程度判断单元;
如果所述类型判断单元判定出错的视频数据是帧内编码帧,并且所述劣化程度判断单元判定RTP包丢失率小于第一门限,则在发送给所述发送端的SEI扩展消息请求中设置要求即时刷新的标志;
如果所述类型判断单元判定出错的视频数据是帧内编码帧,并且所述劣化程度判断单元判定RTP包丢失率小于第一门限,则禁止所述反馈单元因本次接收出错发送所述SEI扩展消息;
如果所述类型判断单元判定出错的视频数据是帧间预测编码帧,则向所述发送端发送所述SEI扩展消息,报告所述的视频数据传送质量监测信息。
本发明还提供了一种多媒体视频通信中错误消除方法,包含以下步骤:
发送端接收来自接收端的传送出错的视频数据的标识和指示信道劣化程度的信息;
所述发送端根据信道劣化程度,在当前视频帧或者紧接着的下一个视频帧中选择优先级指标最高的N个单位的视频数据进行帧内编码后发送给所述接收端,所述接收端使用所述N个单位的帧内编码视频数据进行错误消除。
其中,所述信道劣化程度以RTP包丢失率指示;
所述出错的视频数据的标识为视频帧序号和/或宏块序号;
所述单位为宏块。
此外在所述方法中,所述优先级指标满足以下条件之一或其任意组合:
所述优先级指标是宏块的运动剧烈程度的递增函数;
所述优先级指标是宏块对于后续视频帧中其它宏块的影响程度的递减函数;
所述优先级指标是用于判决预测编码类型的代价函数值的递减函数;
所述优先级指标是宏块在之前预定数目的各帧中被刷新成帧内编码方式的次数的递减函数。
本发明还提供了一种多媒体视频通信中错误消除系统,接收端包含:用于将传输出错的视频数据的标识和指示信道劣化程度的信息发送给发送端的单元;和使用来自发送端的视频数据进行错误消除的单元;
发送端包含:
用于计算视频数据的优先级的单元;
接收来自接收端信息的单元;和
根据信道劣化程度,在出错的视频数据中选择优先级最高的N个单位的视频数据进行帧内编码后发送给所述接收端的单元。
通过比较可以发现,本发明的技术方案与现有技术的主要区别在于,接收端以带内方式反馈传送质量监测信息,相对于现有技术中以带外方式反馈,避免了额外信道的使用。
接收端可以仅在接收出错时反馈传送质量监测信息,相对于现有技术中周期性反馈的方式,减少了带宽的开销,提高了反馈的实时性。
使用SEI扩展消息以带内方式反馈传送质量监测信息,可以完全兼容现有的H.264协议。
通过队列的方式统计RTP包丢失率,可以方便地计算出RTP包丢失率,并可以提供较为详细的RTP包丢失情况。
发送端计算视频数据的优先级指标,并根据信道劣化程度,在当前帧或下一帧中,从出错的位置开始选择优先级指标最高的N个单位的视频数据经帧内编码后发送给接收端,用于接收端的错误消除。根据信道劣化程度得到N的方式有多种,例如可以通过多个门限划分出多个信道劣化程度的区间,每个区间有一个对应的不同的N,原则上信道劣化程度较高时N应当较小,实际操作中最好还能兼顾考虑错误消除能力和额外带宽开销。因为信道劣化程度较高时使用帧内编码的数据较少,而帧内编码产生的数据量较多,所以不会在信道劣化时使传送环境进一步恶化。因为传的是优先级指标最高的部分视频数据,所以传送同样的数据量时对接收端错误消除的帮助最大。
提出了确定优先级指标的方法,包括:优先级指标是宏块的运动剧烈程度的递增函数;优先级指标是宏块对于后续视频帧中其它宏块的影响程度的递减函数;优先级指标是用于判决预测编码类型的代价函数值的递减函数;优先级指标是宏块在之前预定数目的各帧中被刷新成帧内编码方式的次数的递减函数。从而增强了优先级指标计算的可操作性。
如果出错的视频数据是帧内编码帧,且RTP包丢失率大于在先设置的第一门限,则接收端不再发送即时刷新帧请求。RTP包丢失率过大表明当前信道丢包严重,即使发送端重新发送即时刷新帧,此即时刷新帧仍很有可能在传送过程中遭到破坏,导致接收端短期内持续要求刷新即时刷新帧。由于即时刷新帧数据量大,如此重复刷新即时刷新帧非但不会有效改善接收端图像质量,还可能造成信道负担过重,导致信道劣化越来越严重。通过不发送即时刷新帧请求,防止了信道的进一步恶化。
附图说明
图1是根据本发明第一实施方式的双向视频系统结构示意图;
图2是SEI消息的结构示意图;
图3是根据本发明第一实施方式的H.264视频传送质量监测报告和交互错误消除原理图;
图4是本发明第一实施方式中接收端的多媒体视频通信方法流程图;
图5是本发明第一实施方式中用于计算RTP包丢失率的VDTQI队列示意图;
图6是本发明第一实施方式中SEI扩展消息的一个例子;
图7是本发明第一实施方式中发送端的多媒体视频通信方法流程图;
图8是根据本发明第四实施方式的多媒体视频通信系统结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明作进一步地详细描述。
本发明的第一实施方式涉及多媒体视频通信方法,其中包括H.264视频传送质量监测报告的方式和基于交互的错误消除方法。典型地应用于H.264双向视频系统,如视频电话等。双向视频系统的大致结构如图1所示。在双向视频通信模式下,通信系统的各个终端都既有编码器,又有解码器。基于这一特性,接收端可以将信息记入该终端编码码流的补充增强信息(Supplemental Enhancement Information,简称“SEI”)域中,发往远端。这样既不占用专门的反馈信道,又能加快信息反馈的速度。
接收端解码器将信息(如解码出错消息等)发送给本端编码器,这些信息在编码器被编写成为SEI扩展消息,之后进行网络抽象层(NetworkAbstraction Layer,简称“NAL”)的封装,添加NAL头信息,然后被发送到发送端的解码器,发送端解码器解读SEI扩展消息,根据情况的需要,可以将SEI扩展消息内容通知给本端编码器,编码器根据SEI扩展消息内容作出相应的动作。
H.264种提供了多种可以进行消息扩展的机制,本发明使用的是SEI。H.264中对SEI进行了定义,SEI的数据表示区域与视频编码数据独立,SEI的使用方法在H.264协议中NAL的描述中给出。H.264码流的基本单位是网络抽象层单元(Network Abstraction Layer Unit,简称“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消息的文法和语意。
SEI消息的结构如图2所示,每个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视频通信系统的兼容性。
图3示出本实施方式中H.264视频传送质量监测报告和交互错误消除的原理图。为了更清楚地说明,下面分别对接收端和发送端需要执行的流程加以说明。
接收端的处理流程如图4所示,在步骤401,接收端解码器接收视频数据包,并实时统计表示信道劣化程度的指标,本实施方式中以RTP包丢失率作为信道劣化程度的指标。其中,RTP包丢失率可以根据以下方式计算。
预先建立数据传输监测队列。该队列是一个循环队列,写满数据后,重新清空,供下一个统计周期使用。统计周期(或者叫做统计时间窗口)是tFQ,单位是秒。
队列长度 L VDTQI = t FQ * R Rev ‾ L RTP ,
其中,RRev为接收端的平均接收码率,单位是比特/秒(一般应与发送端的编码码率一致,因此也可以近似地使用编码控制的码率值),tFQ*RRev即在tFQ内获得码流长度,LRTP为一个RTP包的长度(单位是比特)。
对于以RTP包形式传输的视频压缩数据,接收端如果正确接收一个RTP包,则向队列中写入0,否则写入1。如图5所示。
当队列满时,开始实时统计此时队列中“1”的个数C1,并计算RTP包丢失率RLoss
R Loss = C 1 L VDTQI
队列内容实时地记录了当前网络传输丢包状况,预测并直接反映出接收端解码图像的质量变化。RLoss即数据传送质量系数VDTQI。VDTQI越大,说明当前网络状况越差。
当然反映H.264视频数据传送质量的参数不仅仅是VDTQI一项,还可以有其它信息,比如:出错图像编号,出错宏块序号等。VDTQI其实只是从RTP包丢失程度这个维度来刻画视频数据传送质量的一个指标。如果RTP包丢失,必然引起其中封装的H.264视频数据的丢失,那么就和出错图像编号,出错宏块序号这些信息是相关和对应的,后两者分别从图像层面和宏块层面来刻画视频数据的传送质量。
此后进入步骤402,接收端在对视频数据包解码时判断是否发现视频数据包接收错误,如果是则进入步骤403,否则返回步骤401。
在步骤403中,接收端进一步判断出错数据包中视频数据的编码类型,如果是帧间预测编码帧(如P帧)则进入步骤404,如果是帧内编码帧(如I帧)则进入步骤405。H.264定义的图像编码类型有IDR,P,B,PB四种。其中IDR类型是帧内编码类型,P和B类型是帧间预测编码类型。在帧内编码时,即时刷新(IDR)图像可以使前面参考图像缓存无效,之后的图像解码时不再参考IDR图像之前的图像,因而IDR图像具有很强的重同步性能。在一些丢包和误码严重的信道中,可以采取不定期传送IDR图像的方式来进一步提高H.264的抗误码性能。
在步骤404中,接收端向发送端反馈SEI扩展消息,此后返回步骤401。本实施方式通过SEI扩展消息,以带内方式反馈传送质量监测信息,相对于现有技术中以带外方式反馈,避免了额外信道的使用。因为仅在接收出错时反馈传送质量监测信息,相对于现有技术中周期性反馈的方式,减少了带宽的开销,提高了反馈的实时性。
SEI扩展消息的格式包含了SEI类型、SEI载荷长度、出错帧序号、出错宏块序号、代表RTP包丢失率的数据传送质量系数(VDTQI)和IDR帧刷新标志。其中SEI类型,SEI载荷长度合称SEI头信息,余下信息称为SEI有效载荷。
假如接收端解码器发现解码出错图像编号为260,该帧内出错宏块序号为56,数据传送质量系数为5,I帧数据未丢失,SEI类型取值定义为0x0A,表示SEI消息是反馈解码端的出错信息,SEI有效载荷长度为5个字节,则编写的SEI扩展消息如图6所示。最后两个字节是IDR帧刷新标志。如果这两个字节为0x00,则表明不需要发送端即时刷新,如果为0x01,则表明需要发送端即时刷新。在步骤404中,因为只是帧间预测编码帧出错,不需要即时刷新。
在步骤405中,接收端判断是否代表RTP包丢失率的数据传送质量系数(VDTQI)大于第一门限α,如果是则禁止接收端因本次接收出错向发送端请求重新发送IDR帧,否则进入步骤406。如若接收端发现I帧数据有丢失且当前VDTQI大于设定的门限,则表明当前信道丢包严重,即使发送端重新发送IDR帧,此IDR帧仍很有可能在传输过程中遭到破坏,导致接收端短期内持续要求刷新IDR帧。由于IDR帧数据量大,如此重复刷新IDR帧非但不会有效改善接收端图像质量,还可能造成信道负担过重,导致信道拥塞越来越严重。因此,在这种情况下,接收端不再发送IDR帧请求,直到VDTQI降低之后,再就当时状况采取相应措施。
在步骤406中,接收端立即暂停解码,编写SEI扩展消息,并将SEI扩展消息中IDR帧刷新标志置为0x01,发送该SEI扩展消息。此后回到步骤401。
发送端的处理流程如图7所示。
在步骤701中,发送端对视频数据进行压缩编码后发送,同时计算序列图像的优先级指标,按优先级指标由大至小进行排序并备份。本实施方式中,优先级指标为宏块刷新优先指标(Macroblock Refreshment Priority Index,简称“MRPI”),本发明并不排斥其它优先级指标。
确定MRPI的相关的因素包括:
(1)宏块的运动剧烈程度,可以用运动向量的范数大小(几何意义就是向量的长度)来度量。该数值越大则,MRPI应该越高。
(2)该宏块对于后续视频帧中其它宏块的影响程度。在后续N个帧中,直接依赖或者间接依赖于该宏块的宏块个数。该数值越大则,MRPI应该越高。
(3)H.264中原有判断进行帧内编码还是帧间预测编码的原则。通常为每一种可能的预测编码方式分别评估其COST(代价)函数值,选出COST函数值最小的一种作为正式的编码方式。COST函数值越大则,MRPI应该越低。
(4)该宏块在前若干帧中是否已经被刷新成帧内编码方式?如果有,则当前MRPI的值应该低,如果没有,则MRPI的数值应该高。如果有刷新,则刷新次数越多,当前MRPI数值越低。
因此,对于MRPI应该是以上因素的量化值作为变量的一个函数。应该是因素(1)的递增函数,因素(2)的递增函数,因素(3)的递减函数,因素(4)的递减函数。
当然还可以考虑其它因素。因此,MRPI的形式可以有很多种,只要满足以上条件。
本发明不限定具体的MRPI形式。下面是MRPI的一种具体形式:
以v1,v2,v3,v4(其中每个符号代表向量,即可以包含多个标量变量)表示因素(1),(2),(3),(4)对应的量化变量。那么
MRPI(v1,v2,v3,v4)=λ1f1(v1)+λ2f2(v2)+λ3f3(v3)+λ4f4(v4)   (3)
其中λ1λ2λ3λ4是非负的权重。
f1(v1)是变量v1的递增函数;对于v1是向量的情况,即f1(v1)是v1各个分量的递增函数;
f2(v2)是变量v2的递增函数;对于v2是向量的情况,即f2(v2)是v2各个分量的递增函数;
f3(v3)是变量v3的递减函数;对于v3是向量的情况,即f3(v3)是v3各个分量的递减函数;
f4(v4)是变量v4的递减函数;对于v4是向量的情况,即f4(v4)是v4各个分量的递减函数。
此后进入步骤702,发送端判断是否收到承载有质量监测信息的SEI扩展消息,如果是则说明发生了接收错误,进入步骤703,否则回到步骤701。
在步骤703中,发送端根据SEI扩展消息中IDR帧刷新标志的值判断接收端是否要求刷新IDR帧,如果是则进入步骤707,否则进入步骤704。
在步骤704中,发送端判断SEI扩展消息中表示RTP包丢失率的数据传送质量系数(VDTQI)是否大于第二门限β,如果是则进入步骤705,否则进入步骤706。
在步骤705中,发送端从出错位置开始,在当前视频帧或者紧接着的下一个视频帧中,选取N1个MRPI值最大的宏块进行帧内编码并发送。当收到VDTQI信息时,如果还来得及,在当前帧执行该策略;如果来不及,比如当前帧的主要部分大多编码完了,剩下的宏块已不够N个了,就在下一帧处理。此后回到步骤701。
在步骤706中,发送端从出错位置开始,在当前视频帧或者紧接着的下一个视频帧中,选取N2个MRPI值最大的宏块进行帧内编码并发送,此后回到步骤701。其中N2大于N1。
数据传送质量系数(VDTQI)实际上代表了信道劣化程度,步骤704到步骤706的基本思想是根据信道劣化程度,选择优先级指标最高的N个宏块经帧内编码后发送给接收端,用于接收端的错误消除。根据信道劣化程度得到N的方式有多种,步骤704到706是一种较为简单的方式,原则上信道劣化程度较高时N应当较小,实际操作中最好还能兼顾考虑错误消除能力和额外带宽开销。因为信道劣化程度较高时使用帧内编码的数据较少,而帧内编码产生的数据量较多,所以不会在信道劣化时使传送环境进一步恶化。因为传的是优先级指标最高的部分视频数据,所以传送同样的数据量时对接收端错误消除的帮助最大。
在步骤707中,根据接收端的要求,发送端进行IDR帧编码,并发送IDR帧。此后回到步骤701。
在本发明第二实施方式也涉及多媒体视频通信方法,第二实施方式与第一实施方式大致相同,区别仅在于,第一实施方式的步骤704到706中,发送端仅根据一个门限β选择N1或N2个MRPI值最大的宏块用于错误消除,而第二实施方式根据多个门限选择用于错误消除的MRPI值最大的宏块的数目。具体地说,可以设定3个门限β1、β2和β3,β1<β2<β3。如果VDTQI小于β1则选取N1个MRPI值最大的宏块进行帧内编码并发送,如果VDTQI大于等于β1小于β2则选取N2个MRPI值最大的宏块进行帧内编码并发送,如果VDTQI大于等于β2小于β3则选取N3个MRPI值最大的宏块进行帧内编码并发送,VDTQI大于β3则选取N4个MRPI值最大的宏块进行帧内编码并发送。相对于第一实施方式,较多的门限可以更好地适应信道的情况。
在本发明第三实施方式也涉及多媒体视频通信方法,第三实施方式与第一实施方式大致相同,区别仅在于,第一实施方式通过SEI扩展消息传送传送质量监测信息,而第三实施方式使用RTCP协议传送传送质量监测信息。RTCP消息中可能不含与RTP包丢失率,而是携带具体的丢包信息,不过同样可以通过这些具体的丢包信息在发送端计算出RTP包丢失率或其它可以表示信道劣化程度的指标。
第三实施方式相对于第一实施方式修改在于:在步骤401和步骤406中,接收端改为通过RTCP消息传送传送质量监测信息;在步骤402中,不是由接收端因接收数据包时出错而触发传送传送质量监测信息的反馈,而是将先错误记录下来,通过周期性的机制(如时钟信号)触发传送传送质量监测信息反馈时一并发送。在步骤702中,发送端改为接收RTCP消息即可。
从第三实施方式可以看出,本发明提出的错误消除方法可以应用于各种反馈的方式,并不限于以带内方式反馈传输传送质量监测信息。
此外,还可以同时使用SEI和RTCP进行反馈,当然反馈的内容可以有分工。
本发明的第四实施方式涉及一种多媒体视频通信系统,如图8所示,包括发送端设备(简称“发送端”)和接收端设备(简称“接收端”)。
接收端进一步包含:
解码单元,用于解码来自发送的H.264视频数据并监测视频数据的接收错误,这些视频数据承载在RTP包中传输到接收端;
RTP包丢失率计算单元,用于计算解码单元所收的的RTP包的丢失率,该指标可以指示信道劣化程度。该单元进一步包含:
用于统计的队列;
收到RTP包时,根据接收的结果向队列写入表示正确或错误的标志的模块;
当队列满时,将该队列中表示错误的标志数目除以队列的长度得到RTP包丢失率的模块;
其中,队列的长度=统计周期×接收端的平均接收码率/每个RTP包的长度。
出错类型判断单元,用于判断解码单元接收出错的视频数据帧的预测编码类型。有两种判断结果,一种是帧内编码,,另一种是帧间预测编码,。如果是帧间预测编码是直接通知反馈消息生成单元生成SEI扩展消息,如果是帧内编码则指示劣化程度判断单元根据信道劣化程度的判断是否需要进行反馈,如果判断结果是需要反馈,则通知反馈消息生成单元生成SEI扩展消息。
劣化程度判断单元,用于从RTP包丢失率计算单元得到RTP包丢失率,并判断RTP包丢失率是否小于在先设置的第一门限,将判断结果输出到反馈消息生成单元,通知反馈消息生成单元根据判断结果生成SEI扩展消息。
反馈消息生成单元,用于生成携带有传送质量监测信息的SEI扩展消息,通过编码单元以带内方式向发送端反馈。SEI扩展消息承载的传送质量监测信息包含:出错帧序号、出错宏块序号、RTP包丢失率、和IDR帧刷新标志。其中RTP包丢失率用于指示信道劣化程度。
反馈消息生成单元根据出错类型判断单元和劣化程度判断单元的不同判断结果生成不同的的SEI扩展消息,具体地说:
如果出错类型判断单元判定出错的视频数据是帧间预测编码帧,则生成携带传送质量监测信息的SEI扩展消息,其中不设置要求IDR帧刷新的标志;
如果出错类型判断单元判定出错的视频数据是帧内编码帧,并且劣化程度判断单元判定RTP包丢失率小于第一门限,则生成携带传送质量监测信息的SEI扩展消息,其中设置要求IDR帧刷新的标志;
如果出错类型判断单元判定出错的视频数据是帧内编码帧,并且劣化程度判断单元判定RTP包丢失率大于第一门限,则不因本次接收出错生成和发送SEI扩展消息。
发送端进一步包含:
解码单元,用于以带内方式接收接收端反馈的传送质量监测信息,具体地说是接收和解析来自接收端的SEI扩展消息,并将传送质量监测信息提供给选择单元。传送质量监测信息中包含传送出错的视频数据的标识和指示信道劣化程度的信息
优先级计算单元,用于计算视频数据的优先级指标,并对计算的结果进行排序和保留。通常可以以宏块为单元计算优先级指标,该优先级指标可以是MRPI,详见第一实施方式中的相关描述。
选择单元,根据解码单元提供的传送质量监测信息中的信道劣化程度,在当前视频帧或者紧接着的下一个视频帧中选择优先级指标最高的N个单位的视频数据,并将选择结果通知编码单元。
编码单元,用于压缩编码和发送视频数据,如果选择单元有指示,则以对选择单元指示的N个单位的视频数据进行帧内编码。
需要指出的是,本发明中所提到的各种单元或模块都是逻辑的,可以合并或进一步拆分,只要能够完成相应的功能就属于本发明的范围。例如可以将接收端的反馈消息生成单元和编码单元合并为反馈单元,反馈单元的功能是反馈消息生成单元和编码单元的合集。各单元可以在同一个物理实体上实现也可以分别在不同的物理实体上实现,甚至一个单元都可以以分布式的方式由多个物理实体同共实现。
虽然通过参照本发明的某些优选实施方式,已经对本发明进行了图示和描述,但本领域的普通技术人员应该明白,可以在形式上和细节上对其作各种改变,而不偏离本发明的精神和范围。

Claims (22)

1.一种多媒体视频通信方法,其特征在于,包含以下步骤:
接收端以带内方式向发送端反馈已收到的视频数据的传送质量监测信息,使所述发送端根据带内反馈的所述传送质量监测信息调整需要向所述接收端发送的视频数据的压缩编码属性;
其中,当所述接收端监测到收到的视频数据发生错误时,反馈的所述传送质量监测信息中包含用于定位传送出错的视频数据的标识和指示信道劣化程度的信息。
2.根据权利要求1所述的多媒体视频通信方法,其特征在于,所述发送端将所述传送质量监测信息承载在补充增强信息SEI扩展消息中,以带内方式反馈给所述发送端。
3.根据权利要求2所述的多媒体视频通信方法,其特征在于,所述SEI扩展消息承载的传送质量监测信息至少包含以下之一:
出错帧序号、出错宏块序号、实时传送协议RTP包丢失率、即时刷新帧刷新标志。
4.根据权利要求3所述的多媒体视频通信方法,其特征在于,所述RTP包丢失率通过以下步骤获得:
收到RTP包时,根据接收的结果向用于统计的队列中写入表示正确或错误的标志;
当所述队列满时,将该队列中表示错误的标志数目除以队列的长度得到所述RTP包丢失率。
5.根据权利要求4所述的多媒体视频通信方法,其特征在于,所述用于统计的队列的长度按照如下方式进行计算和设置:
队列的长度=统计周期×接收端的平均接收码率/每个RTP包的长度。
6.根据权利要求1所述的多媒体视频通信方法,其特征在于,所述发送端通过以下步骤确定向所述接收端发送的用来进行错误消除的视频数据:
所述发送端根据信道劣化程度,在当前视频帧或者紧接着的下一个视频帧中选择优先级指标最高的N个单位的视频数据进行帧内编码,将帧内编码后的视频数据作为所述用来进行错误消除的视频数据发送给所述接收端。
7.根据权利要求6所述的多媒体视频通信方法,其特征在于,通过以下方式根据信道劣化程度确定N的大小:
在先设定m个门限β1到βm,m+1个正整数N1到Nm+1,其中m为正整数,βi<βi+1,1≤i≤m-1;
如果表示信道劣化程度的指标小于β1,则N取值为N1
如果表示信道劣化程度的指标大于等于βi并小于βi+1,1≤i≤m-1,则N取值Ni+1
如果表示信道劣化程度的指标大于等于βm,则N取值Nm+1
其中,表示信道劣化程度的指标值越大表示信道越差。
8.根据权利要求6所述的多媒体视频通信方法,其特征在于,所述信道劣化程度以RTP包丢失率来指示;
所述出错的视频数据的标识为视频帧序号和/或宏块序号;
所述单位为宏块。
9.根据权利要求8所述的多媒体视频通信方法,其特征在于,所述优先级指标满足以下条件之一或其任意组合:
所述优先级指标是宏块的运动剧烈程度的递增函数;
所述优先级指标是宏块对于后续视频帧中其它宏块的影响程度的递减函数;
所述优先级指标是用于判决预测编码类型的代价函数值的递减函数;
所述优先级指标是宏块在当前帧之前预定数目的各帧中被刷新成帧内编码方式的次数的递减函数。
10.根据权利要求8所述的多媒体视频通信方法,其特征在于,所述优先级指标是以下四个函数中的一个或者多个的加权线性组合,并且每个函数对应的加权系数为非负数:
一个关于宏块的运动剧烈程度的递增函数;
一个关于宏块对于后续视频帧中其它宏块的影响程度的递减函数;
一个关于用于判决预测编码类型的代价函数值的递减函数;
一个关于宏块在当前帧之前预定数目的各帧中被刷新成帧内编码方式的次数的递减函数。
11.根据权利要求8所述的多媒体视频通信方法,其特征在于,如果所述出错的视频数据是帧间预测编码帧,则所述发送端根据RTP包丢失率,从出错位置开始,每次选取优先级指标最高的N个宏块经帧内编码后发送给所述接收端。
12.根据权利要求8所述的多媒体视频通信方法,其特征在于,如果所述出错的视频数据是帧内编码帧,且RTP包丢失率小于在先设置的第一门限,则所述接收端立即暂停解码,通过所述SEI扩展消息请求所述发送端重新发送即时刷新帧;
所述发送端将视频帧进行及时刷新编码,然后把该即时刷新帧作为所述用来进行错误消除的视频数据发送给所述接收端。
13.根据权利要求8所述的多媒体视频通信方法,其特征在于,如果所述出错的视频数据是帧内编码帧,且RTP包丢失率大于在先设置的第一门限,则禁止所述接收端因本次接收出错向所述发送端请求重新发送即时刷新帧。
14.一种多媒体视频通信系统,其特征在于,接收端包含:以带内方式向发送端反馈已收到的视频数据的传送质量监测信息的反馈单元;
发送端包含:以带内方式接收所述接收端反馈的传送质量监测信息的单元,和根据反馈的传送质量监测信息调整需要向该接收端发送的视频数据的压缩编码属性的单元;
其中,所述反馈单元在所述接收端监测到收到的视频数据发生错误时,反馈的所述传送质量监测信息中包含用于定位传送出错的视频数据的标识和指示信道劣化程度的信息。
15.根据权利要求14所述的多媒体视频通信系统,其特征在于,所述发送端将所述传送质量监测信息承载在补充增强信息SEI扩展消息中,以带内方式反馈给所述发送端;
所述SEI扩展消息承载的传送质量监测信息至少包含以下之一:
出错帧序号、出错宏块序号、RTP包丢失率、即时刷新帧刷新标志。
16.根据权利要求15所述的多媒体视频通信系统,其特征在于,所述接收端还包含计算RTP包丢失率的单元,该单元包含:
用于统计的队列;
收到RTP包时,根据接收的结果向所述队列写入表示正确或错误的标志的模块;
当所述队列满时,将该队列中表示错误的标志数目除以队列的长度得到所述RTP包丢失率的模块;
其中,所述队列的长度=统计周期×接收端的平均接收码率/每个RTP包的长度。
17.根据权利要求14所述的多媒体视频通信系统,其特征在于,
所述发送端还包含:
用于计算视频数据的优先级指标的单元;
根据信道劣化程度,通过对于当前视频帧或者紧接着的下一个视频帧中的多个单位的视频数据的优先级指标的计算,在当前视频帧或者紧接着的下一个视频帧中选择优先级指标最高的N个单位的视频数据,通知用于视频压缩编码的单元对于这N个单位的视频数据进行帧内编码,以作为接收端进行错误消除的视频数据的单元。
18.根据权利要求15所述的多媒体视频通信系统,其特征在于,所述接收端还包含:判断出错的视频数据帧预测编码类型的类型判断单元;和判断RTP包丢失率是否小于在先设置的第一门限的劣化程度判断单元;
如果所述类型判断单元判定出错的视频数据是帧内编码帧,并且所述劣化程度判断单元判定RTP包丢失率小于第一门限,则在发送给所述发送端的SEI扩展消息请求中设置要求即时刷新的标志;
如果所述类型判断单元判定出错的视频数据是帧内编码帧,并且所述劣化程度判断单元判定RTP包丢失率小于第一门限,则禁止所述反馈单元因本次接收出错发送所述SEI扩展消息;
如果所述类型判断单元判定出错的视频数据是帧间预测编码帧,则向所述发送端发送所述SEI扩展消息,报告所述的视频数据传送质量监测信息。
19.一种多媒体视频通信中错误消除方法,其特征在于,包含以下步骤:
发送端接收来自接收端的传送出错的视频数据的标识和指示信道劣化程度的信息;
所述发送端根据信道劣化程度,在当前视频帧或者紧接着的下一个视频帧中选择优先级指标最高的N个单位的视频数据进行帧内编码后发送给所述接收端,所述接收端使用所述N个单位的帧内编码视频数据进行错误消除。
20.根据权利要求19所述的多媒体视频通信中错误消除方法,其特征在于,所述信道劣化程度以RTP包丢失率指示;
所述出错的视频数据的标识为视频帧序号和/或宏块序号;
所述单位为宏块。
21.根据权利要求20所述的多媒体视频通信中错误消除方法,其特征在于,所述优先级指标满足以下条件之一或其任意组合:
所述优先级指标是宏块的运动剧烈程度的递增函数;
所述优先级指标是宏块对于后续视频帧中其它宏块的影响程度的递减函数;
所述优先级指标是用于判决预测编码类型的代价函数值的递减函数;
所述优先级指标是宏块在当前帧之前预定数目的各帧中被刷新成帧内编码方式的次数的递减函数。
22.一种多媒体视频通信中错误消除系统,其特征在于,接收端包含:用于将传输出错的视频数据的标识和指示信道劣化程度的信息发送给发送端的单元;和使用来自发送端的视频数据进行错误消除的单元;
发送端包含:
用于计算视频数据的优先级的单元;
接收来自接收端信息的单元;和
根据信道劣化程度,在出错的视频数据中选择优先级最高的N个单位的视频数据进行帧内编码后发送给所述接收端的单元。
CN 200610139177 2006-10-16 2006-10-16 多媒体视频通信方法及系统 Expired - Fee Related CN100558167C (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN 200610139177 CN100558167C (zh) 2006-10-16 2006-10-16 多媒体视频通信方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN 200610139177 CN100558167C (zh) 2006-10-16 2006-10-16 多媒体视频通信方法及系统

Publications (2)

Publication Number Publication Date
CN101166270A CN101166270A (zh) 2008-04-23
CN100558167C true CN100558167C (zh) 2009-11-04

Family

ID=39334705

Family Applications (1)

Application Number Title Priority Date Filing Date
CN 200610139177 Expired - Fee Related CN100558167C (zh) 2006-10-16 2006-10-16 多媒体视频通信方法及系统

Country Status (1)

Country Link
CN (1) CN100558167C (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI411307B (zh) * 2010-08-11 2013-10-01 Univ Hungkuang Video playback fluency priority link source channel coding system

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101651790A (zh) * 2008-08-15 2010-02-17 康佳集团股份有限公司 电视机、指示电视信号强度的装置和方法
US8878912B2 (en) 2009-08-06 2014-11-04 Qualcomm Incorporated Encapsulating three-dimensional video data in accordance with transport protocols
CN102316360B (zh) * 2010-07-09 2015-11-25 华为终端有限公司 视频刷新方法、装置及系统
EP2432161B1 (en) * 2010-09-16 2015-09-16 Deutsche Telekom AG Method of and system for measuring quality of audio and video bit stream transmissions over a transmission chain
CN102025993B (zh) * 2010-12-17 2014-01-08 深圳中兴力维技术有限公司 一种基于h.264的视频传输方法及系统
CN102594778A (zh) * 2011-01-11 2012-07-18 中兴通讯股份有限公司 一种流媒体反馈的实现方法和系统
US8483044B2 (en) * 2011-06-01 2013-07-09 Radvision Ltd. Systems, methods, and media for identifying degraded video call links
CN104113722A (zh) * 2014-06-19 2014-10-22 南京熊猫电子股份有限公司 一种无线视频会议传输方法
CN107872675B (zh) * 2016-09-26 2020-06-16 联芯科技有限公司 基于h.264的视频数据的修复方法和传输的数据端
WO2018121775A1 (en) 2016-12-30 2018-07-05 SZ DJI Technology Co., Ltd. System and methods for feedback-based data transmission
CN107113441B (zh) 2016-12-30 2019-07-26 深圳市大疆创新科技有限公司 图像处理方法、装置、无人飞行器和接收端
CN109936746B (zh) 2016-12-30 2021-07-16 深圳市大疆创新科技有限公司 图像处理方法与设备
CN106961627B (zh) * 2017-03-24 2019-07-02 北京金风易通科技有限公司 一种提高实时视频播放质量的方法
CN106998328B (zh) * 2017-03-30 2019-12-13 北京奇艺世纪科技有限公司 一种视频传输方法及装置
US10862620B2 (en) * 2017-09-25 2020-12-08 Dolby Laboratories Licensing Corporation Systems and methods to optimize the load of multipath data transportation
CN112995214B (zh) * 2021-04-26 2021-08-10 安心智能(武汉)信息技术有限公司 一种实时视频传输系统、方法及计算机可读存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI411307B (zh) * 2010-08-11 2013-10-01 Univ Hungkuang Video playback fluency priority link source channel coding system

Also Published As

Publication number Publication date
CN101166270A (zh) 2008-04-23

Similar Documents

Publication Publication Date Title
CN100558167C (zh) 多媒体视频通信方法及系统
CN100466725C (zh) 多媒体通信方法及其终端
CN100456834C (zh) H.264多媒体通信的服务质量监测方法
CN100459717C (zh) 基于h.264的压缩视频传输误码消除方法
US8015474B2 (en) Adaptive forward error correction
CN101636983B (zh) 用于减少视频传输时的分组丢失的影响的方法和系统
CN1801944B (zh) 用于视频编码和解码的方法和设备
CN1934865B (zh) 调整编码器和解码器中缓冲器的大小的方法及装置
CN101686106B (zh) 自适应前向纠错的方法、装置和系统
US8127040B2 (en) Signaling buffer parameters indicative of receiver buffer architecture
EP1359722A1 (en) Data streaming system and method
WO2006105713A1 (en) Video transmission protection method based on h.264
CN101611551A (zh) 用于视频通信系统中的差错弹性的改进系统和方法
CN102036071A (zh) 用于视频通信系统中的差错弹性和随机接入的系统和方法
KR20100005132A (ko) 피드백 기반 스케일러블 비디오 코딩
CN101562615A (zh) 基于mpeg-4编码的多媒体数据流自适应网络带宽的传输方法
KR20040093483A (ko) 데이터 스트리밍 시스템을 위한 데이터 구조
US20120082214A1 (en) Delay Aware Rate Control In The Context Of Hierarchical P Picture Coding
WO2006027661A1 (en) System and method for using redundant representations in streaming applications
CN102316360B (zh) 视频刷新方法、装置及系统
JP2005033556A (ja) データ送信装置、データ送信方法、データ受信装置、データ受信方法
JP2002064472A (ja) 通信システム、送信機及び伝送誤りの防止方法
Ganguly et al. A-REaLiSTIQ-ViBe: Entangling Encoding and Transport to Improve Live Video Experience
US8040945B1 (en) System and method for encoding a single video stream at a plurality of encoding rates
Liu et al. RTP/AVPF compliant feedback for error resilient video coding in conversational applications

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: 20091104

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