音视频通信方法、终端、服务器、计算机设备和存储介质与流程

1.本发明涉及通信技术领域，特别是涉及一种音视频通信方法、终端、服务器、计算机设备和存储介质。


背景技术：

2.随着互联网技术的发展，在远程医疗、在线教育、视频会议等行业的业务场景中，低延时音视频互动的流媒体服务需求越来越旺盛，现有大部分视频直播是基于rtmp流媒体协议，但基于tcp的数据传输过程过于繁杂，使得整个链路的音视频传输延时通常在1-3秒，无法满足低延时互动的需求；udp协议本身没有连接的概念，不需要三次握手和各种繁杂的传输特性，实时性比tcp好，但是其传输机制存在不可靠传送的问题。


技术实现要素：

3.为了解决上述问题至少之一，本发明第一个实施例提供一种音视频通信方法，应用于终端，包括：
4.接入服务器并通过服务器与另一终端建立音视频会话连接；
5.采集音视频，对所述音视频进行编码压缩并将编码压缩后的数据封装为rtp数据包；
6.基于udp协议将所述rtp数据包发送至所述服务器，所述服务器转发所述rtp数据包发送至所述另一终端。
7.进一步的，还包括：
8.基于udp协议接收经所述服务器转发的由所述另一终端发送的rtp数据包，并解码播放所述经所述服务器转发的由所述另一终端发送的rtp数据包的音视频。
9.进一步的，所述终端还包括发送窗口缓冲区，用于保存第一时间阈值范围内所有发送的所述rtp数据包；
10.所述基于udp协议将所述rtp数据包发送至所述服务器的步骤包括：
11.所述发送窗口缓冲区响应于所述另一终端发送的丢包报文将对应的所述rtp数据包重新发送，其中所述丢包报文为所述另一终端在检测到丢包时刻的一个传输时间周期后发送的。
12.进一步的，所述终端还包括发送窗口缓冲区，用于保存第一时间阈值范围内所有发送的所述rtp数据包；
13.所述基于udp协议将所述rtp数据包发送至所述服务器的步骤包括：
14.所述发送窗口缓冲区接收所述另一终端发送的确认报文并根据所述确认报文与所述rtp数据包的对应关系，删除所述发送窗口缓冲区中包括最小序号的连续rtp数据包。
15.进一步的，所述终端还包括发送窗口缓冲区、第一计数器和第二计数器，其中，所述发送窗口缓冲区用于保存第一时间阈值范围内所有发送的所述rtp数据包，所述第一计数器用于记录所述发送窗口缓冲区中发送时间最早的rtp数据包的时间戳，所述第二计数
器用于记录所述发送窗口缓冲区中发送时间最晚的rtp数据包的时间戳；
16.所述基于udp协议将所述rtp数据包发送至所述服务器的步骤包括：
17.根据所述第一计数器和第二计数器实时获取链路延时；
18.根据所述链路延时实时调整所述编码压缩的编码码率。
19.进一步的，所述根据所述链路延时实时调整所述编码压缩的编码码率进一步包括：
20.若所述链路延时大于预设置的拥塞阈值，根据在第二时间阈值范围内接收的所述另一终端已确认的rtp数据包计算链路实时带宽，并根据所述链路实时带宽调整所述编码压缩的编码码率；
21.若所述链路延时小于预设置的拥塞阈值则根据所述链路延时调整所述编码压缩的编码码率。
22.进一步的，所述基于udp协议将所述rtp数据包发送至所述服务器的步骤还包括：
23.若所述链路延时大于预设置的拥塞阈值，将所述发送窗口缓冲区中的各rtp数据包中第三时间阈值范围外的音视频帧的数据删除。
24.进一步的，所述终端还包括接收窗口缓冲区，用于保存第四时间阈值范围内所有接收的所述rtp数据包；
25.所述基于udp协议接收经所述服务器转发的由所述另一终端发送的rtp数据包，并解码播放所述经所述服务器转发的由所述另一终端发送的rtp数据包的音视频的步骤包括：
26.所述接收窗口缓冲区根据已接收的所述rtp数据包推断即将接收的rtp数据包的预期序号，若最新接收的所述rtp数据包的序号大于所述预期序号则判断存在丢包并获取丢包数量和所述丢包的各rtp数据包的序号，若在检测到所述各rtp数据包的丢包时刻的一个传输时间周期内没有收到对应的rtp数据包则生成包括没有收到的rtp数据包的序号的丢包报文发送至所述另一终端以请求重传。
27.进一步的，所述终端还包括播放缓冲区；
28.所述基于udp协议接收经所述服务器转发的由所述另一终端发送的rtp数据包，并解码播放所述经所述服务器转发的由所述另一终端发送的rtp数据包的音视频的步骤还包括：
29.对接收的rtp数据包进行解封装以获取所述另一终端的音视频数据；
30.所述播放缓冲区根据所述另一终端的音视频数据形成音视频帧，根据第五时间阈值调整各所述音视频帧的播放状态，所述播放状态包括缓冲状态和待播放状态，其中所述第五时间阈值根据所述丢包数量和一个传输时间周期动态调整。
31.进一步的，所述基于udp协议接收经所述服务器转发的由所述另一终端发送的rtp数据包，并解码播放所述经所述服务器转发的由所述另一终端发送的rtp数据包的音视频的步骤还包括：根据所述音视频帧的播放状态拼接画面帧并按照播放时间对所述音视频帧进行解码并进行渲染播放。
32.本发明第二个实施例提供一种音视频通信方法，应用于服务器，包括：
33.分别接收第一终端和第二终端的接入请求并建立所述第一终端和第二终端的音视频会话连接；
34.接收所述第一终端和第二终端中的一个基于udp协议发送的rtp数据包并转发至所述第一终端和第二终端中的另一个，其中所述rtp数据包为所述第一终端或第二终端对采集的音视频进行编码压缩并封装的，使得所述第一终端和第二终端中的另一个基于udp协议接收所述rtp数据包，并解码播放所述rtp数据包的音视频。
35.本发明第三个实施例提供一种终端，包括接入单元、采集编码单元和发送单元，其中
36.所述接入单元，配置为接入服务器并通过服务器与另一终端建立音视频会话连接；
37.所述采集编码单元，配置为采集音视频，对所述音视频进行编码压缩并将编码压缩后的数据封装为rtp数据包；
38.所述发送单元，配置为基于udp协议将所述rtp数据包发送至所述服务器，所述服务器转发所述rtp数据包发送至所述另一终端。
39.进一步的，还包括
40.接收单元，配置为基于udp协议接收经所述服务器转发的由所述另一终端发送的rtp数据包，并解码播放所述经所述服务器转发的由所述另一终端发送的rtp数据包的音视频。
41.本发明第四个实施例提供一种服务器，包括信令交互单元和转发单元，其中
42.所述信令交互单元，配置为分别接收第一终端和第二终端的接入请求并建立所述第一终端和第二终端的音视频会话连接；
43.所述转发单元，配置为接收所述第一终端和第二终端中的一个基于udp协议发送的rtp数据包并转发至所述第一终端和第二终端中的另一个，其中所述rtp数据包为所述第一终端或第二终端对采集的音视频进行编码压缩并封装的，使得所述第一终端和第二终端中的另一个基于udp协议接收所述rtp数据包，并解码播放所述rtp数据包的音视频。
44.本发明第五个实施例提供一种计算机可读存储介质，其上存储有计算机程序，
45.该程序被处理器执行时实现如第一个实施例所述的方法；或者
46.该程序被处理器执行时实现如第二个实施例所述的方法。
47.本发明第六个实施例提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，
48.所述处理器执行所述程序时实现如第一个实施例所述的方法；或者
49.所述处理器执行所述程序时实现如第二个实施例所述的方法。
50.本发明的有益效果如下：
51.本发明针对目前现有的问题，制定一种音视频通信方法、终端、服务器、计算机设备和存储介质，基于udp协议和具体实施步骤进行实时高清的音视频传输，在提高音视频传输可靠性的同时，有效降低音视频传输的延时，从而弥补了现有技术中存在的问题，具有广泛的应用前景。
附图说明
52.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于
本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
53.图1示出本发明的一个实施例所述音视频通信方法的流程图；
54.图2示出本发明的一个实施例所述音视频通信系统的场景示意图；
55.图3示出本发明的另一个实施例所述音视频通信方法的流程图；
56.图4示出本发明的另一个实施例所述的一种计算机设备的结构示意图。
具体实施方式
57.为了更清楚地说明本发明，下面结合优选实施例和附图对本发明做进一步的说明。附图中相似的部件以相同的附图标记进行表示。本领域技术人员应当理解，下面所具体描述的内容是说明性的而非限制性的，不应以此限制本发明的保护范围。
58.需要说明的是，本文中所述的“在
……
上”、“在
……
上形成”和“设置在
……
上”可以表示一层直接形成或设置在另一层上，也可以表示一层间接形成或设置在另一层上，即两层之间还存在其它的层。在本文中，除非另有说明，所采用的术语“位于同一层”指的是两个层、部件、构件、元件或部分可以通过同一构图工艺形成，并且，这两个层、部件、构件、元件或部分一般由相同的材料形成。在本文中，除非另有说明，表述“构图工艺”一般包括光刻胶的涂布、曝光、显影、刻蚀、光刻胶的剥离等步骤。表述“一次构图工艺”意指使用一块掩模板形成图案化的层、部件、构件等的工艺。
59.如图1所示，本发明的一个实施例提供了一种音视频通信方法，应用于终端，包括：接入服务器并通过服务器与另一终端建立音视频会话连接；采集音视频，对所述音视频进行编码压缩并将编码压缩后的数据封装为rtp数据包；基于udp协议将所述rtp数据包发送至所述服务器，所述服务器转发所述rtp数据包发送至所述另一终端。
60.在一个具体的实施例中，如图2所示为使用该音视频通信方法的音视频通信系统，其中，第一终端和第二终端为相同的终端，所述终端可以为电脑、也可以为智能手机、pad等终端通信装置，包括接入单元、采集编码单元、发送单元和接收单元；所述服务器包括信令交互单元或转发单元，所述服务器可以为部署在各应用场景中的实际服务器也可以为云服务器。所述终端应用于不同用户，例如在线远程医疗业务场景中的医生用户和患者用户、在线教育业务场景的教师用户和学生用户、视频会议业务场景中的主持人用户、发言人用户和参会用户等，均使用终端通过服务器实现实时在线高清音视频通信。
61.下面以在线远程医疗业务场景为例进行说明，具体包括：
62.首先，第一终端接入服务器并通过服务器与第二终端建立音视频会话连接。
63.在本实施例中，第一终端和第二终端分别通过接入单元接入服务器，例如通过sdp会话请求与服务器建立连接，即所述第一终端和第二终端通过服务器建立基于信令交互的音视频会话连接通道。
64.其次，第一终端采集音视频，对所述音视频进行编码压缩并将编码压缩后的数据封装为rtp数据包。
65.在本实施例中，第一终端通过采集编码单元对终端用户的音频和视频进行采集，例如第一终端的用户为患者，第二终端的用户为医生，则患者通过第一终端的采集编码单元采集患者的病情陈述，具体的，使用采集编码单元的摄像头采集并录制音视频，并通过采
集编码单元的编码器对所述音视频数据进行编码，并将编码后的数据封装成rtp数据包。
66.再其次，所述第一终端基于udp协议将所述rtp数据包发送至所述服务器，经所述服务器转发所述rtp数据包发送至所述另一终端。
67.第一终端通过发送单元将封装好的所述rtp数据包按照udp协议发送至服务器的转发单元，由服务器的转发单元转发所述rtp数据包至第二终端的接收单元，同时考虑到udp协议本身存在的传输不可靠性，在传输过程中增加实施步骤提高数据传输的可靠性，通过服务器转发至医生使用的第二终端，使得第二终端按照udp协议接收所述rtp数据包中的音视频，从而，第一终端和第二终端基于udp协议并经服务器转发实现实时高清的音视频通信。
68.在一个可选的实施例中，所述终端还包括发送窗口缓冲区，用于保存第一时间阈值范围内所有发送的所述rtp数据包；所述基于udp协议将所述rtp数据包发送至所述服务器的步骤包括：所述发送窗口缓冲区响应于所述另一终端发送的丢包报文将对应的所述rtp数据重新发送，其中所述丢包报文为所述另一终端在检测到丢包时刻的一个传输时间周期后发送的。
69.在本实施例中，每个终端的发送单元包括用于重传的发送窗口缓冲区，所述发送窗口缓冲区用于实现重传功能，具体表现为发送窗口缓冲区保存有一定时间内的所有发送的rtp数据包，在本实施例中所述第一时间阈值为5秒，本技术对此不做限定，本领域技术人员应当根据实际应用需求设置第一时间阈值。现有数据传输过程中发送端通常设置有丢包重传机制，即当接收方反馈未收到数据包时发送端重新发送数据包，然而现有的重传机制存在多发数据包的问题，进而造成带宽浪费和网络拥塞。
70.针对该问题，本实施例实施步骤的丢包重传机制设置如下：第一终端的发送单元采用pull方式实现重传，当作为接收方的第二终端检测到发生丢包时并未立刻反馈丢包，而是在检测到丢包时刻再等待一个传输时间周期后，若仍未接收到该数据包则向作为发送方的第一终端反馈丢包，从而使得第一终端的发送单元的发送窗口缓冲区根据反馈的数据包的序号进行重传。所述传输时间周期通常为在第一终端和第二终端内传输数据所需的时间，若在一个传输时间周期范围内仍未接收到该数据包才确定该数据需要重传，例如将丢失的数据包的序号构建一个segment ack反馈报文给发送方，从而避免由于数据包在传输过程中乱序到达导致的带宽浪费和网络拥塞。
71.同时，考虑到发送方的拥塞控制，在一个可选的实施例中，所述终端还包括发送窗口缓冲区，用于保存第一时间阈值范围内所有发送的所述rtp数据包；所述基于udp协议将所述rtp数据包发送至所述服务器的步骤包括：所述发送窗口缓冲区接收所述另一终端发送的确认报文并根据所述确认报文与所述rtp数据包的对应关系，删除所述发送窗口缓冲区中包括最小序号的连续rtp数据包。
72.在本实施例中，考虑到发送窗口缓冲区缓冲的rtp数据包是为了丢包重传而设计的，保存所有正在发送且没有得到接收方确认的rtp数据包。而在网络拥塞时第一终端的发送单元的发送端窗口缓冲区中有很多rtp数据包正在发送，为了缓解拥塞和降低延时，需要对整个缓冲区做检查，如果有超过一定阈值时间的h.264gop分组存在，则将这个视频帧的报文从发送窗口缓冲区移除，并将下一个gop分组的i帧id和报文id同步发送到接收终端，接收终端接收到该同步消息，会将最新连续的id设置成同步过来的id。如果丢弃的过期帧
过多会造成视频画面卡顿，说明当前网络不适合传输高分辨率视频，则直接将视频设成更小的分辨率。
73.具体如下：当发送单元接收到作为接收方的第二终端反馈的确认报文，根据所述确认报文与所述rtp数据包的对应关系，发送窗口缓冲区删除所述确认报文中的包括最小序号的连续所述rtp数据包。例如，作为发送方的第一终端发送的rtp数据包的序号为1，2，3，4，5，作为接收方的第二终端接收到的rtp数据包的序号为1，2，4，5，第二终端向第一终端发送确认报文，所述确认报文中包括对应的rtp数据包的标识，例如序号，则第一终端接收该确认报文，并根据确认报文中的标识确定对应的rtp数据包，即第一终端明确第二终端接收了序号为1，2，4，5的rtp数据包，此时最小序号的rtp数据包为1，包括最小序号1的连续rtp数据包的包括序号为1和2的rtp数据包，则所述发送窗口缓冲区删除序号小于等于2的所有rtp数据包。此时最小序号为3，如果第二终端又接收到序号为3的数据包序号并向第一终端发送确认报文，则第一终端确定所述第二终端接收的包括最小序号3的连续rtp数据包的序号为5，则发送窗口缓冲区删除报文序号小于等于5的所有报文对应的rtp数据包，即序号为3、4和5的rtp数据包。
74.为进一步控制发送方的拥塞控制，在一个可选的实施例中，所述终端还包括发送窗口缓冲区、第一计数器和第二计数器，其中，所述发送窗口缓冲区用于保存第一时间阈值范围内所有发送的所述rtp数据包，所述第一计数器用于记录所述发送窗口缓冲区中发送时间最早的rtp数据包的时间戳，所述第二计数器用于记录所述发送窗口缓冲区中发送时间最晚的rtp数据包的时间戳；所述基于udp协议将所述rtp数据包发送至所述服务器的步骤包括：根据所述第一计数器和第二计数器实时获取链路延时；根据所述链路延时实时调整所述编码压缩的编码码率。
75.在本实施例中，使用第一计数器记录发送窗口缓冲区中最早发送报文的时间戳，使用第二计数器记录发送窗口缓冲区中当前发送报文的时间戳，根据第一计数器和第二计数器获取实时链路延时，即第一计数器的时间戳和第二计数器的时间戳的差值，再根据链路延时实时调整采集编码单元的编码器的编码码率，从而根据实时链路延时调整编码器的编码压缩的编码码率。
76.具体的，在一个可选的实施例中，所述根据所述链路延时实时调整所述编码压缩的编码码率进一步包括：若所述链路延时大于预设置的拥塞阈值，根据在第二时间阈值范围内接收的所述另一终端已确认的rtp数据包计算链路实时带宽，并根据所述链路实时带宽调整所述编码压缩的编码码率；若所述链路延时小于预设置的拥塞阈值则根据所述链路延时调整所述编码压缩的编码码率。
77.在本实施例中，通过预设置的拥塞阈值和获取的链路实时带宽实时调整编码器的编码压缩的编码码率。具体的，例如根据在最近30秒时间内作为接收方的第二终端确认收到的数据大小计算一个带宽值，把该带宽值反馈给作为发送方的第一终端的采集编码单元的编码器，所述编码器根据接收的带宽实时调整编码码率。即当网络拥塞时降低编码器编码码率，而当网络拥塞好转时逐渐恢复编码器编码码率。
78.为进一步降低音视频传输的延时，在一个可选的实施例中，所述基于udp协议将所述rtp数据包发送至所述服务器的步骤还包括：若所述链路延时大于预设置的拥塞阈值，将所述发送窗口缓冲区中的各rtp数据包中第三时间阈值范围外的音视频帧的数据删除。
79.在本实施例中，根据链路延时删除发送窗口缓冲区中存储的一定时间范围内的音视频帧数据，以减少发送窗口缓冲区中存储的音视频帧数据，从而缓解当前网络传输环境下的链路延时。在本实施例中，所述第三时间阈值为1秒，本技术对此不做限定，本领域技术人员应当根据实际应用需求进行设定，在此不再赘述。
80.最后，第一终端基于udp协议接收经所述服务器转发的由所述另一终端发送的rtp数据包，并解码播放所述经所述服务器转发的由所述另一终端发送的rtp数据包的音视频。
81.在本实施例中，第一终端的接收单元以udp方式接收由服务器转发的rtp数据包，然后对接收的rtp数据包进行解析、解码从而获得第二终端发送的音视频数据，例如获取医生的病情询问或用药的注意事项等，从而提高udp方式传输的可靠性，降低rtp数据包的传输延时。
82.具体的，在一个可选的实施例中，所述终端还包括接收窗口缓冲区，用于保存第四时间阈值范围内所有接收的所述rtp数据包；所述基于udp协议接收经所述服务器转发的由所述另一终端发送的rtp数据包，并解码播放所述经所述服务器转发的由所述另一终端发送的rtp数据包的音视频的步骤包括：所述接收窗口缓冲区根据已接收的所述rtp数据包推断即将接收的rtp数据包的预期序号，若最新接收的所述rtp数据包的序号大于所述预期序号则判断存在丢包并获取丢包数量和所述丢包的各rtp数据包的序号，若在检测到所述各rtp数据包的丢包时刻的一个传输时间周期内没有收到对应的rtp数据包则生成包括没有收到的rtp数据包的序号的丢包报文发送至所述另一终端以请求重传。
83.在本实施例中，通过设置在第一终端的接收单元的接收窗口缓冲区进行丢包检测和丢包序号管理。其中，丢包检测具体包括：假设接收窗口缓冲区当前接收的最大的rtp数据包序号为5，则推断即将接收的rtp数据包序号为6，若最新接收的rtp数据包的序号为8，即最新接收的rtp数据包的序号大于推断出的rtp数据包序号则表明存在丢包，丢失的rtp数据包的个数为2，rtp数据包的序号为6和7。为避免因接收的rtp数据包在传输过程中乱序到达导致过度重传，此时第一终端暂时不向第二终端发送丢失rtp数据包的序号和重传请求，而是在检测到丢包时刻的基础上再等待一个传输时间周期的时间，若在此时间范围内仍未接收到丢失的rtp数据包则向第二终端发送丢包反馈以请求第二终端进行重传。
84.考虑到第一终端根据接收的数据包进行稳定播放，在一个可选的实施例中，所述终端还包括播放缓冲区；所述基于udp协议接收经所述服务器转发的由所述另一终端发送的rtp数据包，并解码播放所述经所述服务器转发的由所述另一终端发送的rtp数据包的音视频的步骤还包括：对接收的rtp数据包进行解封装以获取所述另一终端的音视频数据；所述播放缓冲区根据所述另一终端的音视频数据形成音视频帧，根据第五时间阈值调整各所述音视频帧的播放状态，所述播放状态包括缓冲状态和待播放状态，其中所述第五时间阈值根据所述丢包数量和一个传输时间周期动态调整。
85.在本实施例中，通过设置在接收单元的播放缓冲区防止播放抖动并应对丢包重传，从而使得视频流能够按照采集时的频率进行播放。其中，所述播放缓冲区将接收的音视频数据划分为音视频帧并按照音视频帧的顺序号进行排序以便于顺序播放。同时，设置每个音视频帧的状态，当所述音视频帧的状态为waiting时表示该音视频帧处于缓冲状态，即暂时不能播放；当所述音视频帧的状态为playing时表示该音视频帧为待播放状态，等待接收单元对所述音视频帧进行解码播放。
86.具体的：
87.第一步，每个音视频帧初始设置为缓冲状态waiting。
88.第二步，所述接收单元包括两个计数器，分别用于记录所述播放缓冲区中最新音视频帧的时间戳和最老音视频帧的时间戳以获取两帧时间戳的差值，并判断该差值是否大于预设置的第五时间阈值，若大于第五时间阈值则将音视频帧的状态设置为待播放状态playing。
89.需要说明的是，所述播放缓冲区设置过大则增加延时，若所述播放缓冲区设置过小则会出现视频卡顿现象。在本实施例中，通过设置可以动态调整的第五时间阈值调整音视频帧的状态，具体表现为：将rtp数据包在第一终端和第二终端之间的传输时间作为传输时间周期，同时根据传输过程中丢包的数量共同估算并设置播放缓冲区的大小。即根据所述丢包数量和一个传输时间周期动态调整第五时间阈值，从而动态调整播放缓冲区的大小。
90.值得注意的是，若单位时间内没有发生丢包重传则可以适当缩小第五时间阈值从而减少延时，例如将第五时间阈值设置为一帧音视频数据的播放时间，则播放缓冲区仅缓冲了一帧音视频数据；若网络存在间歇性波动导致第五时间阈值设置的较大从而增大播放缓冲区并导致延时增加，在网络恢复正常后第五时间阈值会再次动态减小以降低延时；从而通过动态设置的第五时间阈值动态调整播放缓冲区的大小，进而调整各音视频帧的播放状态。
91.在一个可选的实施例中，所述基于udp协议接收经所述服务器转发的由所述另一终端发送的rtp数据包，并解码播放所述经所述服务器转发的由所述另一终端发送的rtp数据包的音视频的步骤还包括：根据所述音视频帧的播放状态拼接画面帧并按照播放时间对所述音视频帧进行解码并进行渲染播放。具体表现为：
92.第三步，判断播放状态为待播放状态的音视频帧是否可以播放。
93.在本实施例中，从两个方面判断是否对待播放状态的音视频帧进行解码播放，第一方面满足待播放状态的音视频帧需要符合播放的时间要求，第二方面待播放状态的音视频帧需凑足一帧音视频的播放量。
94.第四步，若可以播放在对各音视频帧进行界面渲染并播放。
95.在本实施例中，通过第一终端的接收单元对各音视频帧进行解码并播放各音视频帧的内容。
96.至此，实现使用第一终端的患者和使用第二终端的医生之间通过udp方式的实时在线高清音视频通信。
97.本实施例相对于tcp采用的三次握手的连接方式，采用基于udp协议和具体实施步骤，能够有效降低各终端之间通信连接过程的复杂度，缩短了通信连接的建立时间，降低了通信过程中的传输延时，提高实时传输的可靠性，即在降低延时的基础上提供数据传输的可靠性，确保在网络不稳定的情况下保证音视频稳定传输及低延时。
98.与上述音视频通信方法相对应，本技术的一个实施例还提供一种应用于服务器的音视频通信方法，如图3所示，所述音视频通信方法包括：分别接收第一终端和第二终端的接入请求并建立所述第一终端和第二终端的音视频会话连接；接收所述第一终端和第二终端中的一个基于udp协议发送的rtp数据包并转发至所述第一终端和第二终端中的另一个，
其中所述rtp数据包为所述第一终端或第二终端对采集的音视频进行编码压缩并封装的，使得所述第一终端和第二终端中的另一个基于udp协议接收所述rtp数据包，并解码播放所述rtp数据包的音视频。
99.本实施例的具体实施方式与前述音视频通信方法相类似，在此不再赘述。
100.与上述实施例提供的音视频通信方法相对应，本技术的一个实施例还提供一种使用该音视频通信方法的终端以及一种使用该音视频通信方法的服务器，由于本技术实施例提供的终端和服务器与上述几种实施例提供的音视频通信方法相对应，因此在前实施方式也适用于本实施例提供的终端和服务器，在本实施例中不再详细描述。
101.如图2所示，本技术的一个实施例还提供一种使用该音视频通信方法的终端，包括接入单元、采集编码单元和发送单元，其中所述接入单元，配置为接入服务器并通过服务器与另一终端建立音视频会话连接；所述采集编码单元，配置为采集音视频，对所述音视频进行编码压缩并将编码压缩后的数据封装为rtp数据包；所述发送单元，配置为基于udp协议将所述rtp数据包发送至所述服务器，所述服务器转发所述rtp数据包发送至所述另一终端。
102.在一个可选的实施例中，所述终端还包括：接收单元，配置为基于udp协议接收经所述服务器转发的由所述另一终端发送的rtp数据包，并解码播放所述经所述服务器转发的由所述另一终端发送的rtp数据包的音视频。
103.同理，如图2所示，本技术的一个实施例还提供一种使用该音视频通信方法的服务器，包括信令交互单元和转发单元，其中所述信令交互单元，配置为分别接收第一终端和第二终端的接入请求并建立所述第一终端和第二终端的音视频会话连接；所述转发单元，配置为接收所述第一终端和第二终端中的一个基于udp协议发送的rtp数据包并转发至所述第一终端和第二终端中的另一个，其中所述rtp数据包为所述第一终端或第二终端对采集的音视频进行编码压缩并封装的，使得所述第一终端和第二终端中的另一个基于udp协议接收所述rtp数据包，并解码播放所述rtp数据包的音视频。
104.本发明的另一个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现：接入服务器并通过服务器与另一终端建立音视频会话连接；采集音视频，对所述音视频进行编码压缩并将编码压缩后的数据封装为rtp数据包；基于udp协议将所述rtp数据包发送至所述服务器，所述服务器转发所述rtp数据包发送至所述另一终端。
105.本发明的另一个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现：分别接收第一终端和第二终端的接入请求并建立所述第一终端和第二终端的音视频会话连接；接收所述第一终端和第二终端中的一个基于udp协议发送的rtp数据包并转发至所述第一终端和第二终端中的另一个，其中所述rtp数据包为所述第一终端或第二终端对采集的音视频进行编码压缩并封装的，使得所述第一终端和第二终端中的另一个基于udp协议接收所述rtp数据包，并解码播放所述rtp数据包的音视频。
106.在实际应用中，所述计算机可读存储介质可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有
一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
107.计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
108.计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、电线、光缆、rf等等，或者上述的任意合适的组合。
109.可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c++，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
110.如图4所示，本发明的另一个实施例提供的一种计算机设备的结构示意图。图4显示的计算机设备12仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
111.如图4所示，计算机设备12以通用计算设备的形式表现。计算机设备12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
112.总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(isa)总线，微通道体系结构(mac)总线，增强型isa总线、视频电子标准协会(vesa)局域总线以及外围组件互连(pci)总线。
113.计算机设备12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被计算机设备12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
114.系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)30和/或高速缓存存储器32。计算机设备12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图4未显示，通常称为“硬盘驱动器”)。尽管图4中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如cd-rom，dvd-rom或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产
品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。
115.具有一组(至少一个)程序模块42的程序/实用工具40，可以存储在例如存储器28中，这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本发明所描述的实施例中的功能和/或方法。
116.计算机设备12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该计算机设备12交互的设备通信，和/或与使得该计算机设备12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口22进行。并且，计算机设备12还可以通过网络适配器20与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图4所示，网络适配器20通过总线18与计算机设备12的其它模块通信。应当明白，尽管图4中未示出，可以结合计算机设备12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
117.处理器单元16通过运行存储在系统存储器28中的程序，从而执行各种功能应用以及数据处理，例如实现本发明实施例所提供的一种音视频通信方法。
118.本发明针对目前现有的问题，制定一种音视频通信方法、终端、服务器、计算机设备和存储介质，基于udp协议和具体实施步骤进行实时高清的音视频传输，在提高音视频传输可靠性的同时，有效降低音视频传输的延时，从而弥补了现有技术中存在的问题，具有广泛的应用前景。
119.显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定，对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动，这里无法对所有的实施方式予以穷举，凡是属于本发明的技术方案所引伸出的显而易见的变化或变动仍处于本发明的保护范围之列。