音视频数据的传输方法和系统与流程

1.本技术实施例涉及通信技术领域，尤其涉及一种音视频数据的传输方法、系统、计算机设备及计算机可读存储介质。


背景技术：

2.随着视频会议、视频直播的流行以及未来ar/vr业务的发展，实时视频传输服务被广泛使用。在此背景下，如何在弱网环境下，依旧保持安全可靠且低延迟地传输音视频流数据，满足人们随时随地观看视频的需求日益增加。
3.现有技术中，主要有使用tcp传输数据的方案和基于udp的应用层协议quic传输数据的方案。然而，tcp的握手时延高、队头阻塞等弊病造成的高时延和低效率愈发凸显，在弱网环境下，甚至可能导致视频无法播放。而采用基于quic有序可靠地传输音视频流或者音视频帧的方案，虽然其能够使新的quic连接实现0-rtt建联，但是在弱网环境下，quic stream是可靠有序传输所有音视频数据，对于这些数据，一旦丢包都需要重传，而客户端处于弱网环境下时，过多的重传包将会继续恶化网络环境，影响用户的观看体验。


技术实现要素：

4.本技术实施例的目的是提供一种音视频数据的传输方法、系统、计算机设备及计算机可读存储介质，用于解决以下问题：如何在弱网环境下保持安全可靠且低延迟地传输音视频流数据。
5.本技术实施例的一个方面提供了一种音视频数据的传输方法，应用于发送端，所述发送端与接收端之间建立基于quic协议的连接，所述基于quic协议的连接包含不可靠传输流和可靠传输流，所述的方法包括：
6.对待传输的音视频数据进行解封装，得到不可靠传输类型的数据帧和可靠传输类型的数据帧；其中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧；
7.封装所述不可靠传输类型的数据帧得到第一数据报文，以及封装所述可靠传输类型的数据帧得到第二数据报文；
8.通过所述不可靠传输流传输第一数据报文至所述接收端，以及，通过所述可靠传输流传输第二数据报文至所述接收端。
9.可选地，所述对待传输的音视频数据进行解封装，以得到不可靠传输类型的数据帧和可靠传输类型的数据帧，包括：
10.基于h264编码标准对所述待传输的音视频数据进行解封装，得到i帧数据、p帧数据和b帧数据；
11.确定所述b帧数据为不可靠传输类型的数据帧，并确定所述i帧数据和p帧数据为可靠传输类型的数据帧。
12.可选地，所述封装所述不可靠传输类型的数据帧得到第一数据报文，包括：
13.在所述不可靠传输类型的数据帧中封装基于预设协议的头部数据；其中，所述基
于预设协议的头部数据包含类型字段；
14.根据所述不可靠传输类型配置所述类型字段的值，得到第一数据报文。
15.可选地，所述封装所述可靠传输类型的数据帧得到第二数据报文，包括：
16.在所述可靠传输类型的数据帧中封装基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；
17.根据所述可靠传输类型配置所述类型字段的值，得到第二数据报文。
18.可选地，所述基于预设协议的头部数据还包含帧号字段、分片序号字段和分片总数字段。
19.可选地，所述封装所述不可靠传输类型的数据帧得到第一数据报文，还包括：
20.在所述不可靠传输类型的数据帧中封装基于udp协议的头部数据和基于quic协议的头部数据。
21.可选地，所述封装所述可靠传输类型的数据帧得到第二数据报文，还包括：
22.在所述可靠传输类型的数据帧中封装基于udp协议的头部数据和基于quic协议的头部数据。
23.本技术实施例的一个方面又提供了一种音视频数据的传输方法，应用于接收端，所述接收端与发送端之间建立基于quic协议的连接，所述基于quic协议的连接包含不可靠传输流和可靠传输流，所述的方法包括：
24.通过所述不可靠传输流接收所述发送端传输的第一数据报文，或通过所述可靠传输流接收所述发送端传输的第二数据报文；
25.解析所述第一数据报文或第二数据报文以得到基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；
26.在根据所述类型字段确定所述第一数据报文或第二数据报文为不可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则丢弃所述第一数据报文或第二数据报文。
27.可选地，所述方法还包括：
28.在根据所述类型字段确定所述第一数据报文或第二数据报文为可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则重传所述第一数据报文或第二数据报文。
29.可选地，所述方法还包括：
30.对所述第一数据报文和/或第二数据报文进行重组以得到音视频数据。
31.可选地，所述基于预设协议的头部数据还包含帧号字段；所述若所述第一数据报文或第二数据报文存在缺失，则丢弃所述第一数据报文或第二数据报文，包括：
32.根据所述帧号字段确定相同帧号的分片数据；
33.若所述相同帧号的分片数据存在缺失，则丢弃所述相同帧号的分片数据。
34.可选地，所述基于预设协议的头部数据还包含分片序号字段和分片总数字段；所述对所述第一数据报文和/或第二数据报文进行重组以得到音视频数据，包括：
35.根据所述分片序号字段和分片总数字段，对所述第一数据报文和/或第二数据报文进行重组以得到音视频数据。
36.本技术实施例的一个方面又提供了一种音视频数据的传输系统，包括发送端和接
收端，所述发送端与接收端之间建立基于quic协议的连接，所述基于quic协议的连接包含不可靠传输流和可靠传输流；其中，
37.所述发送端用于，对待传输的音视频数据进行解封装，得到不可靠传输类型的数据帧和可靠传输类型的数据帧；其中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧；封装所述不可靠传输类型的数据帧得到第一数据报文，以及封装所述可靠传输类型的数据帧得到第二数据报文；通过所述不可靠传输流传输第一数据报文至所述接收端，以及，通过所述可靠传输流传输第二数据报文至所述接收端；
38.所述接收端用于，通过所述不可靠传输流接收所述发送端传输的第一数据报文，或通过所述可靠传输流接收所述发送端传输的第二数据报文；解析所述第一数据报文或第二数据报文以得到基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；在根据所述类型字段确定所述第一数据报文或第二数据报文为不可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则丢弃所述第一数据报文或第二数据报文。
39.本技术实施例的一个方面又提供了一种计算机设备，所述计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述的音视频数据的传输方法的步骤。
40.本技术实施例的一个方面又提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序可被至少一个处理器所执行，以使所述至少一个处理器执行所述计算机程序时实现如上述的音视频数据的传输方法的步骤。
41.本技术实施例提供的音视频数据的传输方法、系统、设备及计算机可读存储介质，通过利用基于quic协议的传输流，传输不影响客户端播放质量的音视频流数据，例如，h264编码中b视频帧，这部分数据若出现丢包将不再重传，降低弱网环境下的重传率，然而与播放质量强相关的音视频数据依旧保证有序可靠传输，因此，可以在保证音视频质量的同时，适应不同弱网环境的传输需求，从而降低卡顿率，提升用户观看体验。
附图说明
42.图1示意性示出了根据本技术实施例的音视频数据的传输方法的应用环境图；
43.图2示意性示出了根据本技术实施例一的音视频数据的传输方法的流程图；
44.图3示意性示出了一种c/s软件架构下的一个基于quic协议的连接的示意图；
45.图4示意性示出了一种基于预设协议的头部数据的示意图；
46.图5示意性示出了一种数据报文的数据结构示意图；
47.图6示意性示出了根据本技术实施例二的音视频数据的传输方法的流程图；
48.图7示意性示出了根据本技术实施例三的音视频数据的传输系统的框图；
49.图8示意性示出了根据本技术实施例四的音视频数据的传输装置的框图；
50.图9示意性示出了根据本技术实施例五的音视频数据的传输装置的框图；及
51.图10示意性示出了根据本技术实施例六的适于实现音视频数据的传输方法的计算机设备的硬件架构示意图。
具体实施方式
52.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本技术，并不用于限定本技术。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都为本技术保护的范围。
53.需要说明的是，在本技术实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本技术要求的保护范围之内。
54.随着视频会议、视频直播的流行以及未来ar/vr业务的发展，实时视频传输服务被广泛使用。在此背景下，如何在弱网环境下，依旧保持安全可靠且低延迟地传输音视频流数据，满足人们随时随地观看视频的需求日益增加。在以往的网络传输架构中，由于tcp具有拥塞控制和流量控制的机制,大部分互联网业务的架构都使用tcp传输数据，通常采用tcp作为传输层，rtmp作为应用层协议，完成tcp+rtmp握手之后，有序可靠地传输音视频数据。然而随着人们对网络的实时性需求越来越大，tcp的握手时延高、队头阻塞等弊病造成的高时延和低效率愈发凸显，在弱网环境下，甚至可能导致视频无法播放。google公司提出了基于udp的应用层协议quic。quic协议不仅拥有拥塞控制和流量控制，而且具有0-rtt建连，多路复用，连接迁移等特性，支持不可靠传输功能，拥有比tcp更高的传输效率。
55.现有技术中，如果采用tcp+rtmp方案传输音视频流数据，在传输音视频数据之前必须得经过tcp的三次握手和rtmp的多次握手，这些握手的过程会大大增加网络的传输时延；如果客户端处于弱网环境下，会导致tcp丢包过多，甚至因多次重传数据失败而断开连接，如需继续接收音视频数据，需要重新发起tcp和rtmp握手，这将导致用户观看视频出现卡顿和黑屏等情况，大大地降低用户的观看体验。
56.目前，采用基于quic协议有序可靠地传输音视频流或者音视频帧的方案，虽然其能够使新的quic连接实现0-rtt建联，但是在弱网环境下，quic stream是可靠有序传输所有音视频数据，对于这些数据，一旦丢包都需要重传，而客户端处于弱网环境下时，过多的重传包将会继续恶化网络环境，影响用户的观看体验。
57.有鉴于此，本技术旨在提出一种音视频数据的传输方法，通过对待传输的音视频数据进行解封装，得到不可靠传输类型的数据帧和可靠传输类型的数据帧；其中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧；封装所述不可靠传输类型的数据帧得到第一数据报文，以及封装所述可靠传输类型的数据帧得到第二数据报文；通过基于quic协议连接的不可靠传输流传输第一数据报文至所述接收端，以及，通过可靠传输流传输第二数据报文至所述接收端。利用基于quic协议的不可靠传输流，传输不影响客户端播放质量的音视频流数据，例如，h264编码中b视频帧，这部分数据若出现丢包将不再重传，降低弱网环境下的重传率，然而与播放质量强相关的音视频数据依旧保证有序可靠传输，因此，可以在保证音视频质量的同时，适应不同弱网环境的传输需求，从而降低卡顿率，提升用户观看体验。
58.此外，本技术实施例基于quic作为传输协议，相较于tcp每次建连都需1.5-rtt，quic首次以1-rtt握手建连后，后续握手重连只需0-rtt；用自定义协议取代rtmp协议，可实现quic建联后直接发送音视频数据，省去了rtmp握手的时间，大大降低了首帧的延迟。即使客户端断开或者更换网络重连，quic的连接迁移、0-rtt特性使得网络无缝衔接发送数据，提升用户观看视频的流畅度体验。
59.本技术提供了多个实施例进一步介绍音视频数据的传输方案，具体参照下文。
60.在本技术的描述中，需要理解的是，步骤前的数字标号并不标识执行步骤的前后顺序，仅用于方便描述本技术及区别每一步骤，因此不能理解为对本技术的限制。
61.以下为本技术的术语解释：
62.弱网环境：指网络带宽较小或者网络信号强度较差的环境，例如：地下车库，高铁，偏远山区等场所。
63.quic:全称quick udp internet connection，早期是谷歌制定的一种基于udp的低时延的互联网传输层协议，目前ietf(internet engineering task force)已经正式颁布标准化版本rfc 9000。
64.rtmp：全称real time messaging protocol，一种设计用来进行实时数据通信的网络协议。
65.rtt：全称round trip time。代表网络数据往返时延。0-rtt代表在握手阶段即可发送应用数据。
66.音视频流：一个完整的音视频流，包括音频、视频和基础元信息，常见的视频文件如mp4、mov、flv、avi、rmvb等视频文件，就是一个容器的封装，里面包含了音频和视频两部分，并且都是通过一些特定的编码算法，进行编码压缩生成。
67.图1示意性示出了根据本技术实施例的环境应用示意图。如图1所示：
68.计算机设备10000可以通过网络20000连接客户端30000。
69.计算机设备10000可以提供服务，如进行网络调试，或返回音视频数据的传输结果数据给客户端30000等。
70.计算机设备10000可以位于诸如单个场所之类的数据中心，或者分布在不同的地理位置(例如，在多个场所)中。计算机设备10000可以经由一个或多个网络20000提供服务。网络20000包括各种网络设备，例如路由器，交换机，多路复用器，集线器，调制解调器，网桥，中继器，防火墙，代理设备和/或类似。网络20000可以包括物理链路，例如同轴电缆链路，双绞线电缆链路，光纤链路，其组合等。网络20000可以包括无线链路，诸如蜂窝链路，卫星链路，wi-fi链路等。
71.计算机设备10000可以由一个或多个计算节点实现。一个或多个计算节点可以包括虚拟化的计算实例。虚拟化的计算实例可以包括虚拟机，例如计算机系统，操作系统，服务器等的仿真。计算节点可以基于虚拟映像和/或定义用于仿真的特定软件(例如，操作系统，专用应用程序，服务器)的其他数据，由计算节点加载虚拟机。随着对不同类型的处理服务的需求改变，可以在一个或多个计算节点上加载和/或终止不同的虚拟机。可以实现管理程序来管理同一计算节点上不同虚拟机的使用。
72.客户端30000可以被配置为访问计算机设备10000的内容和服务。客户端30000可以包括任何类型的电子设备，诸如移动设备、平板设备、膝上型计算机、工作站、虚拟现实设
备，游戏设备、机顶盒、数字流媒体设备、车辆终端、智能电视、机顶盒等。
73.客户端30000可以将音视频数据的传输结果数据等输出(例如，显示、渲染、呈现)给用户。
74.以下将通过多个实施例介绍网络调试方案。该方案可以通过计算机设备10000实施。
75.实施例一
76.图2示意性示出了根据本技术实施例一的音视频数据的传输方法的流程图。所述的音视频数据的传输方法应用于发送端，所述发送端与接收端之间建立基于quic协议的连接，所述基于quic协议的连接包含不可靠传输流和可靠传输流，所述的方法包括步骤s202-s206，其中，
77.步骤s202，对待传输的音视频数据进行解封装，得到不可靠传输类型的数据帧和可靠传输类型的数据帧；其中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧；
78.本实施例的音视频数据的传输方案可以用于基于c/s软件架构下，不限于音视频流的封装格式，其中，发送端负责解封装并发送音视频数据，接收端负责接收并重新封装音视频数据。在具体实现时，发送端可以为server服务器端也可以为client客户端，同理，接收端可以为server端也可以为client端，本实施例对此不做限制。
79.在本实施例中，发送端在需要传输音视频流数据时，首先对待传输的音视频流数据进行解封装，并从解封装后的数据帧中确定不可靠传输类型的数据帧和可靠传输类型的数据帧。具体的用来解封装音视频流数据的协议可以是已公开的技术，本技术实施例对此不再赘述。
80.在本实施例中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧，可以通过不可靠的传输方式进行传输。可靠传输类型的数据帧指能够影响音视频的播放质量的数据帧，可以通过可靠的传输方式进行传输。
81.在本技术的一种优选实施例中，所述步骤s202可以包括如下步骤：
82.基于h264编码标准对所述待传输的音视频数据进行解封装，得到i帧数据、p帧数据和b帧数据；确定所述b帧数据为不可靠传输类型的数据帧，并确定所述i帧数据和p帧数据为可靠传输类型的数据帧。
83.具体的，通过从待传输的音视频数据中解封装得到视频帧数据，然后基于h264编码标准对视频帧数据进行解封装，得到i帧数据、p帧数据和b帧数据，确定b帧数据为不可靠传输类型的数据帧，并确定i帧数据和p帧数据为可靠传输类型的数据帧。在h264编码标准中一般分为i帧、p帧和b帧，其中，b帧可以进行帧间和帧内预测，会参考前面或者后面已编码的i帧和p帧，故b帧不作为其他参考帧，若被网络丢包后不会影响接收端其他音视频帧的编解码，因此，可以采用不可靠传输的方式传输b帧。而除b帧之外的数据可以采用可靠传输的方式传输。
84.步骤s204，封装所述不可靠传输类型的数据帧得到第一数据报文，以及封装所述可靠传输类型的数据帧得到第二数据报文；
85.在本实施例中，可以基于quic协议和预设协议来封装数据帧，即基于quic协议和预设协议封装不可靠传输类型的数据帧得到第一数据报文，以及基于quic协议和预设协议
封装可靠传输类型的数据帧得到第二数据报文，那么，生成的第一数据报文和第二数据报文支持quic协议和预设协议传输。其中，预设协议是自定义的协议，主要用于发送端和接受端之间识别数据报文的相关信息，包含报文类型、报文长度和是视频时间戳等信息，使得发送端和接受端之间无需多余的握手交互，就可以直接传输音视频数据报文。
86.步骤s206，通过所述不可靠传输流传输第一数据报文至所述接收端，以及，通过所述可靠传输流传输第二数据报文至所述接收端。
87.在本实施例中，可以基于quic协议和预设协议，通过不可靠传输流传输第一数据报文至接收端，以及，通过可靠传输流传输第二数据报文至接收端。由于第一数据报文通过不可靠传输流进行传输，若是在弱网环境下，第一数据报文发生丢包，则不需要重传；而第二数据报文通过可靠传输流进行传输，若是在弱网环境下，第二数据报文发生丢包，则需要重传以保证数据的质量。因此，可以在保证音视频质量的同时，适应不同弱网环境的传输需求，从而降低卡顿率，提升用户观看体验。
88.在一种示例中，如图3所示，假定server端为发送端，client为接收端，在server端和client端之间建立1个quic的connection，这个quic的connection包含两个stream，分别为不可靠传输流quic datagram和可靠传输流quic stream，其中，使用quic datagram传输第一数据报文，使用quic stream传输第二数据报文。
89.以下提供几个可选地实施例，以进行优化所述音视频数据的传输方法，具体如下：
90.在本技术的一种优选实施例中，所述封装所述不可靠传输类型的数据帧得到第一数据报文，包括：
91.在所述不可靠传输类型的数据帧中封装基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；根据所述不可靠传输类型配置所述类型字段的值，得到第一数据报文。
92.在本实施例中，基于预设协议的头部数据包含类型字段type，用于定义报文类型。对于不可靠传输类型的数据帧，在封装数据帧时，通过在数据帧中封装基于预设协议的头部数据；然后，根据不可靠传输类型配置类型字段的值，得到支持预设协议的第一数据报文。
93.在本技术的一种优选实施例中，所述封装所述可靠传输类型的数据帧得到第二数据报文，包括：
94.在所述可靠传输类型的数据帧中封装基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；根据所述可靠传输类型配置所述类型字段的值，得到第二数据报文。
95.在本实施例中，对于可靠传输类型的数据帧，在封装数据帧时，通过在数据帧中封装基于预设协议的头部数据；然后，根据可靠传输类型配置类型字段的值，得到支持预设协议的第二数据报文。
96.在本技术的一种优选实施例中，所述基于预设协议的头部数据还包含帧号字段、分片序号字段和分片总数字段。
97.在本实施例中，基于预设协议的头部数据还可以包含帧号字段、分片序号字段和分片总数字段。其中，帧号字段seq number用于指定报文对应的帧号，分片序号字段fragment number用于指定报文对应的分片序号，分片总数字段fragment sum用于指定数
header、基于quic协议的头部数据quic header、预设协议header和报文内容数据payload。其中，quic header符合rfc 9000标准，预设协议header部分可根据需求自行定义各字段，主要用于client和server两端识别payload报文类型，报文长度和音视频时间戳等信息，使得双端无需多余的握手交互，直接传输音视频数据信息；payload报文部分承载着发送方解封装后的元数据，音频帧和视频帧等类型的数据。
111.实施例二
112.图6示意性示出了根据本技术实施例二的音视频数据的传输方法的流程图。所述的音视频数据的传输方法应用于接收端，所述接收端与发送端之间建立基于quic协议的连接，所述基于quic协议的连接包含不可靠传输流和可靠传输流，所述的方法包括步骤s602-s606，其中，
113.步骤s602，通过所述不可靠传输流接收所述发送端传输的第一数据报文，或通过所述可靠传输流接收所述发送端传输的第二数据报文；
114.在本实施例中，在发送端和接收端之间建立1个基于quic协议的连接connection，该基于quic协议的连接包含不可靠传输流和可靠传输流，接收端可以通过不可靠传输流接收发送端传输的第一数据报文，或通过可靠传输流接收发送端传输的第二数据报文。
115.步骤s604，解析所述第一数据报文或第二数据报文以得到基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；
116.步骤s606，在根据所述类型字段确定所述第一数据报文或第二数据报文为不可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则丢弃所述第一数据报文或第二数据报文。
117.其中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧。在本实施例中，接收端通过对接收到的第一数据报文或第二数据报文进行解析以得到基于预设协议的头部数据，该基于预设协议的头部数据包含类型字段。通过根据类型字段判断第一数据报文或第二数据报文是否为不可靠传输类型，在确定第一数据报文或第二数据报文是否为不可靠传输类型的情况下，第一数据报文或第二数据报文存在缺失，则丢弃该第一数据报文或第二数据报文，即对于不可靠传输类型的数据，不需要重传，以避免在弱网的情况下，重传数增加网络的负担。
118.以下提供几个可选地实施例，以进行优化所述音视频数据的传输方法，具体如下：
119.在本技术的一种优选实施例中，所述的方法还可以包括如下步骤：
120.在根据所述类型字段确定所述第一数据报文或第二数据报文为可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则重传所述第一数据报文或第二数据报文。
121.在本实施例中，在根据类型字段确定第一数据报文或第二数据报文为可靠传输类型的情况下，判断第一数据报文或第二数据报文存在缺失，若是第一数据报文或第二数据报文存在缺失，则重传该第一数据报文或第二数据报文，即对于可靠传输类型的数据报文，若是发生数据丢包，需要重传，以保证数据的质量。
122.在本技术的一种优选实施例中，所述方法还包括：
123.对所述第一数据报文和/或第二数据报文进行重组以得到音视频数据。
124.在本实施例中，在接收完成数据报文之后，通过对第一数据报文或第二数据报文
进行重组以得到音视频数据。
125.在本技术的一种优选实施例中，所述基于预设协议的头部数据还包含帧号字段；所述若所述第一数据报文或第二数据报文存在缺失，则丢弃所述第一数据报文或第二数据报文，包括：
126.根据所述帧号字段确定相同帧号的分片数据；若所述相同帧号的分片数据存在缺失，则丢弃所述相同帧号的分片数据。
127.在本实施例中，基于预设协议的头部数据还包含帧号字段，在需要判断报文是否存在丢包时，可以通过根据帧号字段确定相同帧号的分片数据；然后判断这些相同帧号的分片数据是否存在缺失，对于不可靠传输类型的数据，若相同帧号的分片数据存在缺失，则直接丢弃这些相同帧号的分片数据。
128.在本技术的一种优选实施例中，所述基于预设协议的头部数据还包含分片序号字段和分片总数字段；所述对所述第一数据报文或第二数据报文进行重组以得到音视频数据，包括：
129.根据所述分片序号字段和分片总数字段，对所述第一数据报文或第二数据报文进行重组以得到音视频数据。
130.在本实施例中，基于预设协议的头部数据还可以包含分片序号字段和分片总数字段，在需要重组数据时，可以根据分片序号字段和分片总数字段，对第一数据报文或第二数据报文进行重组以得到音视频数据。
131.此外，基于预设协议的头部数据还可以包含可变长度的格式字段fmt，用于指示可变长度字段对应的字节数；可变长度字段length，用于描述报文的长度；时间戳字段timestamp，用于描述报文在音视频流数据中对应的时间戳。以及，保留字段resvd，l字段占，s字段占1bit，d-fmt字段等。
132.实施例三
133.图7示意性示出了根据本技术实施例三的音视频数据的传输系统的框图，该音视频数据的传输系统可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本技术实施例。本技术实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本技术实施例中各程序模块的功能。
134.如图7所示，该音视频数据的传输系统700可以包括发送端710和接收端720，所述发送端与接收端之间建立基于quic协议的连接，所述基于quic协议的连接包含不可靠传输流和可靠传输流；其中，
135.所述发送端710用于，对待传输的音视频数据进行解封装，得到不可靠传输类型的数据帧和可靠传输类型的数据帧；其中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧；封装所述不可靠传输类型的数据帧得到第一数据报文，以及封装所述可靠传输类型的数据帧得到第二数据报文；通过所述不可靠传输流传输第一数据报文至所述接收端，以及，通过所述可靠传输流传输第二数据报文至所述接收端；
136.所述接收端720用于，通过所述不可靠传输流接收所述发送端传输的第一数据报文，或通过所述可靠传输流接收所述发送端传输的第二数据报文；解析所述第一数据报文或第二数据报文以得到基于预设协议的头部数据；其中，所述基于预设协议的头部数据包
含类型字段；在根据所述类型字段确定所述第一数据报文或第二数据报文为不可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则丢弃所述第一数据报文或第二数据报文。
137.实施例四
138.图8示意性示出了根据本技术实施例四的音视频数据的传输装置的框图，该音视频数据的传输装置可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本技术实施例。本技术实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本技术实施例中各程序模块的功能。
139.如图8所示，该音视频数据的传输装置800可以包括如下模块：
140.数据解封装模块810，用于对待传输的音视频数据进行解封装，得到不可靠传输类型的数据帧和可靠传输类型的数据帧；其中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧；
141.报文封装模块820，用于封装所述不可靠传输类型的数据帧得到第一数据报文，以及封装所述可靠传输类型的数据帧得到第二数据报文；
142.报文传输模块830，用于通过所述不可靠传输流传输第一数据报文至所述接收端，以及，通过所述可靠传输流传输第二数据报文至所述接收端。
143.在本技术的一种优选实施例中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧。
144.在本技术的一种优选实施例中，所述数据解封装模块810，包括：
145.数据解封装子模块，用于基于h264编码标准对所述待传输的音视频数据进行解封装，得到i帧数据、p帧数据和b帧数据；
146.数据帧类型确定子模块，用于确定所述b帧数据为不可靠传输类型的数据帧，并确定所述i帧数据和p帧数据为可靠传输类型的数据帧。
147.在本技术的一种优选实施例中，所述报文封装模块820，包括：
148.第一报文封装子模块，用于在所述不可靠传输类型的数据帧中封装基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；根据所述不可靠传输类型配置所述类型字段的值，得到第一数据报文。
149.在本技术的一种优选实施例中，所述报文封装模块820，包括：
150.第二报文封装子模块，用于在所述可靠传输类型的数据帧中封装基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；根据所述可靠传输类型配置所述类型字段的值，得到第二数据报文。
151.在本技术的一种优选实施例中，所述基于预设协议的头部数据还包含帧号字段、分片序号字段和分片总数字段。
152.在本技术的一种优选实施例中，所述报文封装模块820，还包括：
153.第一头部封装子模块，用于在所述不可靠传输类型的数据帧中封装基于udp协议的头部数据和基于quic协议的头部数据。
154.在本技术的一种优选实施例中，所述报文封装模块820，还包括：
155.第二头部封装子模块，用于在所述可靠传输类型的数据帧中封装基于udp协议的
头部数据和基于quic协议的头部数据。
156.实施例五
157.图9示意性示出了根据本技术实施例五的音视频数据的传输装置的框图，该音视频数据的传输装置可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本技术实施例。本技术实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本技术实施例中各程序模块的功能。
158.如图9所示，该音视频数据的传输装置900可以包括如下模块：
159.数据接收模块910，用于通过所述不可靠传输流接收所述发送端传输的第一数据报文，或通过所述可靠传输流接收所述发送端传输的第二数据报文；
160.数据解析模块920，用于解析所述第一数据报文或第二数据报文以得到基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；
161.数据丢弃模块930，用于在根据所述类型字段确定所述第一数据报文或第二数据报文为不可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则丢弃所述第一数据报文或第二数据报文。
162.在本技术的一种优选实施例中，所述装置还包括：
163.数据重传模块，用于在根据所述类型字段确定所述第一数据报文或第二数据报文为可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则重传所述第一数据报文或第二数据报文。
164.在本技术的一种优选实施例中，所述装置还包括：
165.数据重组模块，用于对所述第一数据报文和/或第二数据报文进行重组以得到音视频数据。
166.在本技术的一种优选实施例中，所述基于预设协议的头部数据还包含帧号字段；所述数据丢弃模块930，包括：
167.数据丢弃子模块，用于根据所述帧号字段确定相同帧号的分片数据；若所述相同帧号的分片数据存在缺失，则丢弃所述相同帧号的分片数据。
168.在本技术的一种优选实施例中，所述基于预设协议的头部数据还包含分片序号字段和分片总数字段；所述数据重组模块，包括：
169.数据重组子模块，用于根据所述分片序号字段和分片总数字段，对所述第一数据报文和/或第二数据报文进行重组以得到音视频数据。
170.实施例六
171.图10示意性示出了根据本技术实施例六的适于实现音视频数据的传输方法的计算机设备10000的硬件架构示意图。本实施例中，计算机设备10000是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是智能手机、平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括fen独立的服务器，或者多个服务器所组成的服务器集群)等。如图10所示，计算机设备10000至少包括但不限于：可通过系统总线相互通信链接存储器10010、处理器10020、网络接口10030。其中：
172.存储器10010至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、
硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器10010可以是计算机设备10000的内部存储模块，例如该计算机设备10000的硬盘或内存。在另一些实施例中，存储器10010也可以是计算机设备10000的外部存储设备，例如该计算机设备10000上配备的插接式硬盘，智能存储卡(smart media card，简称为smc)，安全数字(secure digital，简称为sd)卡，闪存卡(flash card)等。当然，存储器10010还可以既包括计算机设备10000的内部存储模块也包括其外部存储设备。本实施例中，存储器10010通常用于存储安装于计算机设备10000的操作系统和各类应用软件，例如音视频数据的传输方法的程序代码等。此外，存储器10010还可以用于暂时地存储已经输出或者将要输出的各类数据。
173.处理器10020在一些实施例中可以是中央处理器(central processing unit，简称为cpu)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器10020通常用于控制计算机设备10000的总体操作，例如执行与计算机设备10000进行数据交互或者通信相关的控制和处理等。本实施例中，处理器10020用于运行存储器10010中存储的程序代码或者处理数据。
174.网络接口10030可包括无线网络接口或有线网络接口，该网络接口10030通常用于在计算机设备10000与其他计算机设备之间建立通信链接。例如，网络接口10030用于通过网络将计算机设备10000与外部终端相连，在计算机设备10000与外部终端之间的建立数据传输通道和通信链接等。网络可以是企业内部网(intranet)、互联网(internet)、全球移动通讯系统(global system of mobile communication，简称为gsm)、宽带码分多址(wideband code division multiple access，简称为wcdma)、4g网络、5g网络、蓝牙(bluetooth)、wi-fi等无线或有线网络。
175.需要指出的是，图10仅示出了具有部件10010-10030的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。
176.在本实施例中，存储于存储器10010中的音视频数据的传输方法还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器10020)所执行，以完成本技术实施例。
177.实施例七
178.本技术实施例还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现实施例中的音视频数据的传输方法的步骤。
179.本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(smart media card，简称为smc)，安全数字(secure digital，简称为sd)卡，闪存卡(flash card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例
如实施例中音视频数据的传输方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。
180.显然，本领域的技术人员应该明白，上述的本技术实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本技术实施例不限制于任何特定的硬件和软件结合。
181.以上仅为本技术的优选实施例，并非因此限制本技术的专利范围，凡是利用本技术说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本技术的专利保护范围内。

技术特征：
1.一种音视频数据的传输方法，其特征在于，应用于发送端，所述发送端与接收端之间建立基于quic协议的连接，所述基于quic协议的连接包含不可靠传输流和可靠传输流，所述的方法包括：对待传输的音视频数据进行解封装，得到不可靠传输类型的数据帧和可靠传输类型的数据帧；其中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧；封装所述不可靠传输类型的数据帧得到第一数据报文，以及封装所述可靠传输类型的数据帧得到第二数据报文；通过所述不可靠传输流传输第一数据报文至所述接收端，以及，通过所述可靠传输流传输第二数据报文至所述接收端。2.根据权利要求1所述的音视频数据的传输方法，其特征在于，所述对待传输的音视频数据进行解封装，以得到不可靠传输类型的数据帧和可靠传输类型的数据帧，包括：基于h264编码标准对所述待传输的音视频数据进行解封装，得到i帧数据、p帧数据和b帧数据；确定所述b帧数据为不可靠传输类型的数据帧，并确定所述i帧数据和p帧数据为可靠传输类型的数据帧。3.根据权利要求1所述的音视频数据的传输方法，其特征在于，所述封装所述不可靠传输类型的数据帧得到第一数据报文，包括：在所述不可靠传输类型的数据帧中封装基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；根据所述不可靠传输类型配置所述类型字段的值，得到第一数据报文。4.根据权利要求1所述的音视频数据的传输方法，其特征在于，所述封装所述可靠传输类型的数据帧得到第二数据报文，包括：在所述可靠传输类型的数据帧中封装基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；根据所述可靠传输类型配置所述类型字段的值，得到第二数据报文。5.根据权利要求3或4所述的音视频数据的传输方法，其特征在于，所述基于预设协议的头部数据还包含帧号字段、分片序号字段和分片总数字段。6.根据权利要求3所述的音视频数据的传输方法，其特征在于，所述封装所述不可靠传输类型的数据帧得到第一数据报文，还包括：在所述不可靠传输类型的数据帧中封装基于udp协议的头部数据和基于quic协议的头部数据。7.根据权利要求4所述的音视频数据的传输方法，其特征在于，所述封装所述可靠传输类型的数据帧得到第二数据报文，还包括：在所述可靠传输类型的数据帧中封装基于udp协议的头部数据和基于quic协议的头部数据。8.一种音视频数据的传输方法，其特征在于，应用于接收端，所述接收端与发送端之间建立基于quic协议的连接，所述基于quic协议的连接包含不可靠传输流和可靠传输流，所述的方法包括：通过所述不可靠传输流接收所述发送端传输的第一数据报文，或通过所述可靠传输流
接收所述发送端传输的第二数据报文；解析所述第一数据报文或第二数据报文以得到基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；在根据所述类型字段确定所述第一数据报文或第二数据报文为不可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则丢弃所述第一数据报文或第二数据报文。9.根据权利要求8所述的音视频数据的传输方法，其特征在于，所述方法还包括：在根据所述类型字段确定所述第一数据报文或第二数据报文为可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则重传所述第一数据报文或第二数据报文。10.根据权利要求9所述的音视频数据的传输方法，其特征在于，所述方法还包括：对所述第一数据报文和/或第二数据报文进行重组以得到音视频数据。11.根据权利要求8所述的音视频数据的传输方法，其特征在于，所述基于预设协议的头部数据还包含帧号字段；所述若所述第一数据报文或第二数据报文存在缺失，则丢弃所述第一数据报文或第二数据报文，包括：根据所述帧号字段确定相同帧号的分片数据；若所述相同帧号的分片数据存在缺失，则丢弃所述相同帧号的分片数据。12.根据权利要求10所述的音视频数据的传输方法，其特征在于，所述基于预设协议的头部数据还包含分片序号字段和分片总数字段；所述对所述第一数据报文和/或第二数据报文进行重组以得到音视频数据，包括：根据所述分片序号字段和分片总数字段，对所述第一数据报文和/或第二数据报文进行重组以得到音视频数据。13.一种音视频数据的传输系统，其特征在于，包括发送端和接收端，所述发送端与接收端之间建立基于quic协议的连接，所述基于quic协议的连接包含不可靠传输流和可靠传输流；其中，所述发送端用于，对待传输的音视频数据进行解封装，得到不可靠传输类型的数据帧和可靠传输类型的数据帧；其中，所述不可靠传输类型的数据帧指不影响音视频的播放质量的数据帧；封装所述不可靠传输类型的数据帧得到第一数据报文，以及封装所述可靠传输类型的数据帧得到第二数据报文；通过所述不可靠传输流传输第一数据报文至所述接收端，以及，通过所述可靠传输流传输第二数据报文至所述接收端；所述接收端用于，通过所述不可靠传输流接收所述发送端传输的第一数据报文，或通过所述可靠传输流接收所述发送端传输的第二数据报文；解析所述第一数据报文或第二数据报文以得到基于预设协议的头部数据；其中，所述基于预设协议的头部数据包含类型字段；在根据所述类型字段确定所述第一数据报文或第二数据报文为不可靠传输类型的情况下，若所述第一数据报文或第二数据报文存在缺失，则丢弃所述第一数据报文或第二数据报文。14.一种计算机设备，所述计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时用于实现权利要求1至7或8至12中任意一项所述的音视频数据的传输方法的步骤。
15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序可被至少一个处理器所执行，以使所述至少一个处理器执行权利要求1至7或8至12中任意一项所述的音视频数据的传输方法的步骤。

技术总结
本申请实施例提供了一种音视频数据的传输方法和系统，包括：对待传输的音视频数据进行解封装，得到不可靠传输类型的数据帧和可靠传输类型的数据帧；封装所述不可靠传输类型的数据帧得到第一数据报文，以及封装所述可靠传输类型的数据帧得到第二数据报文；通过基于QUIC协议连接的不可靠传输流传输第一数据报文至所述接收端，以及，通过可靠传输流传输第二数据报文至所述接收端。从而利用基于QUIC协议的传输流，传输不影响客户端播放质量的音视频流数据，这部分数据若出现丢包将不再重传，降低弱网环境下的重传率，然而与播放质量强相关的数据依旧保证有序可靠传输，因此，可以在保证音视频质量的同时，适应弱网环境的传输需求，从而降低视频卡顿率。从而降低视频卡顿率。从而降低视频卡顿率。


技术研发人员：吴义 刘宏强 陈建
受保护的技术使用者：上海哔哩哔哩科技有限公司
技术研发日：2023.05.18
技术公布日：2023/8/2