CN102316360A - 视频刷新方法、装置及*** - Google Patents
视频刷新方法、装置及*** Download PDFInfo
- Publication number
- CN102316360A CN102316360A CN2010102223595A CN201010222359A CN102316360A CN 102316360 A CN102316360 A CN 102316360A CN 2010102223595 A CN2010102223595 A CN 2010102223595A CN 201010222359 A CN201010222359 A CN 201010222359A CN 102316360 A CN102316360 A CN 102316360A
- Authority
- CN
- China
- Prior art keywords
- video
- message
- critical data
- packet loss
- control protocol
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
- H04N19/187—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a scalable video layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
- H04N19/103—Selection of coding mode or of prediction mode
- H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/164—Feedback from the receiver or from the transmission channel
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
本发明实施例公开了一种视频刷新方法、装置及***，涉及视频通信技术领域，解决了I帧刷新需要传输的数据较大、对带宽带来较大的负荷的问题。本发明实施例视频刷新方法包括：接收视频码流接收设备发送的关键数据申请消息，所述关键数据申请消息中包含所申请的数据包对应的分层信息；对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码；将编码所得到的关键数据发送给所述视频码流接收设备。本发明实施例主要用于视频通信技术领域，例如视频会议***、视频通话技术等等。
Description
技术领域
本发明涉及视频通信技术领域，尤其涉及视频刷新方法、装置及***。
背景技术
在标准视频编码框架中，当前帧参考其他视频帧进行预测编码的方法称作帧间预测编码，使用了帧间预测编码的编码帧称作P帧；没有参考任何其他视频帧的编码方法称作帧内预测编码，一帧图像内的全部区域只使用了帧内预测编码的编码帧称作I帧。
帧间预测编码可以有效降低视频图像之间的时间冗余，提高编码压缩效率。但是，帧间预测编码同时也会引入错误扩散的问题，例如：当某一帧发生丢包后，该丢失的数据包对应的编码帧无法经过正确解码获得重建图像，导致出现了错误帧；而后续的P帧图像由于参考到该错误帧，同样无法实现正常解码；这样一来，丢包引发的错误，一直从丢包帧开始扩散到后续的所有P帧，直至遇到I帧为止。从某种意义上讲，I帧属于关键帧的一种。
在现有技术中，本地发送设备在发送视频码流给远端接收设备过程中，当视频码流发生丢包或者错误的情况下，一般首先是由远端接收设备通过解码或者检查包序号的方式来发现，然后由远端接收设备通过指定命令通道，将关于“视频刷新”或者“图像丢包”的消息发送给本地发送设备。本地发送设备接收到该消息后，便执行I帧刷新，操作编码器对视频码流中发生丢包或者错误视频帧进行IDR(Instantaneous decoding refresh，解码立即刷新)帧的编码输出。IDR帧称作立即刷新帧，为I帧的一种。当远端接收设备的解码器接收到IDR帧后，会将发生丢包或错误所对应的参数集以及参考帧列表中的所有参考帧设置为无效，并利用IDR帧纠正丢包引发的错误。
在实现上述I帧刷新的过程中，发明人发现现有技术中至少存在如下问题：如果采用分层编码对视频进行编码，将视频编码成一个基本层和若干个增强层，这种情况下，由于远端发送设备发送的“视频刷新”或者“图像丢包”消息并不能携带任何关于丢包码流的分层信息。因此，在分层编码的情况下，本地发送设备仍然无法获知是哪一层码流发生丢包，只能同时对所有分层(包括基本层和所有增强层)进行I帧刷新，这种I帧刷新方式造成需要传输的数据较大，对带宽带来较大的负荷。
发明内容
本发明的实施例提供一种视频刷新方法、装置及***，减少视频关键数据刷新时需要传输的数据，减少对带宽带来的负荷。
为达到上述目的，本发明的实施例采用如下技术方案：
一种视频刷新方法，包括：
接收视频码流接收设备发送的关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；
对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码；
将所述编码得到的关键数据发送给所述视频码流接收设备。
一种视频刷新装置，其特征在于，包括：
接收单元，用于接收视频码流接收设备发送的关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；
编码单元，用于对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码；
发送单元，用于将所述编码得到的关键数据发送给所述视频码流接收设备。
一种视频刷新方法，其特征在于，包括：
生成关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；
向视频码流发送设备发送所述关键数据申请消息，以指示视频码流发送设备重新发送关键数据。
一种视频刷新装置，其特征在于，包括：
生成单元，用于生成关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；
发送单元，用于向视频码流发送设备发送所述关键数据申请消息，以指示视频码流发送设备重新发送关键数据。
一种视频刷新***，其特征在于，包括：
视频码流接收设备，用于接收视频码流发送设备发送的视频码流，生成关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；并向视频码流发送设备发送所述关键数据申请消息；
视频码流发送设备，用于接收所述关键数据申请消息，对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码；并将所述编码得到关键数据发送给所述视频码流接收设备。
本发明实施例提供的视频刷新方法、装置及***，由于在关键数据申请消息中包含了分层信息，这样一来，在进行I帧刷新的时候可以只对所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码，而现有技术中需要对所有的分层进行关键数据编码；所以，采用本发明实施例提供的视频刷新方法、装置及***，可以使得需要进行关键数据编码的分层层数比现有技术要少，可以使得进行I帧刷新时输出的IDR帧数据量较少，进而减少视频关键数据刷新时需要传输的数据，减少对带宽带来的负荷。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例中视频刷新方法流程图；
图2为本发明实施例中视频刷新装置框图；
图3为本发明实施例中另一视频刷新方法流程图；
图4为本发明实施例中另一视频刷新装置框图；
图5为本发明实施例中视频刷新***原理图；
图6为本发明实施例中具体运用的视频刷新***拓扑图；
图7为本发明实施例1中采用方法一扩展后的命令解码示意图；
图8为本发明实施例1中采用方法二扩展后的命令解码示意图；
图9为本发明实施例1中视频刷新方法流程图；
图10为本发明实施例2中采用方法一扩展后的命令解码示意图；
图11为本发明实施例2中采用方法二扩展后的命令解码示意图。
具体实施方式
分层编码是指将视频编码成一个基本层和若干个增强层。基本层能够独立解码，用于提供一个基本的但是可以接受的视频质量；增强层的解码一般依赖于基本层，增强层能够提供比基本层更好的视频质量。分层编码主要包括以下三类分级方式：
(1)帧率分级：基本层使用原始图像，以较低的输出帧率进行编码，获得较低的流畅度。而增强层则对基本层未进行编码的图像帧进行编码，在基本层解码图像的基础上提高其显示帧率。
(2)分辨率分级：基本层使用由原始图像进行亚采样所得较低分辨率的图像进行编码，获得较低的分辨率。而增强层则由原始分辨率图像进行预测编码，在基本层解码图像的基础上提高其分辨率。增强层的编码可以参考基本层重建图像的插值图像、也可以参考基本层宏块的运动矢量、重建残差系数。
(3)质量分级：基本层使用原始图像，以较高的压缩率(即较大的量化步长、较低的编码带宽)进行编码，获得较低的清晰度；而增强层则参考基本层的重建图像，以较高的图像质量(即较小的量化步长、较高的编码带宽)进行编码，在基本层解码图像的基础上提高其清晰度。
对于采用分层编码的视频通信方案，为了减少视频关键数据刷新时需要传输的数据，减少对带宽带来的负荷，本发明实施例提供一种视频刷新方法，如图1所示，所述方法包括：
101、视频码流接收设备发出一个关键数据申请消息，在所述关键数据申请消息中包含所申请的数据包对应的分层信息。
102、本发明实施例中的视频码流发送设备在接收到所述关键数据申请消息后，对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码，而对其他不需要依据所述分层信息表示的分层进行解码的分层则不进行关键数据编码。
103、将编码所得到的关键数据发送给所述视频码流接收设备，以便视频码流接收设备根据该关键数据进行相应处理。
本发明实施例还提供一种视频刷新装置，如图2所示，所述装置包括：接收单元21、编码单元22、发送单元23。
其中，接收单元21用于接收视频码流接收设备发送的关键数据申请消息，所述关键数据申请消息中包含所申请的数据包对应的分层信息；编码单元22用于根据所述分层信息，对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码，而对其他不需要依据所述分层信息表示的分层进行解码的分层则不进行关键数据编码；发送单元23用于将编码所得到的关键数据发送给所述视频码流接收设备，以便视频码流接收设备根据该关键数据进行相应处理。
为了能够准确对相应的分层进行编码，本发明实施例中所述编码单元22还用于从所接收到的关键数据申请消息中获取所述分层信息表示的分层。
本发明实施例中的分层信息根据具体的分层编码方式不同可有所不同，如：视频图像可以按照帧率分级、分辨率分级、或者质量分级进行分层，其对应的分层信息可以分别为：不同帧率的分层、不同分辨率的分层、不同质量的分层。
所述接收单元21接收到的关键数据申请消息为：多媒体控制协议中的视频快速刷新命令、或宏块组快速刷新命令、或宏块快速刷新命令、或宏块丢包消息、或图象丢包消息、或图象详细丢包消息；或者视频通信反馈信息协议中的图像丢包消息、或宏块组丢包消息；或者实时传输控制协议中的图像丢包消息、或条带丢包消息。
为了承载上述关键数据申请消息，本发明实施例可以采用多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议进行承载，具体包括如下三种实现方式：
第一、通过对多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中原有消息的参数进行扩展后承载所述关键数据申请消息。
第二、通过对多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中的保留消息进行扩展后承载所述关键数据申请消息。
第三、通过新增多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中的消息承载所述关键数据申请消息。
本发明实施例还提供一种视频刷新方法，如图5所示，包括：
301、在需要请求视频码流发送设备重新发送关键数据时，生成关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息，这里的分层信息主要是指需要重新发送的数据对应的分层。
一般情况下，在检测到丢包、或误码、或乱序时，表示关键数据出现了不正确的现象，此时需要向视频码流发送设备发送所述关键数据申请消息；或者周期性地向视频码流发送设备发送所述关键数据申请消息。
302、向视频码流发送设备发送关键数据申请消息，以指示视频码流发送设备重新发送关键数据。
本发明实施例中所述关键数据申请消息的实现方式包括但不限于如下方式：多媒体控制协议中的视频快速刷新命令、或宏块组快速刷新命令、或宏块快速刷新命令、或宏块丢包消息、或图象丢包消息、或图象详细丢包消息；或者视频通信反馈信息协议中的图像丢包消息、或宏块组丢包消息；或者实时传输控制协议中的图像丢包消息、或条带丢包消息。
本发明实施例还提供一种视频刷新装置，如图4所示，所述视频刷新装置包括生成单元41和发送单元42。
在需要请求视频码流发送设备重新发送关键数据时，生成单元41用于生成关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；这里的分层信息主要是指需要重新发送的数据对应的分层。发送单元42用于向视频码流发送设备发送所述关键数据申请消息，以指示视频码流发送设备重新发送关键数据。
本发明实施例中所述发送单元42发送的关键数据申请消息可以采用但不限于如下方式：多媒体控制协议中的视频快速刷新命令、或宏块组快速刷新命令、或宏块快速刷新命令、或宏块丢包消息、或图象丢包消息、或图象详细丢包消息；或者视频通信反馈信息协议中的图像丢包消息、或宏块组丢包消息；或者实时传输控制协议中的图像丢包消息、或条带丢包消息。
在不同的通信***中，由于采用的通信协议不一样，关键数据申请消息可以采用不同的协议进行承载，如：多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议等。具体而言，包括但不限于如下承载方式：
第一、通过对多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中原有消息的参数进行扩展后承载所述关键数据申请消息。
第二、通过对多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中的保留消息进行扩展后承载所述关键数据申请消息。
第三、通过新增多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中的消息承载所述关键数据申请消息。
本发明实施例还提供一种视频刷新***，如图5所示，所述***包括：视频码流发送设备51、视频码流接收设备52。
其中，视频码流发送设备51将需要传输的视频码流发送给视频码流接收设备52；所述视频码流接收设备52用于接收视频码流发送设备51发送的视频码流，并在一定条件下生成关键数据申请消息并向视频码流发送设备51发送关键数据申请消息，所述关键数据申请消息中包含所申请的数据包对应的分层信息。本发明实施例中发送关键数据申请消息的一定条件可以包括但不限于如下条件：检测到丢包、或误码、或乱序；或者本发明实施例中可以周期性地生成并向视频码流发送设备发送所述关键数据申请消息。
所述视频码流发送设备51用于接收所述关键数据申请消息，对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码；并将编码所得到的关键数据发送给所述视频码流接收设备52，以便视频码流接收设备52根据该关键数据进行相应处理。
具体而言，上述视频码流接收设备52可以通过解码或者检查包序号发现视频码流中存在丢包。
本发明实施例提供的视频刷新方法、装置及***，由于在关键数据申请消息中包含了所申请的数据包对应的分层信息，这样一来，在进行I帧刷新的时候可以只对所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码，而现有技术中需要对所有的分层进行关键数据编码；所以，采用本发明实施例提供的视频关键数据的刷新方法、装置及***，可以使得需要进行关键数据编码的分层层数比现有技术要少，可以使得进行I帧刷新时输出的IDR帧的数据量较少，进而减少视频关键数据刷新时需要传输的数据，减少对带宽带来的负荷。
本发明实施例的应用场景具体可以如图6所示，假设本地终端T0(视频码流发送设备)与远端终端T1、T2、T3(视频码流接收设备)进行视频会议；并且本地终端T0对本地图像采用分层编码的方案，具体包括一路基本层Layer1和两路增强层Layer2、Layer3；各层的参考关系为Layer2参考Layer1，Layer3参考Layer2。
本地终端T0经过MCU(Multipoint control unit，多点控制单元)向T1、T2、T3转发各自所需的分层码流，如图6所示。假设远端终端T3发现Layer2出现丢包，采用本发明的提供的方法进行的处理为：远端终端T3向本地终端T0发送关键数据申请消息，并且在关键数据申请消息中把Layer2的分层信息反馈给本地终端T0；T0依据Layer1、Layer2、Layer3之间的解码依赖关系，针对Layer2、Layer3进行关键数据编码，并且将编码得到的关键数据发送给远端终端T3，以便进行I帧刷新，对于Layer1不执行任何操作。
当然，特殊情况下，如果丢包发生在分层编码转码到非分层编码的码流中如SVC(Scalable video coding，分级视频编码)转码到AVC(Advanced videocoding，高级视频编码)的码流，由于解码器无法获取分层信息，此时本地终端需要对所有层都进行I帧刷新。
通过本发明提供的方法，在个别分层发生丢包的情况下，解码端能够将哪些图层发生丢包的信息反馈给编码端；编码端可以只对丢包分层和解码依赖到丢包分层的其他分层进行I帧刷新，避免因对所有分层进行I帧刷新而造成需要发送的数据量过大，可减少对带宽带来的负荷；并且在带宽有限的情况下有效避免编码图像质量严重下降的问题；本发明实施例提供的方法对于那些本来没有丢包的分层码流不会产生任何影响。
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
实施例1：
本发明实施例的应用场景为：视频码流发送设备和视频码流接收设备之间通过H.245协议的消息进行通信，其中的H.245为多媒体控制协议(Controlprotocol for multimedia communication)。在ITU-T(国际电联)公布的建议中，H.323协议族是下一代多媒体会议技术和设备的最重要标准，它规定了不同厂商的设备终端在LAN(局域网)、Internet(互联网)等上的音频、视频以及T.120数据的各种结合形式相互通信所要求的工作模式。其中包括H.225、H.245等。其中H.245是H.323多媒体通信体系中的控制命令协议。
MultimediaSystemControlMessage为H.245协议中定义的最上层***控制消息，在现有技术中该消息具体见下表：
通过上表可以看出，RequestMessage(请求消息)、ResponseMessage(响应消息)、CommandMessage(命令消息)、以及IndicationMessage(指示消息)都是MultimediaSystemControlMessage的可选项之一。
其中，上述CommandMessage的可选项之一包括MiscellaneousCommand(混合命令)，通过MiscellaneousCommand能够实现如下命令：videoFastUpdatePicture(视频快速刷新命令)、videoFastUpdateGOB(宏块组快速刷新命令)、videoFastUpdateMB(宏块快速刷新命令)、videoBadMBs(宏块丢包消息)、lostPicture(图象丢包消息)、lostPartialPicture(图象详细丢包消息)，上述各命令可作为在丢包的环境下，执行I帧申请的消息。但是以上命令，要么不能携带参数，要么只能携带丢包的帧序号、图像区域的相关参数，均没有携带丢包码流的分层信息。因此，H.245的标准命令消息无法反馈丢包码流的分层信息。
对于视频码流发送设备和视频码流接收设备之间通过H.245协议的命令消息进行通信情况，为了使得视频码流接收设备返回的命令消息能够携带分层信息，本发明实施例首先需要扩展H.245，以便指示分层信息。
本发明实施例的对H.245的扩展包括但不限于如下方法：
方法一：在H.245原有可用于I帧申请的命令消息的基础上，进行参数的扩展。具体而言为在原有MiscellaneousCommand消息的基础上添加如下参数：dependency_id(图层的分辨率分级级数)、quality_id(图层的质量分级级数)、temporal_id(图层的帧率分级级数)。本发明实施例以MiscellaneousCommand消息中的其中六种消息为例进行说明，他们分别是：videoFastUpdatePicture(视频快速刷新命令)、videoFastUpdateGOB(宏块组快速刷新命令)、videoFastUpdateMB(宏块快速刷新命令)、videoBadMBs(宏块丢包消息)、lostPicture(图象丢包消息)、lostPartialPicture(图象详细丢包消息)，扩展之后MiscellaneousCommand具体如下表：
上表中下划线标出的参数为扩展后新增的参数，其对应的解析过程如图7所示，首先需要对MiscellaneousCommand消息进行消息类型的判断，在得出类型之后可以分别对上表中MiscellaneousCommand消息的各种不同的消息进行解析，从图7中可以看出在最后解析结果中都包含分辨率分级级数、或者质量分级级数、或者帧率分级级数。
方法二：使用H.245的非标消息(相当于保留消息)，进行消息类型的扩展，添加“视频快速刷新命令”或“图象丢包消息”，所添加的“视频快速刷新命令”或“图象丢包消息”中携带他有相关图层分层信息参数。具体的分层信息参数可以包括dependency_id(图层的分辨率分级级数)、或quality_id(图层的质量分级级数)、或temporal_id(图层的帧率分级级数)。
在H.245的最上层***控制消息MultimediaSystemControlMessage中，RequestMessage(请求消息)、ResponseMessage(响应消息)、CommandMessage(命令消息)、IndicationMessage(指示消息)的可选项中均包括NonStandardMessage(非标消息)。因此，可以使用NonStandardMessage分别扩展相应的消息类型，现有H.245协议中NonStandardMessage定义如下表：
NonStandardParameter定义如下表：
其中上述NonStandardParameter和NonStandardMessage中所包含的NonStandardIdentifier用于标识扩展的消息；而OCTET STRING用于填充具体的消息内容。
本实施例使用CommandMessage_SVC标识扩展的用于分层编码的控制消息，即command.nonStandar.nonStandardData.nonStandardIdentifier等于CommandMessage_SVC，command.nonStandar.nonStandardData.data用于填充CommandMessage_SVC的消息内容。具体定义如下：
上表中videoFastUpdatePicture_SVC为“针对分层码流的视频快速更新指令”，lostPicture_SVC为“针对分层码流的图像丢包消息”，均包含了相关图层的分层信息。其对应的解析过程如图8所示，首先需要对分层编码的命令消息进行消息类型的判断，在得出类型之后可以分别对上表中分层编码的命令消息的各种不同的消息进行解析，从图8中可以看出上表中的两种消息在最后解析结果中都包含分辨率分级级数、或者质量分级级数、或者帧率分级级数。
除了上述两种方法以外，还可以在H.245协议中新增消息，并在新增的消息中设置分辨率分级级数、或者质量分级级数、或者帧率分级级数，以便携带分层信息。
在对H.245协议进行扩展之后，本发明实施例提供的视频刷新方法，如图9所示，所述方法包括：
901、视频码流接收设备生成关键数据申请消息，所述关键数据申请消息中包含所申请的数据包对应的分层信息。本实施例中的关键数据申请消息为上述H.245协议扩展后的消息，以便携带分层信息，具体而言可以选择在原有消息基础上进行扩展，也可以对H.245的非标消息扩展，也可以新增H.245协议消息，以使得扩展后的消息包括分辨率分级级数、或者质量分级级数、或者帧率分级级数。
902、视频码流接收设备向视频码流发送设备发送所述关键数据申请消息。
本发明实施例并不对发出关键数据申请消息的条件进行限制，具体实施时，视频码流接收设备可以周期性地向视频码流发送设备发出所述关键数据申请消息，如每隔5分钟、或者10分钟发出一个关键数据申请消息；也可在检测到关键数据异常的时候发出所述关键数据申请消息，如：检测到丢包、或误码、或乱序时，向视频码流发送设备发送所述关键数据申请消息。
903、视频码流发送设备则接收到所述关键数据申请消息后，依据所述关键数据申请消息中的分层信息确认需要进行关键数据编码的分层。
904、视频码流发送设备对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码，而对其他不需要依据所述分层信息表示的分层进行解码的分层则不进行关键数据编码。
905、视频码流发送设备将编码所得到的关键数据发送给所述视频码流接收设备，进行I帧刷新，以便视频码流接收设备根据该关键数据进行相应处理。本实施例的相应处理包括关键数据的错误纠正、关键数据的定时更新等等。
实施例2：
本发明实施例的应用场景为：视频码流发送设备和视频码流接收设备之间通过H.271协议的消息进行通信，其中的H.271协议为视频通信反馈信息协议(H.Video back-channel messages for conveyance of status informationand requests from a video receiver to a video sender)，专门用于视频接收设备经过反馈信息通道，向视频发送设备传送状态信息和指令要求，能够兼用于H.261、H.263、H.264视频协议。
H.271能够实现的消息类型和对应的负载类型，如下表所示。
| payloadType | 消息/指令 |
| 0 | 一帧或多帧没有检测到的码流错误的图像 |
| 1 | 一帧或多帧完全或部分丢失的图像 |
| 2 | 完全或部分丢失的一组宏块(属于同一帧图像) |
| 3 | 一个参数集的CRC校验码 |
| 4 | 同一类型的所有参数集的CRC校验码 |
| 5 | 重置码流发送设备的码流缓存 |
| ＞5 | 保留由ITU-T将来使用 |
在现有的H.271语法结构具体的丢包消息包括如下两种：
(1)图像丢包消息(payload＝1)，可以通过参数ref_pic_id、delta_ref_pic_id获得发生丢包的起始图像帧号、总帧数。
(2)宏块组丢包消息(payload＝2)，可以通过参数ref_pic_id、first_blk_lost、num_blks_lost_minus1、top_left_blk、bottom_right_blk获得发生丢包的图像帧号、图像区域。
以上两种消息均可作为在丢包的环境下执行I帧申请的消息。但是以上这些反馈消息，均没有携带参数指示丢包码流的分层信息，因此，H.271的标准消息类型同样无法反馈丢包码流的分层信息。
对于视频码流发送设备和视频码流接收设备之间通过H.271协议的消息进行通信情况，为了使得视频码流接收设备返回的消息能够携带分层信息，本发明实施例首先需要扩展H.271，以便指示分层信息。
本发明实施例的对H.271的扩展包括但不限于如下方法：
方法一：在H.271原有可用于I帧申请的反馈消息的基础上，进行参数的扩展。也就是为图像丢包消息(payload＝1)和宏块组丢包消息(payload＝2)进行参数扩展，在消息末尾添加上参数dependency_id(图层的分辨率分级级数)、quality_id(图层的质量分级级数)、temporal_id(图层的帧率分级级数)。
经过参数扩展后的H.271的消息语法结构，如下表所示：
| msg_payload(payloadType，payloadSize){ | 描述符 |
| if(payloadType＜＝4) | |
| ref_pic_id | u(32) |
| if(payloadType＝＝0){ | |
| num_ref_pics_minus1 | ue(v) |
| for(i＝1；i＜＝num_ref_pics_minus1；i++) | |
| good_ref_pi c_id[i] | u(32) |
| }elseif(payloadType＝＝1) | |
| delta_ref_pic_id | ue(v) |
| else if(payloadType＝＝2){ | |
| data_partition_idc | ue(v) |
| run_length_flag | u(1) |
| if(run_length_flag){ | |
| first_blk_lost | ue(v) |
| num_blks_lost_minus1 | ue(v) |
| }else{ | |
| top_left_blk | ue(v) |
| bottom_right_blk | ue(v) |
| } | |
| }else if((payloadType＝＝3)||(payloadType＝＝4)){ | |
| param_set_type | ue(v) |
| param_set_crc | u(16) |
| if(payloadType＝＝3) | |
| param_set_id | ue(v) |
| } | |
| /*新添加的语法参数，用于指示丢包码流的分层信息*/ | |
| if((payloadType＝＝1)||(payloadType＝＝2)){ | |
| lost_layer_info_idc/*是否在码流中写入丢包的分层信息*/ | u(1) |
| if(lost_layer_info_idc){ | |
| lost_layers_minus1/*发生丢包的图层数减1*/ | ue(v) |
| for(i＝1；i＜＝lost_layers_minus1；i++){ | |
| dependency_id[i]/*丢包图层的分辨率分级级数*/ | ue(v) |
| quality_id[i]/*丢包图层的质量分级级数*/ | ue(v) |
| temporal_id[i]/*丢包图层的帧率分级级数*/ | ue(v) |
| } | |
| } | |
| } | |
| stop_one_bit/*equal to 1*/ | f(1) |
| while(！byte_aligned()) | |
| alignment_zero_bit/*equal to 0*/ | f(1) |
| } |
扩展后新增的参数包括dependency_id、或者quality_id、或者temporal_id，其对应的解析过程如图10所示，首先需要进行消息类型的判断，在得到消息类型后可以对该消息进行解析，具体各种不同的消息在最后解析结果参见图10，在解析结果中中都包含分辨率分级级数、或者质量分级级数、或者帧率分级级数。
方法二：使用H.271的保留消息，进行反馈消息类型的扩展，添加“图象丢包消息”并在该“图象丢包消息”携带相关图层分层信息参数。具体的分层信息参数包括dependency_id(图层的分辨率分级级数)、或者quality_id(图层的质量分级级数)、或者temporal_id(图层的帧率分级级数)。
H.271中对于(payloadType＞5)的消息类型都是保留且未作使用的，下面以使用payloadType＝6为例，说明如何通过保留消息类型，扩展携带相关图层分层信息参数的“图象丢包消息”。经过消息类型扩展后的H.271的消息语法结构，如下表所示。
| msg_payload(payloadType，payloadSize){ | 描述符 |
| if((payloadType＜＝4)||(payloadType＝＝6)) | |
| ref_pic_id | u(32) |
| if(payloadType＝＝0){ | |
| num_ref_pics_minus1 | ue(v) |
| for(i＝1；i＜＝num_ref_pics_minus1；i++) | |
| good_ref_pic_id[i] | u(32) |
| }else if(payloadType＝＝1) | |
| delta_ref_pic_id | ue(v) |
| else if(payloadType＝＝2){ | |
| data_partition_idc | ue(v) |
| run_length_flag | u(1) |
| if(run_length_flag){ | |
| first_blk_lost | ue(v) |
| num_blks_lost_minus1 | ue(v) |
| }else{ | |
| top_left_blk | ue(v) |
| bottom_right_blk | ue(v) |
| } | |
| }else if((payloadType＝＝3)||(payloadType＝＝4)){ | |
| param_set_type | ue(v) |
| param_set_crc | u(16) |
| if(payloadType＝＝3) | |
| param_set_id | ue(v) |
| } | |
| /*新添加的语法参数，用于指示丢包码流的分层信息*/ | |
| if(payloadType＝＝6){ | |
| lost_layers_minus1/*发生丢包的图层数减1*/ | ue(v) |
| for(i＝1；i＜＝lost_layers_minus1；i++){ | |
| dependency_id[i]/*丢包图层的分辨率分级级数*/ | ue(v) |
| quality_id[i]/*丢包图层的质量分级级数*/ | ue(v) |
| temporal_id[i]/*丢包图层的帧率分级级数*/ | ue(v) |
| } | |
| } | |
| stop_one_bit/*equal to 1*/ | f(1) |
| while(！byt e_aligned()) | |
| alignment_zero_bit/*equal to 0*/ | f(1) |
| } |
对于payloadType＝6的保留消息扩展后新增的参数包括dependency_id、或者quality_id、或者temporal_id，其对应的解析过程如图11所示，首先需要判断消息类型，在得出消息类型后对消息进行解析，从图11中可以看出各种不同类型的消息在最后解析结果中都包含分辨率分级级数、或者质量分级级数、或者帧率分级级数。
除了上述两种方法以外，还可以在H.271协议中新增消息，并在新增的消息中设置分辨率分级级数、或者质量分级级数、或者帧率分级级数，以便携带分层信息。
在对H.271协议进行扩展之后，本发明实施例提供的视频刷新方法与图9的过程相似，不同之处在于本发明实施例中的关键数据申请消息为上述H.271协议扩展后的消息，以便携带分层信息，具体而言可以选择在原有消息基础上进行扩展，也可以对H.271的保留消息扩展，也可以新增H.271协议消息，以使得扩展后的消息包括分辨率分级级数、或者质量分级级数、或者帧率分级级数。
实施例3：
本发明实施例的应用场景为：视频码流发送设备和视频码流接收设备之间通过实时传输控制协议(RTCP，Realtime transport control protocol)的消息进行通信，其中实时传输控制协议负责管理传输质量，在当前应用进程之间交换控制信息。在RTP(Realtime transport protocol，实时传输协议)会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计信息。
按照RFC4585定义，RTCP提供以下几种负载层和应用层的反馈信息类型。
| FMT | 消息 |
| 0 | 保留 |
| 1 | 图像丢包消息 |
| 2 | Slice丢包消息 |
| 3 | 图像正确解码消息(指示可用的参考帧) |
| 4-14 | 保留 |
| 15 | 应用层反馈消息 |
| 16-30 | 保留 |
| 31 | 保留用作序列号的扩展 |
其中，图像丢包消息(FMT＝1)是没有携带参数的，即FCI(反馈消息内容)为空；Slice(条带)丢包消息(FMT＝2)携带了相关参数指示丢包的帧序号和图像区域(发生丢包的起始宏块号和宏块数)，FCI的结构如下。
图像丢包消息(FMT＝1)和Slice丢包消息(FMT＝2)均可作为在丢包的环境下执行I帧申请的消息。但是以上这些反馈消息，均没有携带参数指示丢包码流的分层信息，因此，RTCP的标准消息类型同样无法反馈丢包码流的分层信息。
对于视频码流发送设备和视频码流接收设备之间通过RTCP协议的消息进行通信情况，为了使得视频码流接收设备返回的消息能够携带分层信息，本发明实施例首先需要扩展RTCP，以便指示分层信息。
本发明实施例的对RTCP的扩展包括但不限于如下方法：
方法一：在RTCP原有可用于I帧申请的反馈消息类型的基础上，进行参数的扩展。也就是为图像丢包消息(FMT＝1)和Slice丢包消息(FMT＝2)进行参数扩展，在原有FCI的末尾添加上参数dependency_id(图层的分辨率分级级数)、或者quality_id(图层的质量分级级数)、或者temporal_id(图层的帧率分级级数)。
经过参数扩展后的图像丢包消息(FMT＝1)的FCI结构如下所示。
经过参数扩展后的Slice丢包消息(FMT＝2)的FCI结构如下所示。
方法二：使用RTCP保留消息，进行消息的扩展，添加“图象丢包消息”，该“图象丢包消息”中携带有相关图层分层信息参数。具体而言，分层信息参数包括dependency_id(图层的分辨率分级级数)、或者quality_id(图层的质量分级级数)、或者temporal_id(图层的帧率分级级数)。
RTCP中对于(FMT＝4-14)范围的负载层反馈消息类型，都是保留且未作使用的。下面以使用(FMT＝14)为例，说明如何通过RTCP保留的反馈消息类型，扩展携带相关图层分层信息参数的“图象丢包消息”。新扩展的图像丢包消息(FMT＝14)的FCI结构，如下所示。
除了上述两种方法以外，还可以在RTCP协议中新增消息，并在新增的消息中设置分辨率分级级数、或者质量分级级数、或者帧率分级级数，以便携带分层信息。
在对RTCP协议进行扩展之后，本发明实施例提供的视频刷新方法与图9的过程相似，不同之处在于本发明实施例中的关键数据申请消息为上述RTCP协议扩展后的消息，以便携带分层信息，具体而言可以选择在原有消息基础上进行扩展，也可以对RTCP的保留消息扩展，也可以新增RTCP协议消息，以使得扩展后的消息包括分辨率分级级数、或者质量分级级数、或者帧率分级级数。
本发明实施例主要用于视频通信技术领域，例如视频会议***、视频通话技术等等。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。
Claims (19)
1.一种视频刷新方法，其特征在于，包括：
接收视频码流接收设备发送的关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；
对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码；
将所述编码得到的关键数据发送给所述视频码流接收设备。
2.根据权利要求1所述的视频刷新方法，其特征在于，所述视频图像按照帧率分级、分辨率分级、或者质量分级进行分层。
3.根据权利要求1所述的视频刷新方法，其特征在于，所述关键数据申请消息为：多媒体控制协议中的视频快速刷新命令、或宏块组快速刷新命令、或宏块快速刷新命令、或宏块丢包消息、或图象丢包消息、或图象详细丢包消息；或者视频通信反馈信息协议中的图像丢包消息、或宏块组丢包消息；或者实时传输控制协议中的图像丢包消息、或条带丢包消息。
4.根据权利要求1所述的视频刷新方法，其特征在于，通过对多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中原有消息的参数进行扩展后承载所述关键数据申请消息；或者通过对多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中的保留消息进行扩展后承载所述关键数据申请消息；或者通过新增多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中的消息承载所述关键数据申请消息。
5.根据权利要求1所述的视频刷新方法，其特征在于，所述编码得到的关键数据包括：关键编码数据、或者关键宏块编码数据、或者关键分层编码数据。
6.一种视频刷新装置，其特征在于，包括：
接收单元，用于接收视频码流接收设备发送的关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；
编码单元，用于对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码；
发送单元，用于将所述编码得到的关键数据发送给所述视频码流接收设备。
7.根据权利要求6所述的视频刷新装置，其特征在于，所述视频图像按照帧率分级、分辨率分级、或者质量分级进行分层。
8.根据权利要求6所述的视频刷新装置，其特征在于，所述编码单元还用于从所接收到的关键数据申请消息中获取所述分层信息表示的分层。
9.根据权利要求6所述的视频刷新装置，其特征在于，所述发送单元发送的关键数据包括：关键编码数据、或者关键宏块编码数据、或者关键分层编码数据。
10.一种视频刷新方法，其特征在于，包括：
生成关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；
向视频码流发送设备发送所述关键数据申请消息，以指示视频码流发送设备重新发送关键数据。
11.根据权利要求10所述视频刷新方法，其特征在于，所述生成关键数据申请消息为：在检测到丢包、或误码、或乱序时生成所述关键数据申请消息，或者周期性地生成所述关键数据申请消息。
12.根据权利要求10所述视频刷新方法，其特征在于，所述关键数据申请消息为：多媒体控制协议中的视频快速刷新命令、或宏块组快速刷新命令、或宏块快速刷新命令、或宏块丢包消息、或图象丢包消息、或图象详细丢包消息；或者视频通信反馈信息协议中的图像丢包消息、或宏块组丢包消息；或者实时传输控制协议中的图像丢包消息、或条带丢包消息。
13.根据权利要求10所述视频刷新方法，其特征在于，通过对多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中原有消息的参数进行扩展后承载所述关键数据申请消息；或者通过对多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中的保留消息进行扩展后承载所述关键数据申请消息；或者通过新增多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中的消息承载所述关键数据申请消息。
14.一种视频刷新装置，其特征在于，包括：
生成单元，用于生成关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；
发送单元，用于向视频码流发送设备发送所述关键数据申请消息，以指示视频码流发送设备重新发送关键数据。
15.根据权利要求14所述的视频刷新装置，其特征在于，所述生成单元在检测到丢包、或误码、或乱序时生成所述关键数据申请消息，或者周期性地生成并所述关键数据申请消息。
16.根据权利要求14所述的视频刷新装置，其特征在于，所述生成单元生成的关键数据申请消息为：多媒体控制协议中的视频快速刷新命令、或宏块组快速刷新命令、或宏块快速刷新命令、或宏块丢包消息、或图象丢包消息、或图象详细丢包消息；或者视频通信反馈信息协议中的图像丢包消息、或宏块组丢包消息；或者实时传输控制协议中的图像丢包消息、或条带丢包消息。
17.根据权利要求14所述的视频刷新装置，其特征在于，所述生成单元生成的关键数据申请消息为：通过对多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中原有消息的参数进行扩展后承载所述关键数据申请消息；或者通过对多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中的保留消息进行扩展后承载所述关键数据申请消息；或者通过新增多媒体控制协议、或者视频通信反馈信息协议、或者实时传输控制协议中的消息承载所述关键数据申请消息。
18.一种视频刷新***，其特征在于，包括：
视频码流接收设备，用于接收视频码流发送设备发送的视频码流，生成关键数据申请消息，所述关键数据申请消息中包含所申请的数据包分层信息；并向视频码流发送设备发送所述关键数据申请消息；
视频码流发送设备，用于接收所述关键数据申请消息，对视频图像中所述分层信息表示的分层、以及需要依据所述分层信息表示的分层进行解码的分层进行关键数据编码；并将所述编码得到关键数据发送给所述视频码流接收设备。
19.根据权利要求18所述的视频刷新***，其特征在于，所述视频码流接收设备检测到丢包、或误码、或乱序时生成并向视频码流发送设备发送所述关键数据申请消息，或者周期性地生成并向视频码流发送设备发送所述关键数据申请消息。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201010222359.5A CN102316360B (zh) | 2010-07-09 | 2010-07-09 | 视频刷新方法、装置及*** |
| PCT/CN2011/077015 WO2012003808A1 (zh) | 2010-07-09 | 2011-07-09 | 视频刷新方法、装置及*** |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201010222359.5A CN102316360B (zh) | 2010-07-09 | 2010-07-09 | 视频刷新方法、装置及*** |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102316360A true CN102316360A (zh) | 2012-01-11 |
| CN102316360B CN102316360B (zh) | 2015-11-25 |
Family
ID=45429120
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201010222359.5A Expired - Fee Related CN102316360B (zh) | 2010-07-09 | 2010-07-09 | 视频刷新方法、装置及*** |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN102316360B (zh) |
| WO (1) | WO2012003808A1 (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103647923A (zh) * | 2013-12-06 | 2014-03-19 | 广东欧珀移动通信有限公司 | 一种视频通话中的图像显示方法 |
| CN106713924A (zh) * | 2017-01-24 | 2017-05-24 | 钟炎培 | 用于文字分层压缩方法和装置 |
| CN107018423A (zh) * | 2015-09-17 | 2017-08-04 | 联发科技股份有限公司 | 视频编码方法与视频编码装置 |
| CN111149365A (zh) * | 2017-12-19 | 2020-05-12 | 西部数据技术公司 | 利用边缘装置进行内容分发的混合技术 |
| WO2021004239A1 (zh) * | 2019-07-10 | 2021-01-14 | 华为技术有限公司 | 数据处理方法及装置 |
| CN112637635A (zh) * | 2020-12-15 | 2021-04-09 | 西安万像电子科技有限公司 | 文件保密方法及***、计算机可读存储介质及处理器 |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1599308A (zh) * | 2003-09-05 | 2005-03-23 | 三菱电机株式会社 | 包括差错控制机制和差错恢复应用的数据发送方法 |
| CN101001132A (zh) * | 2006-01-10 | 2007-07-18 | 英业达股份有限公司 | 数据无线传输*** |
| CN101155311A (zh) * | 2006-09-27 | 2008-04-02 | 中兴通讯股份有限公司 | 一种视频通信中的视频码流错误检测和处理方法 |
| CN101166270A (zh) * | 2006-10-16 | 2008-04-23 | 华为技术有限公司 | 多媒体视频通信方法及*** |
| CN101193312A (zh) * | 2006-11-22 | 2008-06-04 | 中兴通讯股份有限公司 | 基于反馈的自适应错误恢复装置、视频通信***和方法 |
| CN101370144A (zh) * | 2007-08-16 | 2009-02-18 | 大唐移动通信设备有限公司 | 视频数据的传输方法、***以及发送和接收的方法、装置 |
| CN101394556A (zh) * | 2008-10-29 | 2009-03-25 | 清华大学 | 用于深空通信的图像传输方法、发送装置、接收装置 |
| US20090290648A1 (en) * | 2008-05-20 | 2009-11-26 | Canon Kabushiki Kaisha | Method and a device for transmitting image data |
-
2010
- 2010-07-09 CN CN201010222359.5A patent/CN102316360B/zh not_active Expired - Fee Related
-
2011
- 2011-07-09 WO PCT/CN2011/077015 patent/WO2012003808A1/zh active Application Filing
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1599308A (zh) * | 2003-09-05 | 2005-03-23 | 三菱电机株式会社 | 包括差错控制机制和差错恢复应用的数据发送方法 |
| CN101001132A (zh) * | 2006-01-10 | 2007-07-18 | 英业达股份有限公司 | 数据无线传输*** |
| CN101155311A (zh) * | 2006-09-27 | 2008-04-02 | 中兴通讯股份有限公司 | 一种视频通信中的视频码流错误检测和处理方法 |
| CN101166270A (zh) * | 2006-10-16 | 2008-04-23 | 华为技术有限公司 | 多媒体视频通信方法及*** |
| CN101193312A (zh) * | 2006-11-22 | 2008-06-04 | 中兴通讯股份有限公司 | 基于反馈的自适应错误恢复装置、视频通信***和方法 |
| CN101370144A (zh) * | 2007-08-16 | 2009-02-18 | 大唐移动通信设备有限公司 | 视频数据的传输方法、***以及发送和接收的方法、装置 |
| US20090290648A1 (en) * | 2008-05-20 | 2009-11-26 | Canon Kabushiki Kaisha | Method and a device for transmitting image data |
| CN101394556A (zh) * | 2008-10-29 | 2009-03-25 | 清华大学 | 用于深空通信的图像传输方法、发送装置、接收装置 |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103647923A (zh) * | 2013-12-06 | 2014-03-19 | 广东欧珀移动通信有限公司 | 一种视频通话中的图像显示方法 |
| CN103647923B (zh) * | 2013-12-06 | 2016-08-31 | 广东欧珀移动通信有限公司 | 一种视频通话中的图像显示方法 |
| CN107018423A (zh) * | 2015-09-17 | 2017-08-04 | 联发科技股份有限公司 | 视频编码方法与视频编码装置 |
| CN106713924A (zh) * | 2017-01-24 | 2017-05-24 | 钟炎培 | 用于文字分层压缩方法和装置 |
| CN106713924B (zh) * | 2017-01-24 | 2019-06-07 | 西安万像电子科技有限公司 | 用于文字分层压缩方法和装置 |
| CN111149365A (zh) * | 2017-12-19 | 2020-05-12 | 西部数据技术公司 | 利用边缘装置进行内容分发的混合技术 |
| CN111149365B (zh) * | 2017-12-19 | 2021-12-28 | 西部数据技术公司 | 用于传输数据的装置、***和方法 |
| WO2021004239A1 (zh) * | 2019-07-10 | 2021-01-14 | 华为技术有限公司 | 数据处理方法及装置 |
| CN112637635A (zh) * | 2020-12-15 | 2021-04-09 | 西安万像电子科技有限公司 | 文件保密方法及***、计算机可读存储介质及处理器 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2012003808A1 (zh) | 2012-01-12 |
| CN102316360B (zh) | 2015-11-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Zhu | RTP payload format for H. 263 video streams | |
| CN101175213B (zh) | 视频源编码的方法和设备以及视频源解码的方法和设备 | |
| AU2022209216B2 (en) | Methods and apparatus for use of compact concurrent codecs in multimedia communications | |
| KR101091792B1 (ko) | 피드백 기반 스케일러블 비디오 코딩 | |
| Turletti et al. | RTP payload format for H. 261 video streams | |
| CN1910926B (zh) | 用于处理视频通信差错的方法和装置 | |
| US20100034293A1 (en) | Method and apparatus of multi-view coding and decoding | |
| CN102316360B (zh) | 视频刷新方法、装置及*** | |
| WO2012075968A1 (zh) | 转码业务中获取视频码流的参数集值的方法、***及装置 | |
| US7454692B2 (en) | Encoder based error resilience method in a video codec | |
| US11265583B2 (en) | Long-term reference for error recovery in video conferencing system | |
| US7627184B2 (en) | Content distribution/reception device, content transmission/reception method, and content distribution/reception program | |
| US20070121532A1 (en) | Application specific encoding of content | |
| CN114827669B (zh) | 一种视频数据的传输方法、装置、介质及设备 | |
| US7702994B2 (en) | Method of determining a corruption indication of a sequence of encoded data frames | |
| Zhu | Rfc2190: Rtp payload format for h. 263 video streams | |
| WO2015174893A1 (en) | Methods, decoder and encoder for selection of reference pictures to be used during encoding | |
| Turletti et al. | RFC2032: RTP payload format for H. 261 video streams | |
| KR100543607B1 (ko) | 동영상 디코딩 방법 | |
| KR100557047B1 (ko) | 동영상 디코딩 방법 | |
| KR20040046539A (ko) | 동영상 디코딩 방법 | |
| KR20040046540A (ko) | 동영상 디코딩 방법 | |
| KR20050026110A (ko) | 동영상 디코더 및 디코딩 방법 |
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 | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20170825 Address after: 201, room 1, building A, No. 518053, front Bay Road, Qianhai, Shenzhen Shenzhen cooperation zone, Guangdong, China Patentee after: Shenzhen Zhitong World Technology Service Co. Ltd. Address before: 518129 Longgang District, Guangdong, Bantian HUAWEI base B District, building 2, building No. Patentee before: Huawei Device Co., Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20180104 Address after: 518053 Guangdong city of Shenzhen province Qianhai Shenzhen Hong Kong cooperation area before Bay Street, Qianhai road at the Shenzhen Hong Kong Cooperation Area Management Bureau office building A Building Room 201 Patentee after: Shenzhen Qianhai TengXiang science and Technology Information Co., Ltd. Address before: 201, room 1, building A, No. 518053, front Bay Road, Qianhai, Shenzhen Shenzhen cooperation zone, Guangdong, China Patentee before: Shenzhen Zhitong World Technology Service Co. Ltd. |
|
| TR01 | Transfer of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20151125 Termination date: 20190709 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |