发明内容
本发明的目的在于提供一种编解码器能力协商方法及终端,用于经由数字网络的终端之间的音频或视频通信中,采用编解码器能力自协商的方式,以提高编码算法选择的灵活性,改善音频或视频通信质量,增强终端用户体验。
为实现上述目的,本发明提供一种编解码器能力协商方法,包括:
在第一终端中存储用于指示协商是否完成的协商标识,并将所述协商标识设置为协商未完成;
第一终端的编码器采用基线算法对媒体数据进行编码后发送,发送的数据包中携带第一终端的编解码器最大支持的编码算法能力集和协商未完成指示,以供第二终端获取协商后的编码算法,并采用协商后的编码算法对媒体数据进行编码后发送,其中,所述协商后的编码算法为第一、二终端的编解码器最大支持的编码算法能力集的交集,第二终端发送的数据包中携带协商后的编码算法和协商已完成指示;
第一终端的解码器接收到第二终端发送的携带有协商后的编码算法和协商已完成指示的数据包时,将所述协商后的编码算法通知给编码器,将所述协商标识设置为协商已完成。
上述的编解码器能力协商方法,其中,还包括:
第一终端的解码器接收到第二终端发送的携带有协商后的编码算法和协商已完成指示的数据包时,采用协商后的编码算法进行解码。
上述的编解码器能力协商方法,其中,还包括:
第一终端的编码器进行编码时,若所述协商标识指示协商已完成,则采用协商后的编码算法对媒体数据进行编码后发送,发送的数据包中携带所述协商后的编码算法和协商已完成指示。
上述的编解码器能力协商方法,其中,还包括:
第二终端接收到第一终端发送的携带有协商未完成指示的数据包时,采用基线算法进行解码;
第二终端接收到第一终端发送的携带有协商已完成指示的数据包时,采用协商后的编码算法进行解码。
上述的编解码器能力协商方法,其中:
协商后的编码算法、编解码器最大支持的编码算法能力集由发送的数据包的编码头携带,协商已完成指示、协商未完成指示由发送的数据包的包头携带。
为实现上述目的,本发明还提供一种编解码器能力协商方法,包括:
在第二终端中存储用于指示协商是否完成的协商标识,并将所述协商标识设置为协商未完成;
第二终端的解码器接收到第一终端发送的携带有第一终端的编解码器最大支持的编码算法能力集和协商未完成指示的数据包时,求取第一、二终端的编解码器最大支持的编码算法能力集的交集,得到协商后的编码算法,将协商后的编码算法通知给第二终端的编码器,将所述协商标识设置为协商已完成;
第二终端的编码器采用协商后的编码算法对媒体数据进行编码后发送,发送的数据包中携带协商后的编码算法和协商已完成指示,以供第一终端获取协商后的编码算法。
上述的编解码器能力协商方法,其中,还包括:
第二终端接收到第一终端发送的携带有协商未完成指示的数据包时,采用基线算法进行解码;
上述的编解码器能力协商方法,其中,还包括:
第一终端获取到协商后的编码算法后,将第一终端中存储的协商标识设置为协商已完成,并采用协商后的编码算法对媒体数据进行编码后发送,发送的数据包中携带所述协商后的编码算法和协商已完成指示。
上述的编解码器能力协商方法,其中,还包括:
第二终端接收到第一终端发送的携带有协商已完成指示的数据包时,采用协商后的编码算法进行解码。
为实现上述目的,本发明还提供一种终端,包括,编码器、解码器和存储模块,其中:
所述存储模块用于存储指示协商是否完成的协商标识;
所述编码器进行编码时,若所述协商标识指示协商未完成,则采用基线算法对媒体数据进行编码后发送,发送的数据包中携带本端终端的编解码器最大支持的编码算法能力集和协商未完成指示,以供对端终端获取协商后的编码算法,并采用协商后的编码算法对媒体数据进行编码后发送,其中,所述协商后的编码算法为本端终端的编解码器最大支持的编码算法能力集与对端终端的编解码器最大支持的编码算法能力集的交集,对端终端发送的数据包中携带协商后的编码算法和协商已完成指示;
所述解码器接收到对端终端发送的携带有协商后的编码算法和协商已完成指示的数据包时,将所述协商后的编码算法通知给编码器,将所述协商标识设置为协商已完成。
上述的终端,其中:
所述解码器接收到对端终端发送的携带有协商后的编码算法和协商已完成指示的数据包时,采用协商后的编码算法进行解码。
上述的终端,其中:
所述编码器进行编码时,若存储模块中存储的协商标识指示协商已完成,则采用协商后的编码算法对媒体数据进行编码后发送,发送的数据包中携带协商后的编码算法和协商已完成指示。
上述的终端,其中:
协商后的编码算法、编解码器最大支持的编码算法能力集由发送的数据包的编码头携带;协商已完成指示、协商未完成指示由发送的数据包的包头携带。
为实现上述目的,本发明还提供一种终端,包括,编码器、解码器和存储模块,其中:
所述存储模块用于存储指示协商是否完成的协商标识;
所述解码器接收到对端终端发送的携带有对端终端的编解码器最大支持的编码算法能力集和协商未完成指示的数据包时,求取本端终端的编解码器最大支持的编码算法能力集与对端终端的编解码器最大支持的编码算法能力集的交集,得到协商后的编码算法,将协商后的编码算法通知给编码器,将所述协商标识设置为协商已完成;
所述编码器采用协商后的编码算法对媒体数据进行编码后发送,发送的数据包中携带协商后的编码算法和协商已完成指示,以供对端终端获取协商后的编码算法。
上述的终端,其中:
所述解码器接收到对端终端发送的携带有协商未完成指示的数据包时,采用基线算法进行解码;
所述解码器接收到对端终端发送的携带有协商已完成指示的数据包时,采用协商后的编码算法进行解码。
与现有技术相比,本发明的有益效果是:
本发明不需要采用信令方式,直接根据本地存储的编解码器协商标识和数据包中携带的相关信息即可完成编解码器能力的协商,即,实现了编解码器能力的自协商,从而提高了编码算法选择的灵活性。当编解码器能力协商完成后,终端可以采用相互都能够支持的编码算法(包括编码标准规范中的可选的编码算法),极大的保证了终端编解码器能力利用的最大化及带宽利用最大化,从而可以改善终端之间的音频或视频通信质量,增强终端用户体验。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图及具体实施例对本发明进行详细描述。
参照图1,本发明实施例的编解码器能力协商方法,包括如下步骤:
步骤101:在第一、二终端中存储用于指示协商是否完成的协商标识,初始时,将所述协商标识均设置为协商未完成;
步骤102:第一终端的编码器采用基线算法对媒体数据进行编码后发送,发送的数据包中携带第一终端的编解码器最大支持的编码算法能力集和协商未完成指示;
步骤103:第二终端的解码器接收到第一终端发送的携带有第一终端的编解码器最大支持的编码算法能力集和协商未完成指示的数据包后,求取第一、二终端的编解码器最大支持的编码算法能力集的交集,得到协商后的编码算法,将协商后的编码算法通知给第二终端的编码器,并将第二终端中存储的协商标识设置为协商已完成;
在本步骤中,第二终端的解码器采用基线算法对第一终端发送的数据包进行解码。
步骤104:第二终端的编码器采用协商后的编码算法对媒体数据进行编码后发送,发送的数据包中携带协商后的编码算法和协商已完成指示;
步骤105:第一终端的解码器接收到第二终端发送的携带有协商后的编码算法和协商已完成指示的数据包时,将所述协商后的编码算法通知给第一终端的编码器,并将第一终端中存储的协商标识设置为协商已完成。
在本步骤中,第一终端的解码器采用协商后的编码算法对第二终端发送的数据包进行解码。
至此,第一、二终端之间的编解码器能力协商完成,在随后的通信过程中,均采用协商后的编码算法进行编解码。
在具体实现时,协商后的编码算法、编解码器最大支持的编码算法能力集可由发送的数据包的编码头携带;协商已完成指示、商未完成指示可由发送的数据包的包头携带。可以理解的是,这些信息也可以由发送的数据包中的其他字段携带,本发明对此不作限制。
参照图2,本发明实施例的终端10包括编码器11、解码器12和存储模块13,其中:
所述存储模块13用于存储指示协商是否完成的编解码器协商标识(简称协商标识),例如,协商标识为TRUE,代表本端终端的编解码器能力协商已完成,协商标识为TRUE,代表本端终端的编解码器能力协商未完成;
所述编码器11进行编码时,若存储模块中存储的协商标识指示协商已完成,则采用协商后的编码算法对媒体数据(音频数据、视频数据等)进行编码后发送,发送的数据包中携带协商后的编码算法和协商已完成指示;若所述协商标识指示协商未完成,则采用编码标准规范中强制要求实施的编码算法(基线算法)对媒体数据进行编码后发送,发送的数据包中携带终端的编解码器最大支持的编码算法能力集和协商未完成指示;
所述解码器12接收到数据包时,若所述协商标识指示协商未完成,则判断接收的数据包中是否携带有协商已完成指示,若是,将接收的数据包中携带的协商后的编码算法通知给所述编码器11,并将所述协商标识设置为协商已完成;否则,求本端终端的编解码器最大支持的编码算法能力集与接收的数据包中携带的对端终端的编解码器最大支持的编码算法能力集的交集,得到协商后的编码算法,将协商后的编码算法通知给所述编码器11,并将所述协商标识设置为协商已完成。
其中,协商后的编码算法、编解码器最大支持的编码算法能力集可由发送的数据包的编码头携带;协商已完成指示、商未完成指示可由发送的数据包的包头携带。
本发明实施例的终端,不需要采用信令方式,直接根据本地存储的编解码器协商标识和数据包中携带的相关信息即可完成编解码器能力的协商,即,实现了编解码器能力的自协商,从而提高了编码算法选择的灵活性。
进一步,本发明实施例的终端中的解码器进行解码时,若接收的数据包中携带有协商已完成指示,则采用接收的数据包中携带的协商后的编码算法进行解码;若接收的数据包中携带有协商未完成指示,则采用基线算法进行解码。
图3是本发明实施例的终端中编码器工作流程的示意图,参照图3,包括如下步骤:
步骤301:编码器开始编码操作时,先判断编解码器协商标识,若该协商标识为FALSE,进入步骤302,若该协商标识为TRUE,进入步骤303;
步骤302:协商标识为FALSE,表示本端终端的编解码器能力协商未完成,编码器采用编码标准规范中强制要求实施的编码算法(基线算法)对媒体数据(音频数据、视频数据等)进行编码后发送,在发送的数据包的编码头中携带本端编解码器最大支持的编码算法能力集,在发送的数据包的包头中携带协商未完成指示,结束;
步骤303:协商标识为TRUE,表示本端终端的编解码器能力协商已完成,编码器采用协商后的编码算法对媒体数据进行编码后发送,在发送的数据包的编码头中携带协商后的编码算法,在发送的数据包的包头中携带协商已完成指示。
图4是本发明实施例的终端中解码器工作流程的示意图,参照图4,包括如下步骤:
步骤401:本端终端接收到对端终端发送的音频或视频数据包后,本端终端的解码器先判断本地存储的编解码器协商标识,若该协商标识为FALSE,进入步骤402,若该协商标识为TRUE,进入步骤403;
步骤402:协商标识为FALSE,表示本端终端的编解码器能力协商未完成,本端终端的解码器通过解析接收的数据包的包头信息获取协商完成指示,若该协商完成指示为FALSE,进入步骤404,若该协商完成指示为TRUE,进入步骤407;
步骤403:协商标识为TRUE,表示本端终端的编解码器能力协商已完成,本端终端的解码器通过解析接收的数据包的包头信息获取协商完成指示,若该协商完成指示为FALSE,进入步骤410,若该协商完成指示为TRUE,进入步骤409;
步骤404:协商完成指示为FALSE,表示对端终端的编解码器能力协商未完成,本端终端的解码器通过解析接收的数据包的编码头信息,获取对端终端的编解码器最大支持的编码算法能力集P1;
步骤405:用本端终端的编解码器最大支持的编码算法能力集P2与P1做交集,得到编码算法能力集P3,将P3作为协商后的编码算法;
步骤406:将协商后的编码算法通知给本端终端的编码器,并设置编解码器协商标识为TRUE,完成本端终端的编解码器能力协商过程,然后,进入步骤310的解码过程;
步骤407:协商完成指示为TRUE,表示对端终端的编解码器能力协商已完成,本端终端的解码器通过解析接收的数据包的编码头信息,获取对端终端发送的协商后的编码算法;
步骤408:将协商后的编码算法通知给本端终端的编码器,并设置编解码器协商标识为TRUE,完成本端终端的编解码器能力协商过程,然后,进入步骤309的解码过程;
步骤409:协商完成指示为FALSE,表示对端终端的编解码器能力协商未完成,说明对端终端的编码器的编码采用的是编码标准规范强制要求实施的编码算法,因此,本端终端的解码器按照编码标准规范强制要求实施的编码算法对接收到的数据包进行解码;
步骤410:协商完成指示为TRUE,表示对端终端的编解码器能力协商已完成,说明对端终端的编码器的编码采用的是协商后的编码算法,因此,本端终端的解码器根据接收到的数据包的编码头信息中携带的编码算法(此即协商后的编码算法)进行解码。
以下给出本发明实施例的终端之间进行媒体会话的一个应用实例。
参照图5,终端T1与终端T2之间进行的媒体会话过程,主要包括如下步骤:
步骤501:终端T1与终端T2通过信令协商过程,选择编码类型;
需要说明的是,本步骤中通过信令协商的仅为编码类型,而非编码算法。如前所述,在各种编码标准规范中,除了规范强制要求实施的编码算法外,还有部分可选的编码算法,因此,在后续步骤中,还通过非信令的方式协商编码算法。
步骤502:终端T1与终端T2之间建立实时传输协议(RTP)媒体通道,并初始化终端T1与终端T2的编解码器协商标识为FALSE,开始音频或视频会话过程;
步骤503:终端T1需要向终端T2发送第一个RTP数据包时,此时终端T1的编解码器协商标识为FALSE,表示终端T1的编解码器能力协商未完成,终端T1的编码器采用编码标准规范中强制要求实施的编码算法对媒体数据进行编码后发送,在发送的数据包的编码头中携带终端T1的编解码器最大支持的编码算法能力集P1,在发送的数据包的包头中携带协商未完成指示;
步骤504:终端T2收到终端T1发送的第一个RTP数据包时,此时终端T2的编解码器协商标识为FALSE,表示终端T2的编解码器能力协商未完成,于是,终端T2的解码器通过解析接收的数据包的包头来获取协商完成指示,此时,该协商完成指示为FALSE,表示终端T1的编解码器能力协商未完成,继续解析接收的数据包的编码头获取终端T1最大支持的编码算法能力集P1,终端T2用自身最大支持的编码算法能力集P2与P1做交集,得到终端T1与终端T2都能够支持的编码算法能力集P3,将P3作为协商后的编码算法通知给终端T2的编码器,并修改终端T2的编解码器协商标识为TRUE;
终端T2的编码器在随后的编码过程中采用P3中的编码算法,并在RTP数据包的编码头中携带P3中的编码算法,在RTP数据包的包头中携带协商已完成指示;
在本步骤中,由于终端T2获知终端T1的编解码器能力协商还未完成,则可以确定终端T1的编码器采用的是编码标准规范中强制要求实施的编码算法进行的编码,因此,终端T2的解码器对该接收到的数据包采用编码标准规范中强制要求实施的编码算法进行解码。
步骤505:终端T1接收到终端T2发送的RTP数据包,此时终端T1的编解码器协商标识为FALSE,表示终端T1的编解码器能力协商未完成,终端T1的解码器通过解析接收的数据包的包头中携带的协商完成指示,获知终端T2协商已完成,于是,继续通过解析接收的数据包的编码头信息获取协商后的编码算法,将获取到的协商后的编码算法通知给终端T1的编码器,并修改终端T1的编解码器协商标识为TRUE,终端T1的编码器在随后的编码过程中采用协商后的编码算法。
从以上对本发明的实施例的描述可知,根据本发明实施例提供的技术方案,若终端在确定本端的编解码器能力协商未完成,即终端编解码器协商标识为FALSE,编码器采用编码标准规范中强制要求实施的编码算法,以保证对端能够正常对收到的音频或视频数据进行解码,这种方法特别对于视频通信有着极其重要的意义。
在视频编码算法中,为了能够提高带宽的利用率,采用了“关键帧”压缩算法,关键帧是对全图像的压缩编码,而非关键帧(预测帧)是对当前图像和相邻图像的不同点来压缩数据,解码器收到非关键帧进行解码操作时需要参考相邻的图像数据。在视频通信中,关键帧和非关键帧(预测帧)通常是交替传输的,而第一帧必然为关键帧,如果第一帧丢失或者接收端解码失败必然导致接收端的视频质量大幅下降。因此,在编解码器能力协商完成前,采用编码标准规范强制要求实施的编码算法,可以极大的保证终端之间的视频通信质量。
根据本发明实施例提供的技术方案,当终端收到对端的数据包进行解码操作时,需要先判断数据包头部携带的协商完成指示。若协商未完成,表示该数据包携带的音频或视频数据采用的是编码标准规范中强制要求实施的编码算法;若协商已完成,表示该数据包携带的音频或视频数据采用的是协商后的编码算法。采用这种方式,可以保证终端在编解码器能力协商过程中发送的音频或视频数据包能够被对方正常解码。
根据本发明实施例提供的技术方案,当编解码器能力协商完成后,终端可以采用相互都能够支持的编码算法,从而保证了编码算法选择的灵活性,极大的保证了终端编解码器能力利用的最大化及带宽利用最大化,并且可以改善终端之间的音频或视频通信质量,增强终端用户体验。
最后应当说明的是,以上实施例仅用以说明本发明的技术方案而非限制,本领域的普通技术人员应当理解,可以对本发明的技术方案进行修改或者等同替换,而不脱离本发明技术方案的精神范围,其均应涵盖在本发明的权利要求范围当中。