CN101883240A - 基于mcu的视频会议***及其视频传输丢包处理的方法 - Google Patents
基于mcu的视频会议***及其视频传输丢包处理的方法 Download PDFInfo
- Publication number
- CN101883240A CN101883240A CN2010101974830A CN201010197483A CN101883240A CN 101883240 A CN101883240 A CN 101883240A CN 2010101974830 A CN2010101974830 A CN 2010101974830A CN 201010197483 A CN201010197483 A CN 201010197483A CN 101883240 A CN101883240 A CN 101883240A
- Authority
- CN
- China
- Prior art keywords
- packet loss
- mcu
- subcode stream
- video
- coding side
- 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.)
- Granted
Links
Images
Landscapes
- Compression Or Coding Systems Of Tv Signals (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明视频传输丢包处理的方法,包括:编码端采样与编码,将获得的子码流按UDP协议发送至MCU服务端;MCU服务端对子码流进行丢包检测,然后返回反馈信息至编码端;编码端根据反馈信息,执行丢包处理策略;MCU服务端将丢包检测后的子码流按UDP协议发送至解码端;解码端进行丢包检测和重组,在子码流丢包时返回终止数据发送的请求至MCU服务端,MCU服务端接收该请求并执行;解码端对丢包检测与重组后的子码流进行解码获得视频图像。本发明基于MCU的视频会议***,包括采样编码模块、编码端发送控制模块、数据包分析模块、MCU发送控制模块、分析重组模块和解码模块。本发明既能提高传输的实时性,还能提高传输的可靠性。
Description
技术领域
本发明涉及视频传输领域,具体为一种基于MCU的视频会议***和一种基于MCU的视频会议***中视频传输丢包处理的方法。
背景技术
现有基于MCU(Multipoint Control Unit,即多点控制单元)的视频会议***,如图1所示,一般包括编码端、MCU服务端和解码端。其中,MCU服务端是视频会议***中的重要组成部分,它的作用主要是协调和控制编码端与解码端之间的视频数据传输。视频会议***的一项重要功能就是实现视频的实时传输,一般传输视频数据所采用的传输协议是TCP(TransmissionControl Protocol)协议或者UDP(User Datagram Protocol)协议。
TCP协议比较可靠,它是一种面向连接的、基于字节流的运输层通信协议。使用TCP协议可以保证数据传输的可靠性,但是这种可靠性是建立在丢失数据的重传之上。例如,发送端将一个视频数据段发送出去的同时会启动一个重发定时器,如果该重发定时器超过预定时间也没有接收到接收端的确认信息,那么发射端会重传该数据段。这样不但增加了传输的数据量,而且牺牲了视频数据传输的实时性,造成视频图像的延时。
UDP协议是OSI参考模型中一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务。传输数据之前源端和终端是不需要建立连接的,发送数据时也不需要确认是否正确接收。由于使用UDP协议传输数据具有发送效率高、实时性强的优点,使用UDP协议进行视频数据传输是目前大多数视频会议软件选择的方式。但是UDP协议无法保证数据传输的可靠性,一旦视频出现数据包丢失,那么解码图像很可能出现质量严重下降,例如马赛克的出现。
发明内容
本发明的目的在于,提出一种基于MCU的视频会议***和一种基于MCU的视频会议***中视频传输丢包处理的方法,能够实时传输视频数据,并提高视频传输的可靠性。
本发明基于MCU的视频会议***中视频传输丢包处理的方法,该基于MCU的视频会议***包括编码端、MCU服务端和解码端,其中,该视频传输丢包处理的方法具体包括:
步骤S1,所述编码端对视频图像进行采样与编码,将编码后获得的子码流按UDP协议发送至所述MCU服务端。
步骤S2,所述MCU服务端对接收到的子码流进行丢包检测,然后返回反馈信息至所述编码端;所述反馈信息包括丢包检测结果。
步骤S3,所述编码端根据所述反馈信息,执行丢包处理策略;其中,所述丢包处理策略包括:对发生丢包的子码流所属的图像组序列,所述编码端停止向所述MCU服务端发送该图像组序列的剩余数据。
步骤S4,所述MCU服务端将丢包检测后的子码流按UDP协议发送至所述解码端。
步骤S5,所述解码端接收到所述子码流后进行丢包检测和重组,出现子码流丢包时返回终止数据发送的请求至所述MCU服务端;所述MCU服务端根据所述请求,对发生丢包的子码流所属的图像组序列,停止向所述解码端发送该图像组序列的剩余数据。
步骤S6,所述解码端对丢包检测与重组后的子码流进行解码获得视频图像。
本发明还同时提出一种基于MCU的视频会议***,该基于MCU的视频会议***包括编码端、MCU服务端和解码端。
其中,所述编码端包括用于对视频图像进行采样和编码的采样编码模块、以及用于对子码流进行发送与控制的编码端发送控制模块。所述MCU服务端包括用于对接收的子码流进行丢包检测和丢包率统计的数据包分析模块,以及用于对子码流进行发送与控制的MCU发送控制模块。所述解码端包括用于对接收的子码流进行丢包检测与重组的分析重组模块,以及用于对子码流进行解码的解码模块。
所述采样编码模块对视频图像进行采样与编码,所述编码端发送控制模块将编码后获得的子码流按UDP协议发送至所述MCU服务端。
所述数据包分析模块对所述MCU服务端接收到的子码流进行丢包检测,然后所述MCU服务端根据丢包检测结果返回反馈信息至所述编码端。
所述编码端发送控制模块根据所述反馈信息,执行丢包处理策略;其中,所述丢包处理策略包括:对发生丢包的子码流所属的图像组序列,所述编码端发送控制模块停止向所述MCU服务端发送该图像组序列的剩余数据。
所述MCU发送控制模块将丢包检测后的子码流按UDP协议发送至所述解码端;所述分析重组模块接收到所述子码流后进行丢包检测与重组,所述解码端在出现子码流数据包丢失时返回终止数据发送的请求至所述MCU服务端;所述MCU发送控制模块根据所述请求,对发生丢包的子码流所属的图像组序列,停止向所述解码端发送该图像组序列的剩余数据;所述解码模块对丢包检测与重组后的子码流进行解码获得视频图像。
本发明的技术方案,在传输子码流时都采用UDP协议进行传输,充分保证了视频数据传输的实时性;而且MCU服务端和解码端在接收数据时都进行丢包检测,在发生丢包时利用消息反馈的手段进行反馈,可以停止无用数据的发送,避免利用这些无用数据解码出现马赛克的现象,充分降低了带宽占用,提高视频传输的可靠性。
附图说明
图1为基于MCU的视频会议***结构示意图;
图2为基于MCU的视频会议***中视频传输丢包处理的方法流程示意图;
图3为两路子码流关键帧交替出现示意图;
图4为基于MCU的视频会议***内部组成示意图;
图5为实施例4提出的基于MCU的视频会议***内部组成示意图。
具体实施方式
实施例1:
本实施例是基于MCU的视频会议***中视频传输丢包处理的方法,该基于MCU的视频会议***如图1所示,包括编码端、MCU服务端和解码端。本实施例中,仅以一个解码端进行描述。其中,该视频传输丢包处理的方法具体如图2所示,包括:
步骤S1,编码端对视频图像进行采样与编码,将编码后获得的子码流按UDP协议发送至MCU服务端。编码端对采集的视频图像进行隔行下采样,然后将图像送入H.264编码器进行编码获得子码流。
步骤S2,MCU服务端对接收到的子码流进行丢包检测,然后返回反馈信息至编码端。每一路子码流包含若干数据包,每个数据包的包头都会有唯一的编号-PacketNum,PacketNum是逐一递增的,MCU服务端在接收子码流时等待指定PacketNum的数据包到来,若发现收到的数据包的PacketNum发生跳跃,则认为当前等待的数据包已经丢失,则会按TCP协议发送反馈消息至编码端,该反馈消息中包含发生丢包的子码流的信息。
步骤S3,编码端根据反馈信息,确定发送的子码流是否发生丢包情况,若发生丢包则执行相应的丢包处理策略。即对发生丢包的子码流所属的图像组序列,编码端停止向MCU服务端发送该图像组序列的剩余数据。这些剩余数据属于无用数据,若根据这些无用的数据进行解码,很可能解码后获得的图像出现马赛克。同时,停止这些无用数据的发送,还能够节省网络带宽,降低编码端和MCU服务端的带宽占用。
步骤S4,MCU服务端将丢包检测后的子码流按UDP协议发送至解码端。在丢包检测后,若未发生丢包情况,则MCU服务端将接收的完整子码流传输至解码端;若发生丢包情况,因为已经停止该子码流所述图像组序列的剩余数据的发送,则将已接收的子码流中的数据发送至解码端。
步骤S5,解码端接收到子码流后进行丢包检测和重组,解码端进行丢包检测的过程与MCU服务端进行丢包检测的过程相同,数据包重组是指将属于同一帧的数据包视频数据组合在一起,每个数据包包头都有一个帧索引-FrameIndex,可以利用这个索引将同帧的所有数据包组合在一起。同样,丢包检测之后,若发生子码流丢包的情况,解码端返回一个请求至MCU服务端,要求终止数据发送。MCU服务端根据返回的这个请求,对发生丢包的子码流所属的图像组序列,停止向解码端发送该图像组序列的剩余数据。这里,同样起到避免使用无用数据解码使解码图像出现马赛克的情况,并同时降低了MCU服务端和解码端的带宽占用。
步骤S6,解码端对丢包检测与重组后的子码流进行解码获得视频图像。
通过本实施例的描述,该视频传输丢包处理的方法使用UDP协议进行视频数据传输保证视频的实时性,并在子码流发生丢包情况时通过消息反馈的手段要求停止无用数据的发送,降低了带宽占用,也提高了视频传输的可靠性。
实施例2:
本实施例同样描述一种基于MCU的视频会议***中视频传输丢包处理的方法,该基于MCU的视频会议***如图1所示,包括编码端、MCU服务端和解码端,其中,该视频传输丢包处理的方法具体包括:
步骤S1,编码端对视频图像进行采样与编码,将编码后获得的子码流按UDP协议发送至MCU服务端。编码端对采集的视频图像进行隔行下采样,然后将采样获得的图像分成第一子图像和第二子图像,再将这两个子图像分别放入不同的H.264编码器进行编码,编码得出的码流称作第一子码流和第二子码流。
在上述编码过程中,可以对子码流关键帧的出现进行控制,即,将两个子码流的关键帧周期都设置为相同值,但关键帧的出现的时间是交替的,如图3所示,在图3中,IDR(Instantaneous Decoding Refresh)表示即时解码刷新。用GopSize表示关键帧周期,编码端将第一子图像和第二子图像关键帧的间隔帧数都设置为然后根据帧序FrameNum进行调整,具体为:在时,编码端只对第一子图像进行编码;在时,编码端对第一子图像和第二子图像都进行编码。编码端再将编码后获得的这两路子码流按UDP协议发送至MCU服务端。
步骤S2,MCU服务端对接收到的子码流进行丢包检测和丢包率的统计,然后返回反馈信息至编码端。本步骤中,MCU服务端进行丢包检测的过程可以参考实施例1中步骤S2对丢包检测的描述,同样是检测数据包的PacketNum是否发生跳跃,若发生跳跃则认为当前等待的数据包已经丢失。同时,MCU服务端还会按照预定的时间间隔(例如30秒)进行丢包率的统计,丢包率按照公式(1-实际接收数据包数/应该接收数据包数)×100%进行计算。然后MCU服务端将包含丢包检测结果和丢包率的反馈信息以TCP方式发送至编码端。
步骤S3,编码端根据反馈信息,确定是否哪路子码流发生丢包,并按照发生丢包的子码流以及丢包率执行丢包处理策略。丢包处理策略包括:
1)若第一子码流发生丢包情况,则编码端停止向MCU服务端发送第一子码流所属图像组序列的剩余数据。若第二子码流发生丢包情况,则采取同样的处理方式。
2)根据返回的不同丢包率,执行以下处理策略:
当丢包率为0%-10%时,编码端不做任何处理;
当丢包率为10%-20%时,编码端将对应同一帧的两个子码流的数据包发送间隔进行设置,该发送间隔最小为1帧,最大为5帧,即发送间隔在1帧以上并且在5帧以下;
当丢包率为20%-30%时,编码端在第一子码流和第二子码流中任意选择一路子码流发送至MCU服务端;此种情况下,丢包率较为严重,除了停止无用数据的发送,再次发送子码流时,只传输一路子码流数据,以保证视频的流畅性;
当丢包率大于30%时,编码端在第一子码流和第二子码流中任意选择一路子码流,并将该子码流的编码帧率降低为10fps以上,再将编码帧率降低后的子码流发送至MCU服务端。当丢包率在30%以上,属于丢包率非常严重的情况,此时仅传输一路子码流是不够的,还需要降低编码帧率,使降低编码帧率后的子码流能够适应恶劣的网络带宽,来保证视频的流畅性。
步骤S4,MCU服务端将丢包检测后的子码流按UDP协议发送至解码端。
步骤S5,解码端接收到子码流后进行丢包检测和重组,在子码流丢包时返回终止数据发送的请求至MCU服务端;MCU服务端根据请求,对发生丢包的子码流所属的图像组序列,停止向解码端发送该图像组序列的剩余数据。本步骤丢包检测的过程和步骤S2中丢包检测过程相同。解码端对子码流进行重组的过程也与实施例1中步骤S5中对子码流进行重组的过程相同,即根据帧索引FrameIndex将同帧的所有数据包的视频数据组合在一起。
步骤S6,解码端对丢包检测与重组后的子码流进行解码获得视频图像。本实施例中,解码端接收到的子码流包括两种情况:
A)解码端接收到两路子码流,即当前帧的第一子码流和第二子码流的完整数据都被接收到,则解码端对两个子码流的数据进行解码,然后再对解码后的图像进行拼接处理,再对拼接处理后的图像进行滤波处理,获得质量最好的图像。
B)解码端仅接收到一路子码流,此处以仅接收到第一子码流为例,如果当前帧的第一子码流的完整数据被接收到,则解码端对第一子码流中的数据进行解码后,再对解码获得的图像进行图像还原处理,例如,可以采用隔行插值的办法进行图像还原过程,获得可以接受的图像。
传统视频会议***中使用的是单流模式,当一个GOP(Group of Pictures,图像组)序列中出现数据包丢失,为了保证图像不出现质量下降的情况,解码端只能放弃GOP序列后续数据的解码,因此视频的流畅性较差,并且浪费带宽。但通过上述描述,本实施例采用双流模式进行传输,并且利用相应的反馈和丢包处理策略,使得解码端在接收到两路子码流的情况能够获得质量最好的图像,即使丢失了一路子码流,也可以利用另外一路子码流还原出令人可以接受的视频图像,尽可能地保证视频流畅性;同时,利用MCU服务端和解码端的消息反馈,能够停止无用数据的发送,尽最大可能降低带宽占用。
实施例3:
本实施例提出一种基于MCU的视频会议***,该基于MCU的视频会议***包括编码端、MCU服务端和解码端。
其中,如图4所示,编码端包括用于对视频图像进行采样和编码的采样编码模块、以及用于对子码流进行发送与控制的编码端发送控制模块。MCU服务端包括用于对接收的子码流进行丢包检测和丢包率统计的数据包分析模块,以及用于对子码流进行发送与控制的MCU发送控制模块。解码端包括用于对接收的子码流进行丢包检测与重组的分析重组模块,以及用于对子码流进行解码的解码模块。
基于MCU的视频会议***工作过程如下:
采样编码模块对视频图像进行隔行下采样,然后将采样的图像送入H.264编码器进行编码,编码端发送控制模块将编码获得的子码流按UDP协议发送至MCU服务端。
数据包分析模块对MCU服务端接收到的子码流进行丢包检测,然后MCU服务端根据丢包检测结果返回反馈信息至编码端。每一路子码流包含若干数据包,每个数据包的包头都会有唯一的编号-PacketNum,PacketNum是逐一递增的,数据包分析模块等待指定PacketNum的数据包到来,若发现收到的数据包的PacketNum发生跳跃,则认为当前等待的数据包已经丢失,MCU服务端按TCP协议发送反馈消息至编码端,该反馈消息中包含发生丢包的子码流的信息。
编码端发送控制模块根据反馈信息,确定发生丢包的子码流,然后执行丢包处理策略,即对发生丢包的子码流所属的图像组序列,编码端发送控制模块停止向MCU服务端发送该图像组序列的剩余数据。这些剩余数据属于无用数据,若根据这些无用的数据进行解码,很可能解码后获得的图像出现马赛克。同时,停止这些无用数据的发送,还能够节省网络带宽。
MCU发送控制模块将丢包检测后的子码流按UDP协议发送至解码端。在丢包检测后,若未发生丢包情况,则MCU发送控制模块将接收的完整子码流传输至解码端;若发生丢包情况,因为已经停止该子码流所述图像组序列的剩余数据的发送,则MCU发送控制模块将已接收的子码流中的数据发送至解码端。
然后在解码端中,分析重组模块接收到子码流后进行丢包检测与重组。此处分析重组模块进行丢包检测的过程与MCU服务端中数据包分析模块进行丢包检测的过程相同。数据包重组是指将属于同一帧的数据包视频数据组合在一起,每个数据包包头都有一个帧索引-FrameIndex,可以利用这个索引将同帧的所有数据包组合在一起。
解码端在发生子码流数据包丢失时返回请求至MCU服务端,要求终止剩余数据的发送。MCU发送控制模块根据请求,对发生丢包的子码流所属的图像组序列,停止向解码端发送该图像组序列的剩余数据。这样能够避免使用无用数据解码使解码图像出现马赛克的情况,并同时降低了MCU服务端和解码端的带宽占用。
解码模块对丢包检测与重组后的子码流进行解码获得视频图像。
无论是编码端发送控制模块还是MCU发送控制模块,都使用UDP协议进行视频数据传输,以保证视频传输的实时性。而在发生子码流丢包情况时MCU服务端和解码端都通过消息反馈的手段要求停止无用数据的发送,降低了带宽占用,尽可能保证视频传输的流畅性。
实施例4:
本实施例提出一种基于MCU的视频会议***,该基于MCU的视频会议***包括编码端、MCU服务端和解码端。
如图5所示,编码端包括用于对视频图像进行采样和编码的采样编码模块、用于对子码流进行发送与控制的编码端发送控制模块、以及对图像数据的编码进行编码控制的编码控制模块。其中,采样编码模块包含两个不同的编码器。
MCU服务端包括用于对接收的子码流进行丢包检测和丢包率统计的数据包分析模块,以及用于对子码流进行发送与控制的MCU发送控制模块。
解码端包括用于对接收的子码流进行丢包检测与重组的分析重组模块,用于对子码流进行解码的解码模块、用于对解码后的图像进行拼接处理的拼接模块、用于对拼接处理后的图像进行滤波处理的滤波模块、以及用于对解码后的图像进行图像还原处理的图像还原模块。本实施例将采样“双流”模式进行视频传输,即数据是以两路码流的方式,所以对应不同的接收状况,将采用不同的模块来对解码后的图像进行处理,以获得所需的视频图像。
具体工作过程如下:
编码端中,采样编码模块对视频图像进行隔行下采样,然后将采样的图像分成第一子图像和第二子图像,将这两幅子图像分别送入不同的H.264编码器进行编码。以GopSize表示关键帧周期,FrameNum表示帧序,编码控制模块将第一子图像和第二子图像关键帧的间隔帧数都设置为再根据帧序进行相应调整:编码控制模块在时发送第一控制指令至采样编码模块,采样编码模块只对第一子图像进行编码;编码控制模块在时发送第二控制指令至采样编码模块,采样编码模块对第一子图像和第二子图像都进行编码。其中,第一控制指令和第二控制指令仅仅是为了描述的方便,并不构成对本发明技术方案的限定。编码端发送控制模块将编码获得的第一子码流和第二子码流按UDP协议发送至MCU服务端。
在MCU服务端,数据包分析模块对MCU服务端接收到的子码流进行丢包检测和丢包率的统计,丢包检测的过程与实施例3中介绍的丢包检测过程相同,即检测收到的数据包的PacketNum是否发生跳跃,若发生跳跃则认为当前等待的数据包已经丢失。MCU服务端按TCP协议发送包含发生丢包的子码流信息和丢包率的反馈消息至编码端。
编码端发送控制模块根据反馈信息,确定发生丢包的子码流以及相应的丢包率,然后执行丢包处理策略。其中,丢包处理策略具体包括:
1)若第一子码流发生丢包情况,则编码端发送控制模块停止向MCU服务端发送第一子码流所属图像组序列的剩余数据。若第二子码流发生丢包情况,则采取同样的处理方式。
2)根据返回的不同丢包率,执行以下处理策略:
当丢包率为0%-10%时,编码端发送控制模块不做任何处理;
当丢包率为10%-20%时,编码端发送控制模块将对应同一帧的两个子码流的数据包发送间隔进行设置,该发送间隔最小为1帧,最大为5帧,即发送间隔在1帧以上并且在5帧以下;
当丢包率为20%-30%时,编码端发送控制模块在第一子码流和第二子码流中任意选择一路子码流发送至MCU服务端;此种情况下,丢包率较为严重,除了停止无用数据的发送,再次发送子码流时,仅仅传输一路子码流数据,保证视频的流畅性;
当丢包率大于30%时,编码端发送控制模块在第一子码流和第二子码流中任意选择一路子码流,并将该子码流的编码帧率降低为10fps以上,再将编码帧率降低后的子码流发送至MCU服务端。当丢包率在30%以上,属于丢包率非常严重的情况,此时仅传输一路子码流是不够的,还需要降低编码帧率,使降低编码帧率后的子码流能够适应恶劣的网络带宽,来保证视频的流畅性。
MCU发送控制模块将丢包检测后的子码流按UDP协议发送至解码端。在丢包检测后,若未发生丢包情况,则MCU发送控制模块将接收的完整子码流传输至解码端;若发生丢包情况,因为已经停止该子码流所述图像组序列的剩余数据的发送,则MCU发送控制模块将已接收的子码流中的数据发送至解码端。
在解码端中,分析重组模块接收到子码流后进行丢包检测与重组。分析重组模块进行丢包检测的过程与MCU服务端中数据包分析模块进行丢包检测的过程相同。数据包重组与实施例3中对重组过程的介绍相同,即根据帧索引FrameIndex将同帧的所有数据包组合在一起。
解码端在发生子码流数据包丢失时返回请求至MCU服务端,要求终止剩余数据的发送。MCU发送控制模块根据请求,对发生丢包的子码流所属的图像组序列,停止向解码端发送该图像组序列的剩余数据。这样能够避免使用无用数据解码使解码图像出现马赛克的情况,并同时降低了MCU服务端和解码端的带宽占用。
解码模块对丢包检测与重组后的子码流进行解码,这里包括两种情况:
A)解码端接收到两路子码流,即当前帧的第一子码流和第二子码流的完整数据都被接收到,则解码模块对两个子码流的数据进行解码,然后由拼接模块对解码后的图像进行拼接处理,再由滤波模块对拼接处理后的图像进行滤波处理,获得质量最好的图像。
B)解码端仅接收到一路子码流,此处以仅接收到第一子码流为例,如果当前帧的第一子码流的完整数据被接收到,则解码模块对第一子码流中的数据进行解码后,再由图像还原模块对解码获得的图像进行图像还原处理,例如,可以采用隔行插值的办法进行图像还原过程,获得可以接受的图像。
通过UDP协议进行传输,保证了视频传输的实时性,并且使用双流模式结合相应的反馈机制和策略调整,解码端在接收到两路码流的情况下能够获得最好的视频图像,而在仅接收到一路码流,采用图像还原处理还原出能够接受的视频图像,尽可能地保证视频的流畅性。
以上所述的本发明实施方式,并不构成对本发明保护范围的限定。任何在本发明的精神和原则之内所作的修改、等同替换和改进等,均应包含在本发明的权利要求保护范围之内。
Claims (10)
1.一种基于MCU的视频会议***中视频传输丢包处理的方法,该基于MCU的视频会议***包括编码端、MCU服务端和解码端,其特征在于,该视频传输丢包处理的方法具体包括:
步骤S1,所述编码端对视频图像进行采样与编码,将编码后获得的子码流按UDP协议发送至所述MCU服务端;
步骤S2,所述MCU服务端对接收到的子码流进行丢包检测,然后返回反馈信息至所述编码端;所述反馈信息包括丢包检测结果;
步骤S3,所述编码端根据所述反馈信息,执行丢包处理策略;其中,所述丢包处理策略包括:对发生丢包的子码流所属的图像组序列,所述编码端停止向所述MCU服务端发送该图像组序列的剩余数据;
步骤S4,所述MCU服务端将丢包检测后的子码流按UDP协议发送至所述解码端;
步骤S5,所述解码端接收到所述子码流后进行丢包检测和重组,出现子码流丢包时返回终止数据发送的请求至所述MCU服务端;所述MCU服务端根据所述请求,对发生丢包的子码流所属的图像组序列,停止向所述解码端发送该图像组序列的剩余数据;
步骤S6,所述解码端对丢包检测与重组后的子码流进行解码获得视频图像。
2.根据权利要求1基于MCU的视频会议***中视频传输丢包处理的方法,其特征在于,
所述步骤S1具体包括:
所述编码端对视频图像进行采样,将采样获得的图像分成第一子图像和第二子图像并分别送入不同的编码器进行编码,将编码后获得的第一子码流和第二子码流按UDP协议发送至所述MCU服务端;
所述步骤S6具体包括:
若在丢包检测与重组后所述解码端接收到所述第一子码流和所述第二子码流,则所述解码端对所述第一子码流和所述第二子码流中的数据进行解码,并将解码后的图像进行拼接处理,获得视频图像;
若在丢包检测与重组后所述解码端仅接收到所述第一子码流或所述第二子码流,则所述解码端对接收到的所述第一子码流或所述第二子码流进行解码,对解码后的图像进行图像还原处理,获得视频图像。
4.根据权利要求3基于MCU的视频会议***中视频传输丢包处理的方法,其特征在于,
步骤S2具体包括:
所述MCU服务端接收到所述子码流后进行丢包检测并进行丢包率的统计,然后返回反馈信息至所述编码端;其中,所述反馈信息包括丢包检测结果和丢包率;
步骤S3中执行丢包处理策略的过程还包括:
当所述丢包率为0%-10%时,所述编码端不做任何处理;
当所述丢包率为10%-20%时,所述编码端将对应同一帧的两个子码流的数据包发送间隔设置为:该发送间隔在1帧以上并且在5帧以下;
当所述丢包率为20%-30%时,所述编码端在所述第一子码流和所述第二子码流中任意选择一路子码流发送至所述MCU服务端;
当所述丢包率大于30%时,所述编码端在所述第一子码流和所述第二子码流中任意选择一路子码流,并将该子码流的编码帧率降低为10fps以上,再将编码帧率降低后的子码流发送至所述MCU服务端。
5.根据权利要求4基于MCU的视频会议***中视频传输丢包处理的方法,其特征在于,步骤S2中所述MCU服务端按照预定的时间间隔进行丢包率的统计。
6.根据权利要求1或5基于MCU的视频会议***中视频传输丢包处理的方法,其特征在于,所述编码端采用隔行下采样的方法对视频图像进行采样。
7.根据权利要求1基于MCU的视频会议***中视频传输丢包处理的方法,其特征在于,
步骤S2中所述MCU服务端返回反馈信息至所述编码端的过程为:所述MCU服务端按照TCP协议发送反馈信息至所述编码端;
步骤S5中所述解码端返回终止数据发送的请求至所述MCU服务端的过程包括:所述MCU服务端按照TCP协议发送终止数据发送的请求至所述编码端。
8.根据权利要求2基于MCU的视频会议***中视频传输丢包处理的方法,其特征在于,步骤S6中,若在丢包检测与重组后所述解码端接收到所述第一子码流和所述第二子码流,则所述解码端对拼接处理后的图像进行滤波处理,获得滤波处理后的视频图像。
9.根据权利要求2基于MCU的视频会议***中视频传输丢包处理的方法,其特征在于,步骤S6中,若在丢包检测与重组后所述解码端仅接收到所述第一子码流或所述第二子码流,则所述解码端采用隔行插值的方法对解码后的图像进行图像还原处理,获得图像还原处理后的视频图像。
10.一种基于MCU的视频会议***,该基于MCU的视频会议***包括编码端、MCU服务端和解码端,其特征在于,
所述编码端包括用于对视频图像进行采样和编码的采样编码模块、以及用于对子码流进行发送与控制的编码端发送控制模块;
所述MCU服务端包括用于对接收的子码流进行丢包检测和丢包率统计的数据包分析模块,以及用于对子码流进行发送与控制的MCU发送控制模块;
所述解码端包括用于对接收的子码流进行丢包检测与重组的分析重组模块,以及用于对子码流进行解码的解码模块;
所述采样编码模块对视频图像进行采样与编码,所述编码端发送控制模块将编码后获得的子码流按UDP协议发送至所述MCU服务端;
所述数据包分析模块对所述MCU服务端接收到的子码流进行丢包检测,然后所述MCU服务端根据丢包检测结果返回反馈信息至所述编码端;
所述编码端发送控制模块根据所述反馈信息,执行丢包处理策略;其中,所述丢包处理策略包括:对发生丢包的子码流所属的图像组序列,所述编码端发送控制模块停止向所述MCU服务端发送该图像组序列的剩余数据;所述MCU发送控制模块将丢包检测后的子码流按UDP协议发送至所述解码端;所述分析重组模块接收到所述子码流后进行丢包检测与重组,所述解码端在出现子码流数据包丢失时返回终止数据发送的请求至所述MCU服务端;所述MCU发送控制模块根据所述请求,对发生丢包的子码流所属的图像组序列,停止向所述解码端发送该图像组序列的剩余数据;所述解码模块对丢包检测与重组后的子码流进行解码获得视频图像。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 201010197483 CN101883240B (zh) | 2010-06-09 | 2010-06-09 | 基于mcu的视频会议***及其视频传输丢包处理的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 201010197483 CN101883240B (zh) | 2010-06-09 | 2010-06-09 | 基于mcu的视频会议***及其视频传输丢包处理的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101883240A true CN101883240A (zh) | 2010-11-10 |
CN101883240B CN101883240B (zh) | 2012-02-22 |
Family
ID=43055115
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 201010197483 Expired - Fee Related CN101883240B (zh) | 2010-06-09 | 2010-06-09 | 基于mcu的视频会议***及其视频传输丢包处理的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101883240B (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102752670A (zh) * | 2012-06-13 | 2012-10-24 | 广东威创视讯科技股份有限公司 | 减少网络视频传输中马赛克现象的方法、装置及*** |
CN102938833A (zh) * | 2012-07-25 | 2013-02-20 | 苏州科达科技有限公司 | 视频会议中的方法及装置、多点控制设备及视频会议*** |
WO2013113281A1 (zh) * | 2012-02-02 | 2013-08-08 | 腾讯科技(深圳)有限公司 | 传输多媒体数据的方法、装置及*** |
CN103533387A (zh) * | 2013-10-21 | 2014-01-22 | 腾讯科技(深圳)有限公司 | 一种视频直播控制方法、设备及*** |
CN106993197A (zh) * | 2017-04-10 | 2017-07-28 | 杭州星犀科技有限公司 | 一种基于编码器的丢帧方法 |
CN109842821A (zh) * | 2018-12-25 | 2019-06-04 | 视联动力信息技术股份有限公司 | 一种视频数据传输的方法和装置 |
CN112511782A (zh) * | 2019-09-16 | 2021-03-16 | 中兴通讯股份有限公司 | 视频会议方法、第一终端、mcu、***及存储介质 |
CN112565664A (zh) * | 2020-11-27 | 2021-03-26 | 北京融讯科创技术有限公司 | 视频会议码流反馈方法、装置、设备及计算机可读存储介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070058635A1 (en) * | 2005-08-05 | 2007-03-15 | Sony Corporation And Sony Electronics, Inc. | Systems and methods for transmitting data over lossy networks |
CN101296055A (zh) * | 2007-04-29 | 2008-10-29 | 华为技术有限公司 | 数据包收发方法及装置 |
CN101389036A (zh) * | 2008-10-14 | 2009-03-18 | 广东威创视讯科技股份有限公司 | 一种适用于视频会议的纠错装置及其方法 |
US20090222709A1 (en) * | 2008-02-28 | 2009-09-03 | Ip Video Communications Coporation | Universal packet loss recovery system for delivery of real-time streaming multimedia content over packet-switched networks |
CN106111551A (zh) * | 2016-06-28 | 2016-11-16 | 柏伟伟 | 重量不合格次品分拣装置 |
-
2010
- 2010-06-09 CN CN 201010197483 patent/CN101883240B/zh not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070058635A1 (en) * | 2005-08-05 | 2007-03-15 | Sony Corporation And Sony Electronics, Inc. | Systems and methods for transmitting data over lossy networks |
CN101296055A (zh) * | 2007-04-29 | 2008-10-29 | 华为技术有限公司 | 数据包收发方法及装置 |
US20090222709A1 (en) * | 2008-02-28 | 2009-09-03 | Ip Video Communications Coporation | Universal packet loss recovery system for delivery of real-time streaming multimedia content over packet-switched networks |
CN101389036A (zh) * | 2008-10-14 | 2009-03-18 | 广东威创视讯科技股份有限公司 | 一种适用于视频会议的纠错装置及其方法 |
CN106111551A (zh) * | 2016-06-28 | 2016-11-16 | 柏伟伟 | 重量不合格次品分拣装置 |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013113281A1 (zh) * | 2012-02-02 | 2013-08-08 | 腾讯科技(深圳)有限公司 | 传输多媒体数据的方法、装置及*** |
CN103248882A (zh) * | 2012-02-02 | 2013-08-14 | 腾讯科技(深圳)有限公司 | 多媒体数据传输的方法、多媒体数据传输装置及*** |
US9578179B2 (en) | 2012-02-02 | 2017-02-21 | Tencent Technology (Shenzhen) Company Limited | Method, apparatus and system for transmitting multimedia data |
CN102752670A (zh) * | 2012-06-13 | 2012-10-24 | 广东威创视讯科技股份有限公司 | 减少网络视频传输中马赛克现象的方法、装置及*** |
CN102752670B (zh) * | 2012-06-13 | 2015-11-25 | 广东威创视讯科技股份有限公司 | 减少网络视频传输中马赛克现象的方法、装置及*** |
CN102938833B (zh) * | 2012-07-25 | 2016-10-12 | 苏州科达科技股份有限公司 | 视频会议中的方法及装置、多点控制设备及视频会议*** |
CN102938833A (zh) * | 2012-07-25 | 2013-02-20 | 苏州科达科技有限公司 | 视频会议中的方法及装置、多点控制设备及视频会议*** |
CN103533387A (zh) * | 2013-10-21 | 2014-01-22 | 腾讯科技(深圳)有限公司 | 一种视频直播控制方法、设备及*** |
CN103533387B (zh) * | 2013-10-21 | 2016-08-17 | 腾讯科技(深圳)有限公司 | 一种视频直播控制方法、设备及*** |
WO2015058590A1 (zh) * | 2013-10-21 | 2015-04-30 | 腾讯科技(深圳)有限公司 | 一种视频直播控制方法、设备及***和存储介质 |
CN106993197A (zh) * | 2017-04-10 | 2017-07-28 | 杭州星犀科技有限公司 | 一种基于编码器的丢帧方法 |
CN106993197B (zh) * | 2017-04-10 | 2019-05-24 | 杭州星犀科技有限公司 | 一种基于编码器的丢帧方法 |
CN109842821A (zh) * | 2018-12-25 | 2019-06-04 | 视联动力信息技术股份有限公司 | 一种视频数据传输的方法和装置 |
CN112511782A (zh) * | 2019-09-16 | 2021-03-16 | 中兴通讯股份有限公司 | 视频会议方法、第一终端、mcu、***及存储介质 |
WO2021052077A1 (zh) * | 2019-09-16 | 2021-03-25 | 中兴通讯股份有限公司 | 视频会议方法、第一终端、mcu、***及存储介质 |
CN112511782B (zh) * | 2019-09-16 | 2024-05-07 | 中兴通讯股份有限公司 | 视频会议方法、第一终端、mcu、***及存储介质 |
CN112565664A (zh) * | 2020-11-27 | 2021-03-26 | 北京融讯科创技术有限公司 | 视频会议码流反馈方法、装置、设备及计算机可读存储介质 |
CN112565664B (zh) * | 2020-11-27 | 2023-04-28 | 北京融讯科创技术有限公司 | 视频会议码流反馈方法、装置、设备及计算机可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN101883240B (zh) | 2012-02-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101883240B (zh) | 基于mcu的视频会议***及其视频传输丢包处理的方法 | |
CN105704580B (zh) | 一种视频传输方法 | |
CN102036071B (zh) | 用于视频通信***中的差错弹性和随机接入的***和方法 | |
US8699522B2 (en) | System and method for low delay, interactive communication using multiple TCP connections and scalable coding | |
CN107231328B (zh) | 实时视频传输方法、装置、设备及*** | |
EP2529528B1 (en) | A method and apparatus for parsing a network abstraction-layer for reliable data communication | |
US6606112B1 (en) | Composite-video generation from different-rate constituents | |
US9641588B2 (en) | Packets recovery system and method | |
JP4479650B2 (ja) | コミュニケーションシステム、端末装置及びコンピュータプログラム | |
CN103248882A (zh) | 多媒体数据传输的方法、多媒体数据传输装置及*** | |
WO2002056601A1 (en) | A method for processing error code of compressed image in transmission | |
CN101389036B (zh) | 一种适用于视频会议的纠错装置及其方法 | |
CN110602522B (zh) | 一种多路实时直播WebRTC流合成方法 | |
Wenger et al. | Using RFC2429 and H. 263+ at low to medium bit-rates for low-latency applications | |
WO2012003808A1 (zh) | 视频刷新方法、装置及*** | |
CN112995214B (zh) | 一种实时视频传输***、方法及计算机可读存储介质 | |
EP2908516A1 (en) | Process for transmitting an ongoing video stream from a publisher to a receiver through a MCU unit during a live session | |
WO2008073881A2 (en) | System and method for low-delay, interactive communication using multiple tcp connections and scalable coding | |
CN113542685B (zh) | 一种基于可靠udp的实时超高清视频传输方法 | |
AU2012216587B2 (en) | Systems and methods for error resilience and random access in video communication systems | |
Micanti et al. | A packetization technique for D-Cinema contents multicasting over metropolitan wireless networks | |
Martinez et al. | Cross layer rohc compression for multicast video streaming | |
Chung et al. | Nondisruptive RTSP video over the Internet using a modem connection | |
Zhao et al. | Video communication system based on hybrid packetization scheme | |
Zhang et al. | Cross-layer feedback-based resilient coding for video transmission over uplink cellular network |
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 | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20120222 Termination date: 20190609 |