CN114448588A - 音频传输方法、装置、电子设备及计算机可读存储介质 - Google Patents

音频传输方法、装置、电子设备及计算机可读存储介质 Download PDF

Info

Publication number
CN114448588A
CN114448588A CN202210044235.5A CN202210044235A CN114448588A CN 114448588 A CN114448588 A CN 114448588A CN 202210044235 A CN202210044235 A CN 202210044235A CN 114448588 A CN114448588 A CN 114448588A
Authority
CN
China
Prior art keywords
time period
terminal
next time
red
redundancy
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
Application number
CN202210044235.5A
Other languages
English (en)
Other versions
CN114448588B (zh
Inventor
崔承宗
阮良
陈功
陈丽
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Netease Zhiqi Technology Co Ltd
Original Assignee
Hangzhou Netease Zhiqi Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hangzhou Netease Zhiqi Technology Co Ltd filed Critical Hangzhou Netease Zhiqi Technology Co Ltd
Priority to CN202210044235.5A priority Critical patent/CN114448588B/zh
Publication of CN114448588A publication Critical patent/CN114448588A/zh
Application granted granted Critical
Publication of CN114448588B publication Critical patent/CN114448588B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1864—ARQ related signaling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Abstract

本公开的实施方式提供了一种音频传输方法、装置、电子设备及计算机可读存储介质。该方法可以应用于终端，包括：获得该终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；确定下一时段的初始RED冗余度；基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度；按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给所述服务端。

Description

音频传输方法、装置、电子设备及计算机可读存储介质
技术领域
本公开的实施方式涉及通信技术领域，更具体地，本公开的实施方式涉及一种音频传输方法、装置、电子设备及计算机可读存储介质。
背景技术
本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
随着VoIP(Voice over Internet Protocol)技术的不断发展，终端之间可以经由网际协议(IP)来达成语音通话与多媒体会议，也就是可以基于互联网进行音视频数据的传输。
由于互联网是不可靠的传输网络，因此在终端之间基于互联网进行音视频数据的传输过程中，可能会出现数据包丢失的问题，进而导致用户的音视频通话体验下降。为了解决音频传输过程中出现的数据包丢失问题，可以针对音频数据采用RED(Redundant AudioData，冗余音频数据)冗余、ARQ(Automatic Repeat-reQuest，自动重传请求)等技术手段。
在多人音视频通话的场景中，可以采用基于SFU(Selective Forwarding Unit，选择性转发单元)的系统架构。所述基于SFU的系统架构，可以由一个服务端和多个终端组成；其中，所述服务端在接收到多个终端所发送的若干路音频流之后，通常可以进行选路处理，也即：可以从接收到的若干路音频流中，选中能量最高的几路音频流，并可以只将被选中的这几路音频流转发给其他终端，而无需转发未被选中的其他音频流。
发明内容
在本公开实施方式的第一方面中，提供了一种音频传输方法，应用于终端，包括：
获得该终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
确定下一时段的初始RED冗余度；其中，RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值；
基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度；
按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给所述服务端。
在本公开实施方式的第二方面中，提供了另一种音频传输方法，应用于服务端，包括：
为终端提供该终端在当前时段的选路概率值，以使所述终端基于所述当前时段的选路概率值对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码；其中，所述选路概率值，用于表征在相应时段，所述服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值；
接收所述终端发送的冗余编码后的音频流。
在本公开实施方式的第三方面中，提供了另一种音频传输方法，应用于终端，包括：
获得该终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
确定下一时段的初始NACK响应频率；
基于所述当前时段的选路概率值，对所述下一时段的初始NACK响应频率进行自适应调整，得到下一时段的自适应NACK响应频率；
按照所述下一时段的自适应NACK响应频率，在下一时段中响应于接收到所述服务端发送的NACK请求，向所述服务端重新发送音频流。
在本公开实施方式的第四方面中，提供了另一种音频传输方法，应用于服务端，包括：
获得终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，所述服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
确定下一时段的初始NACK请求频率和/或下一时段的初始NACK最大请求次数；
基于该终端在当前时段的选路概率值，对所述下一时段的初始NACK请求频率和/或所述下一时段的初始NACK最大请求次数进行自适应调整，以得到下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数；
根据所述下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数，向所述终端发送NACK请求。
在本公开实施方式的第五方面中，提供了一种音频传输装置，应用于终端，包括：
获得模块，用于获得该终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
确定模块，用于确定下一时段的初始RED冗余度；其中，RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值；
调整模块，用于基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度；
编码模块，用于按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码；
发送模块，用于将冗余编码后的音频流发送给所述服务端。
在本公开实施方式的第六方面中，提供了另一种音频传输装置，应用于服务端，包括：
提供模块，用于为终端提供该终端在当前时段的选路概率值，以使所述终端基于所述当前时段的选路概率值对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码；其中，所述选路概率值，用于表征在相应时段，所述服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值；
接收模块，用于接收所述终端发送的冗余编码后的音频流。
在本公开实施方式的第七方面中，提供了一种电子设备，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行任一所述音频传输方法。
在本公开实施方式的第八方面中，提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现任一所述音频传输方法中的步骤。
本公开以上的实施方式，至少具有如下的有益效果：
在本公开实施方式的第一方面和第二方面中，由于终端在当前时段所发送的音频流未被服务端选中时，该终端在当前时段的选路概率值会减少，因此该终端可以基于该终端在当前时段的选路概率值，对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并且可以按照所述下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给服务端。从而可以减少该终端发送给所述服务端的冗余编码后的音频流的数据量，进而可以减少终端基于RED冗余操作抗丢包的性能开销，减少传输冗余音频数据所占用的上行带宽，缓解网络堵塞的风险。
在本公开实施方式的第三方面中，由于终端在当前时段所发送的音频流未被服务端选中时，该终端在当前时段的选路概率值会减少，因此该终端可以基于该终端在当前时段的选路概率值，对下一时段的初始NACK响应频率进行自适应调整，以得到下一时段的自适应NACK响应频率，并且可以按照所述下一时段的自适应NACK响应频率，在下一时段中响应于接收到所述服务端发送的NACK请求，向所述服务端重新发送所述冗余编码后的音频流。从而可以减少该终端向所述服务端重传音频流的数据量，进而可以减少该终端基于ARQ处理抗丢包的性能开销，减少重传音频流所占用的上行带宽，缓解网络堵塞的风险。
在本公开实施方式的第四方面中，由于终端在当前时段所发送的音频流未被服务端选中时，该终端在当前时段的选路概率值会减少，因此服务端可以基于该终端在当前时段的选路概率值，对下一时段的初始NACK请求频率和/或初始NACK最大请求次数进行自适应调整，以得到下一时段的自适应NACK请求频率和/或自适应NACK最大请求次数，并且可以按照所述下一时段的自适应NACK请求频率和/或自适应NACK最大请求次数，向该终端发送NACK请求。从而可以减少服务端向该终端发送NACK请求的次数，进而可以减少该终端基于ARQ处理抗丢包的性能开销，减少重传音频流所占用的上行带宽，缓解网络堵塞的风险。
附图说明
通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：
图1是一示例性实施例提供的一种冗余编码后的音频数据的示意图；
图2是一示例性实施例提供的一种音频传输方法的系统架构示意图；
图3是一示例性实施例提供的一种音频传输方法的流程图；
图4是一示例性实施例提供的另一种音频传输方法的流程图；
图5是一示例性实施例提供的另一种音频传输方法的流程图；
图6是一示例性实施例提供的另一种音频传输方法的流程图；
图7是一示例性实施例提供的一种音频传输装置的框图；
图8是一示例性实施例提供的另一种音频传输装置的框图；
图9是一示例性实施例提供的另一种音频传输装置的框图；
图10是一示例性实施例提供的另一种音频传输装置的框图；
图11是一示例性实施例提供的一种音频传输方法对应的可读存储介质的示意图；
图12是一示例性实施例提供的一种能够实现上述方法的电子设备的示意图。
在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机可读存储介质。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
根据本公开的实施方式，提出了一种音频传输方法、装置、电子设备及计算机可读存储介质。
在本文中，需要理解的是，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。并且，本公开所涉及的数据可以为经用户授权或者经过各方充分授权的数据。
下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。
应用场景总览
随着VoIP(Voice over Internet Protocol)技术的不断发展，终端之间可以经由网际协议(IP)来达成语音通话与多媒体会议，也就是可以基于互联网进行音视频数据的传输。由于互联网是不可靠的传输网络，因此在终端之间基于互联网进行音视频数据的传输过程中，可能会出现数据包丢失的问题，进而导致用户的音视频通话体验下降。
为了解决音频传输过程中出现的数据包丢失问题，可以采用RED(RedundantAudio Data，冗余音频数据)冗余、ARQ(Automatic Repeat-reQuest，自动重传请求)技术等抗丢包手段中的一种或多种。
其中，所述RED冗余，标准格式定义于IETF(The Internet Engineering TaskForce)制定的RFC 2198协议。具体地，发送端可以针对音频数据进行基于RED协议的冗余编码，以得到冗余编码后的音频数据，所述冗余编码后的音频数据中可以包括原音频数据和冗余音频数据，发送端可以将所述冗余编码后的音频数据发送给接收端，以使接收端可以获得所述原音频数据和冗余音频数据，并且在所述接收端确定接收到的原音频数据出错时，可以利用接收到的冗余音频数据来恢复丢失的数据包。
例如，请参见图1，图1是一示例性实施例提供的一种冗余编码后的音频数据的示意图。如图1所示，99号包、100号包可以分别为发送端在上一时刻、当前时刻向接收端发送的原音频数据；冗余编码后的音频数据110，可以是所述发送端针对上一时刻待发送的原音频数据(99号包)进行基于RED协议的冗余编码而得到的；冗余编码后的音频数据120，可以是所述发送端针对当前时刻待发送的原音频数据(100号包)进行基于RED协议的冗余编码而得到的；96号包、97号包、98号包可以为冗余编码后的音频数据中包括的冗余音频数据。在接收到所述发送端发送的冗余编码后的音频数据110、120之后，所述接收端可以对其进行拆分、去重、排序等处理。可见，由于所述发送端可以将同一原音频数据包括在不同的冗余编码后的音频数据中发送给所述接收端，因此在出现丢包现象(如冗余编码后的音频数据110丢失)时，接收端可以根据接收到的其他冗余编码后的音频数据(如冗余编码后的音频数据120)中包括的冗余音频数据来恢复丢失的数据包，实现抗丢包的目的。
需要说明的是，如图1所示的96号包、97号包、98号包可以分别为所述发送端在历史时刻向所述接收端发送过的原音频数据；关于如图1所示的冗余编码后的音频数据110中包括的冗余音频数据可以为96号包、97号包、98号包，仅仅是一种示例性的描述，并不代表对本公开做出特殊限制；例如，所述如图1所示的冗余编码后的音频数据110中包括的冗余音频数据，也可以为所述发送端在其他的历史时刻向所述接收端发送过的原音频数据。
其中，所述ARQ技术，是OSI(Open System Interconnection)模型中数据链路层的错误纠正协议之一。具体地，在接收到发送端发送的原始数据包之后，接收端可以根据丢包检测结果向发送端发送NACK请求，以使发送端可以响应于所述NACK请求，向接收端重新发送出错的数据包；进一步地，接收端可以根据接收到的重新发送的数据包来恢复之前出错的数据包。
在多人音视频通话的场景中，可以采用基于SFU(Selective Forwarding Unit，选择性转发单元)的系统架构。所述基于SFU的系统架构，可以由一个服务端和多个终端组成；其中，所述终端可以采集用户的声音信息，以生成相应的音频流，并可以将所述音频流发送给所述服务端；所述服务端在接收到各个终端发送的音频流之后，可以直接将接收到的音频流转发给其他终端，不会对接收到的音频流进行混音处理，也即所述服务端不会对接收到的音频流进行解包、解码、混合叠加声音信号等处理。
在实际应用中，上述多人音视频通话的场景，具体可以包括但不限于：办公、教育、娱乐等场景中的多人音视频通话。例如，多人线上会议、多人在线课堂、多人在线K歌、多人游戏组队语音等，在此不再进行穷举。
在多人音视频通话的场景中，由于人耳对同一时间来自不同声源的混合声音信号的识别能力有限，因此所述服务端在接收到多个终端所发送的若干路音频流之后，可以进行选路处理，也即：从接收到的若干路音频流中，可以选中能量最高的几路音频流，并可以只将被选中的这几路音频流转发给其他终端，而无需转发未被选中的其他音频流。
例如，请参见图2，图2是一示例性实施例提供的一种音频传输方法的系统架构示意图。如图2所示的系统架构200，可以由服务端210、以及终端220、230、240、250、260组成。终端220、230、240、250、260，可以分别向服务端210发送音频流A、B、C、D、E；服务端210在接收到所述音频流A、B、C、D、E之后，可以从接收到的5路音频流中，选中能量最高的3路音频流(如：选中了音频流A、C、E)，并可以只将被选中的3路音频流转发给其他终端，而无需转发未被选中的音频流(如：未被选中的音频流B、D)；进一步地，各个终端在接收到被选中的音频流之后，可以对所述被选中的音频流进行解包、解码、混音等处理。需要说明的是，在图2中仅仅示例性的示出了5个终端，并不代表对本公开做出限制；在实际应用中可以有任意数量的终端，也即，可以支持任意数量的用户通过各自对应的终端参与多人音视频通话。
在以上示出的应用场景中，采用RED冗余来解决音频传输过程中出现的数据包丢失问题时，通常每个终端都可以对音频流进行RED冗余操作；然而，由于所述未被服务端选中的音频流并不会被所述服务端转发至其他终端，也就无法最终参与到音频通话中，因此对于所发送的音频流未被服务端选中的那部分终端而言，该终端针对音频流的RED冗余操作实际上并不会发挥作用。类似地，采用ARQ技术来解决音频传输过程中出现的数据包丢失问题时，通常每个终端都可以对音频流进行ARQ处理，也即响应于服务端发起的NACK请求，重传出错的数据包；然而，基于相似的原因，对于所发送的音频流未被服务端选中的那部分终端而言，该终端针对音频流的ARQ处理实际上并不会发挥作用。
由此可见，若每个终端都对音频流进行同等的RED冗余操作或同等的ARQ处理，会导致终端性能开销浪费、上行带宽浪费等问题，甚至可能造成网络拥堵。
需要注意的是，上述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。
发明概述
有鉴于此，本说明书提供一种每个终端可以基于自身已发送的音频流被服务端选中的概率，对该终端的初始RED冗余度进行自适应调整，进而不同的终端可以按照不同的自适应RED冗余度，对待发送音频流进行基于RED协议的冗余编码的技术方案。
本说明书的核心构思在于：
终端可以获得该终端在当前时段的选路概率值，其中，所述选路概率值，可以用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；进一步地，该终端可以确定下一时段的初始RED冗余度，并基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度；进一步地，该终端可以按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给所述服务端。
通过这种方式，一方面，终端可以基于自身在当前时段的选路概率值，对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并且该终端可以按照所述下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给服务端。由于终端在当前时段所发送的音频流未被服务端选中时，该终端在当前时段的选路概率值会减少，进而该终端在下一时段的RED冗余度会降低(也即下一时刻的自适应RED冗余度小于下一时刻的初始RED冗余度)，因此按照降低后的RED冗余度，对下一时刻的待发送音频流进行基于RED协议的冗余编码，得到的冗余编码后的音频流的数据量会减少，从而可以减少终端基于RED冗余抗丢包的性能开销，减少传输冗余音频数据所占用的上行带宽，缓解网络堵塞的风险。
另一方面，从系统整体来看，不同的终端在同一时刻的选路概率值可能存在差异，通过每个终端基于自身的选路概率值，对该终端的RED冗余度进行自适应调整，可以实现不同的终端在同一时刻的RED冗余度也存在差异(也即不同的终端在同一时刻的自适应RED冗余度不同)，从而在每个终端都可以保证针对音频数据的抗丢包能力的同时，能够优化音频传输过程中的系统整体性能。
另外，基于上述核心构思，本说明书还提供一种每个终端可以基于自身已发送的音频流被服务端选中的概率，对该终端的初始NACK响应频率进行自适应调整，进而不同的终端可以按照不同的自适应NACK响应频率，向所述服务端重传音频流的技术方案。
以及，基于上述核心构思，本说明书还提供一种服务端可以基于每个终端已发送的音频流被选中的概率，对NACK请求频率和/或NACK最大请求次数进行自适应调整，进而可以按照不同的NACK请求频率和/或NACK最大请求次数，向不同的终端发送NACK请求的技术方案。
示例性方法
下面将结合如图2所示的系统架构示意图，通过具体的实施例对本说明书的技术构思进行详细描述。
在本公开的实施方式中，所述终端可以为用户使用的电子设备。所述终端具体可以包括但不限于智能手机、台式计算机、平板电脑、笔记本电脑、电子书阅读器、智能手表、智能手环等具有一定计算能力的电子设备，并且该电子设备可以运行有即时通讯类、社交类、游戏类、教育类等类别的软件或网站，可以应用于多人音视频通话的场景。
所述服务端可以包括一个服务器、多个服务器形成的服务器集群、或云服务器。所述服务端具体可以是独立的物理服务器，也可以是由多个物理服务器构成的服务器集群或分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。
所述终端和所述服务端可以通过有线通信或无线通信的方式，进行直接或间接的连接，本公开不做特殊限制。
在本公开的一个实施例中，所述终端至少可以采用RED冗余技术来解决音频传输过程中出现的抗丢包问题；也即，所述终端可以获取该终端在当前时段的选路概率值，并基于所述当前时段的选路概率值，对该终端在下一时段的初始RED冗余度进行自适应调整，以得到该终端在下一时段的自适应RED冗余度；进一步地，所述终端可以按照该终端在下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给所述服务端。
请参见图3，图3是一示例性实施例提供的一种音频传输方法的流程图。所述方法可以应用于如图2所示的任一终端。所述方法可以包括以下步骤：
步骤301：获得终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端。
在本实施例中，所述服务端可以为所述终端提供该终端在当前时段的选路概率值；相应地，所述终端可以获得该终端在当前时段的选路概率值。
例如，当前时刻可以为第t个时段，服务端210可以为终端220提供该终端在当前时段的选路概率值filtered_S(t)；终端220可以获得该终端在当前时段的选路概率值filtered_S(t)。其中，所述选路概率值的取值范围可以为filtered_S(t)∈[0，1]。
需要说明的是，关于每个时段的时长，本说明书中不做限制，本领域技术人员可以根据需求灵活设置。例如，每个时段的时长可以与所述服务端的选路周期时长相同，所述服务端的选路周期通常可以为20ms。又例如，所述时段的时长可以包括由用户为所述终端配置的用于周期性地自适应调整RED冗余度的预设周期时长。又例如，所述时段的时长可以包括极短的一段时间的时长。
在本实施例中，所述终端可以自行计算以得到该终端在当前时段的选路概率值；或者，所述终端也可以直接获得由所述服务端计算出来的该终端在当前时段的选路概率值。
在一些可能的实施方式中，所述获得该终端在当前时段的选路概率值，具体可以包括：接收所述服务端周期性发送的RTCP报文，所述RTCP报文中包括该终端在当前时段的选中标记的标记值；获得所述RTCP报文中包括的该终端在当前时段的选中标记的标记值；根据所获得的该终端在当前时段的选中标记的标记值进行计算，以获得该终端在当前时段的选路概率值。其中，所述选中标记的标记值，可以用于表征在相应时段下相应终端所发送的音频流是否被所述服务端选中的状态结果；所述选中标记的标记值取第一值时，可以表征在相应时段下相应终端所发送的音频流已被所述服务端选中；所述选中标记的标记值取第二值时，可以表征在相应时段下相应终端所发送的音频流未被所述服务端选中。
在这种情况下，所述服务端可以根据当前时段所述终端发送的音频流是否被所述服务端选中的状态结果，确定该终端在当前时段的选中标记的标记值；所述服务端可以向所述终端周期性发送RTCP报文，所述RTCP报文中可以包括该终端在当前时段的选中标记的标记值；相应地，所述终端可以获得所述RTCP报文中包括的该终端在当前时段的选中标记的标记值；进一步地，所述终端可以根据所获得的该终端在当前时段的选中标记的标记值进行计算，以获得该终端在当前时段的选路概率值。
例如，服务端210可以根据当前时段终端220所发送的音频流是否被该服务端选中的状态结果，来确定终端220在当前时段的选中标记的标记值S(t)；进一步地，服务端210可以向终端220周期性发送RTCP报文，并且，所述RTCP报文中可以包括终端220在当前时段的选中标记的标记值S(t)；进一步地，终端220可以接收服务端210发送的所述RTCP报文，并可以获取到所述RTCP报文中包括的终端220在当前时段的选中标记的标记值S(t)；进一步地，终端220可以根据所获取到的终端220在当前时段的选中标记的标记值S(t)进行计算，以获得终端220在当前时段的选路概率值filtered_S(t)。其中，若当前时段终端220所发送的音频流已被服务端210选中，则可以确定终端220在当前时段的选中标记的标记值S(t)＝1；若未被选中，则可以确定终端220在当前时段的选中标记的标记值S(t)＝0。
需要说明的是，在以上示出的实施方式中，所述第一值可以为1，且所述第二值可以为0，仅仅是一种示例性的描述方式，并不代表对本说明书做出特殊限制。例如，所述第一值可以为0，且所述第二值可以为1；也即，所述选中标记的标记值S(t)＝0时，可以表征在相应时段下相应终端所发送的音频流已被该服务端选中；所述选中标记的标记值S(t)＝1时，可以表征在相应时段下相应终端所发送的音频流未被该服务端选中。
另外，在这种情况下，为了避免同一终端在不同时刻的选路概率值变化剧烈，所述终端可以采用滑动加权平均计算的方式，来计算所述终端在当前时段的选路概率值。根据该终端在当前时段的选中标记的标记值进行计算，以获得该终端在当前时段的选路概率值，具体可以包括：根据该终端在上一时段的选路概率值以及该终端在当前时段的选中标记的标记值，进行滑动加权平均计算，以获得该终端在当前时段的选路概率值。
例如，当前时段可以为第t个时段，则上一时段可以为第t-1个时段；终端220可以获取到该终端在上一时段的选路概率值为filtered_S(t-1)，以及，可以获取到该终端在当前时段的选中标记的标记值S(t)；进一步地，终端220可以按照预设的加权因子p，根据该终端在上一时段的选路概率值filtered_S(t-1)、以及该终端在当前时段的选中标记的标记值S(t)，采用如下所示的公式：
Figure BDA0003471520530000081
来进行滑动加权平均计算，以获得该终端在当前时段的选路概率值filtered_S(t)。其中，所述加权因子的取值范围可以为p∈(0，1]。
需要说明的是，在以上示出的实施方式中，该终端在上一时段的选路概率值filtered_S(t-1)所占的权重越大，该终端在不同时段的选路概率值的变化就越平稳，进而可以避免后续对初始RED冗余度进行频繁地、大幅度地自适应调整；而该终端在当前时段的选中标记的标记值S(t)所占的权重越大，可以通过该终端在不同时段的选路概率值的变化情况，更明显地反映出该终端在不同时段中所发送的音频流是否被该服务端选中的状态结果的变化情况，进而可以后续对初始RED冗余度及时地进行自适应调整。
而关于所述加权因子的具体取值，本领域技术人员可以根据需求灵活设置，本说明书中不做限制；例如，所述加权因子p可以为0.9。
在另一些可能的实施方式中，所述获得该终端在当前时段的选路概率值，具体可以包括：接收所述服务端周期性发送的RTCP报文，所述RTCP报文中包括由所述服务端进行计算而获得的该终端在当前时段的选路概率值；获得所述RTCP报文中包括的该终端在当前时段的选路概率值。
在这种情况下，所述服务端可以根据当前时段所述终端发送的音频流是否被所述服务端选中的状态结果，确定该终端在当前时段的选中标记的标记值；所述服务端可以根据该终端在当前时段的选中标记的标记值进行计算，以获得该终端在当前时段的选路概率值；所述服务端可以向所述终端周期性发送RTCP报文，所述RTCP报文中可以包括由所述服务端进行计算而获得的该终端在当前时段的选路概率值；相应地，所述终端可以获得所述RTCP报文中包括的该终端在当前时段的选路概率值。
例如，服务端210可以根据当前时段终端220发送的音频流是否被选中的状态结果，确定终端220在当前时段的选中标记的标记值S(t)；服务端210可以根据终端220在当前时段的选中标记的标记值S(t)进行计算，以获得终端220在当前时段的选路概率值filtered_S(t)；服务端210可以向终端220周期性发送RTCP报文，并且，所述RTCP报文中可以包括由服务端210计算出来的终端220在当前时段的选路概率值filtered_S(t)；终端220可以接收服务端210发送的所述RTCP报文，并可以获取到所述RTCP报文中包括的终端220在当前时段的选路概率值filtered_S(t)。
需要说明的是，在这种情况下，为了避免同一终端在不同时刻的选路概率值变化剧烈，所述服务端也可以采用滑动加权平均计算的方式，来计算所述终端在当前时段的选路概率值。由所述服务端根据该终端在当前时段的选中标记的标记值进行计算以获得该终端在当前时段的选路概率值的具体实现方式，与由所述终端根据该终端在当前时段的选中标记的标记值进行计算以获得该终端在当前时段的选路概率值的具体实现方式类似，在此不再赘述，请参见上述实施例。
在本实施例中，所述终端至少可以采用RED冗余来解决音频数据传输过程中出现的丢包问题。在基于所述当前时段的选路概率值，对该终端在下一时段的初始RED冗余度进行自适应调整之前，除了可以获得该终端在当前时段的选路概率值，还可以确定该终端在下一时段的初始RED冗余度。
步骤302：确定下一时段的初始RED冗余度；其中，RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值。
例如，当前时段可以为第t个时段，则下一时段可以为第t+1个时段；终端210可以确定下一时段的初始RED冗余度RED_redundance_by_lossrate(t+1)。
需要说明的是，关于所述RED冗余度的计算方式，下面进行示例性地说明。例如，如图1所示，在冗余编码后的音频数据110中，99号包为原音频数据，96号包、97号包、98号包为冗余音频数据，因此，冗余编码后的音频数据110的RED冗余度为3:1＝300％；类似的，在冗余编码后的音频数据120中，100号包为原音频数据，97号包、99号包为冗余音频数据，因此，冗余编码后的音频数据120的RED冗余度为2:1＝200％。
在一些可能的实施方式中，该终端在下一时段的初始RED冗余度，可以是基于该终端在当前时段的丢包率而确定的。所述确定下一时段的初始RED冗余度，具体可以包括：获得该终端在当前时段的丢包率；基于该终端在当前时段的丢包率，确定下一时段的初始RED冗余度。
例如，终端220可以获得终端220在当前时段的丢包率lossrate(t)，并可以基于所获得的当前时段的丢包率lossrate(t)，确定下一时段的初始RED冗余度RED_redumdance_by_lossrate(t+1)。
在一种示例性的实施方式中，本领域技术人员可以根据网络带宽、抗丢包需求等因素，为所述终端预先配置当前时段的丢包率与下一时段的初始RED冗余度之间的对应关系；所述基于该终端在当前时段的丢包率，确定下一时段的初始RED冗余度，具体可以包括：根据预先配置当前时段的丢包率与下一时段的初始RED冗余度之间的对应关系，确定与该终端在当前时段的丢包率对应的下一时段的初始RED冗余度。
例如，请参见表1，表1是一种示例性的为终端所预先配置的当前时段的丢包率与下一时段的初始RED冗余度之间的对应关系。
lossrate(t) RED_redundance_by_lossrate(t+1)
＜10％ 0
10％～20％ 100％
20％～50％ 200％
＞＞50％ 300％
表1
如表1所示，若终端220获得当前时段的丢包率lossrate(t)＝30％，则可以确定下一时段的初始RED冗余度RED_redundance_by_lossrate(t+1)＝200％。
在一种示例性的实施方式中，所述终端可以根据接收到的所述服务端发送的RTCP报文，获得该终端在当前时段的丢包率；所述RTCP报文中可以包括与该终端在当前时段的丢包率相关的参数信息。
例如，服务端210向终端220发送的RTCP报文中，可以包括终端220在当前时段的发包数量和丢包数量；终端220在接收到所述RTCP报文之后，可以根据当前时段的发包数量和丢包数量进行计算，以获得终端220在当前时段的丢包率。
又例如，服务端210向终端220发送的RTCP报文中，可以包括终端220在当前时段的丢包率；终端220在接收到所述RTCP报文之后，可以获得所述RTCP报文中包括的终端220在当前时段的丢包率。
在本实施例中，在获得该终端在当前时段的选路概率值，以及确定该终端在下一时段的初始RED冗余度之后，所述终端可以基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整。
需要说明的是，由于所述终端可以按照当前时段的实际RED冗余度，对当前时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给所述服务端，进而在所述服务端确定当前时刻的选路结果之后，可以获得该终端在当前时段的选路概率值，因此，所述终端可以基于该终端在当前时段的选路概率值，对该终端在下一时段的初始RED冗余度进行自适应调整。
步骤303：基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度。
例如，终端220在获得该终端在当前时刻的时段的选路概率值filtered_S(t)，以及确定下一时段的初始RED冗余度RED_redundance_by_lossrate(t+1)之后，可以基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整；具体地，可以采用如下所示的公式：
RED_redundance(t+1)＝RED_redundance_by_lossrate(t+1)*filted_S(t)，
以得到下一时段的自适应RED冗余度RED_redundance(t+1)。
步骤304：按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给所述服务端。
例如，终端220在基于该终端在当前时刻的时段的选路概率值filtered_S(t)，对下一时段的初始RED冗余度RED_redundance_by_lossrate(t+1)进行自适应调整之后，可以按照得到的下一时段的自适应RED冗余度RED_redundance(t+1)，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给服务端210。
在一些可能的实施方式中，所述终端基于获得的该终端在当前时段的选路概率值，除了可以对下一时段的初始RED冗余度进行自适应调整，还可以对下一时段的初始码率进行自适应调整。在将所述冗余编码后的音频流发送给所述服务端之前，所述方法还可以包括：基于所述下一时段的初始RED冗余度，确定下一时段的初始码率；以及，基于所述下一时段的自适应RED冗余度，确定下一时段的自适应码率，以按照所述下一时段的自适应码率，将所述冗余编码后的音频流发送给所述服务端。
在一种示例性的实施方式中，本领域技术人员可以为所述终端预先配置每个时段的RED冗余度与码率之间的对应关系；所述终端可以根据预先配置的所述对应关系，确定与下一时段的RED冗余度对应的下一时段的码率。
例如，请参见表2，表2是一种示例性的为所述终端预先配置每个时段的RED冗余度与码率之间的对应关系。
RED冗余度 码率
0 20kbps
100％ 32kbps
200％ 64kbps
300％ 128kbps
表2
如表2所示，若终端220可以确定下一时段的初始RED冗余度为300％，则可以确定下一时段的初始码率为128kbps；若终端220可以确定下一时段的自适应RED冗余度为200％，则可以确定下一时段的自适应码率为64kbps；进一步地，终端220可以按照下一时段的自适应码率，将所述冗余编码后的音频流发送给服务端210。
在这种情况下，由于所述终端在当前时段所发送的音频流未被服务端选中时，该终端在当前时段的选路概率值会减少，进而该终端在下一时段的码率也会降低(也即下一时段的自适应码率小于下一时段的初始码率)，因此按照降低后的码率向所述服务端发送音频流，可以节约出来下一时段的初始码率中的部分码率；进一步地，所述终端可以将节约出来的这一部分码率分配给其他数据流，也即可以用于该终端在下一时段将待发送的其他数据流发送给所述服务端。
在确定下一时段的自适应码率之后，所述方法还可以包括：计算所述下一时段的自适应码率与所述下一时段的初始码率之间的差值，并将所述差值确定为下一时段的第一类可分配码率；所述下一时段的第一类可分配码率，用于该终端在下一时段将待发送的其他数据流发送给所述服务端；所述其他数据流，包括该终端在下一时段待发送的除所述冗余编码后的音频流之外的数据流；将所述下一时段的第一类可分配码率分配给所述其他数据流。
接着以上示出的实施例继续说明，若终端220可以下一时段的初始码率为128kbps，下一时段的自适应码率为64kbps，则可以计算上述二者之间的差值，以得到下一时段的第一类可分配码率为128kbps-64kbps＝64kbps；进一步地，终端220可以将所述下一时段的第一类可分配码率，分配给该终端在下一时段待发送的、除所述冗余编码后的音频流之外的其他数据流。
在一种示例性的实施方式中，所述终端可以不将全部的所述第一类可分配码率分配给其他数据流，也即，可以只将所述下一时段的第一类可分配码率中的部分，分配给其他数据流，用于其他数据流的传输，并可以将所述下一时段的第一类可分配码率中的剩余部分预留出来，用于避免出现网络堵塞等情况。所述将所述下一时段的第一类可分配码率分配给所述其他数据流，具体可以包括：将所述下一时段的第一类可分配码率中的部分，分配给所述其他数据流。
例如，终端220可以按照预设的预留因子q，根据计算得到的下一时段的第一类可分配码率remain_bitrate(t+1)，可以采用以下示出的公式：
usable_remain_bitrate(t+1)＝q*remain_bitrate(t+1)，来进行加权计算，以获得该终端在下一时段可以分配给其他数据流的部分码率usable_remain_bitrate(t+1)。其中，所述预留因子的取值范围可以为q∈(0，1]。而关于所述预留因子的具体取值，本领域技术人员可以根据需求灵活设置，本说明书中不做限制；例如，所述预留因子q可以为0.9。
在一种示例性的实施方式中，所述终端可以在相应时段，将向所述服务端发送音频流所节约出来的第一类可分配码率，用于向所述服务端发送视频流，从而提高视频数据传输过程中的抗丢包能力，进而可以提升多方视频通信的用户体验。所述其他数据流具体可以包括：该终端在下一时段待发送的视频流。
例如，终端220可以将计算得到的下一时段的第一类可分配码率的全部或部分，分配给终端220在下一时段待发送的、除所述冗余编码后的音频流之外的其他数据流。
在一些可能的实施方式中，所述终端除了可以在当前时段的选路概率值减少时，降低该终端在下一时段的RED冗余度，还可以在当前时段的选路概率值增加时或者大于预设阈值时，提高该终端在下一时段的RED冗余度；通过按照提高得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的编码，可以增加在所述终端向所述服务端发送的冗余编码后的音频流中的冗余音频数据，进而可以提升所述终端针对音频数据的抗丢包能力。
在一种示例性的实施方式中，在按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码之前，所述方法还可以包括：响应于所获得的该终端在当前时段的选路概率值大于预设阈值，将下一时段的第二类可分配码率，分配给该终端在下一时段的待发送音频流；所述下一时段的第二类可分配码率，包括下一时段该终端在码率资源池中预留的码率；基于所分配的所述下一时段的第二类可分配码率，提高所述下一时段的自适应RED冗余度。
例如，终端220在获得该终端在当前时刻的时段的选路概率值filtered_S(t)，以及确定下一时段的初始RED冗余度RED_redundance_by_lossrate(t+1)之后，可以采用如下所示的公式：
RED_redundance(t+1)＝RED_redundance_by_lossrate(t+1)*filtered_S(t)，
基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度RED_redundance(t+1)；进一步地，若终端220在当前时段的选路概率值大于预设阈值，可以认为该终端所发送的音频流被服务端210选中的概率较高，因此，可以将下一时段的第二类可分配码率，分配给终端220在下一时段的待发送音频流，以使终端220可以进一步地提高下一时段的自适应RED冗余度RED_redundance(t+1)。
在另一种示例性的实施方式中，所述基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，具体可以包括：响应于所获得的该终端在当前时段的选路概率值大于预设阈值，将下一时段的第二类可分配码率，分配给该终端在下一时段的待发送音频流；所述下一时段的第二类可分配码率，包括下一时段该终端在码率资源池中预留的码率；基于所分配的所述下一时段的第二类可分配码率，提高所述下一时段的初始RED冗余度，以得到下一时段的自适应RED冗余度。
例如，终端220在获得该终端在当前时刻的时段的选路概率值filtered_S(t)之后，若所述当前时段的选路概率值大于预设阈值，可以认为该终端所发送的音频流被服务端210选中的概率较高，因此，可以将下一时段的第二类可分配码率，分配给终端220在下一时段的待发送音频流，以使终端220可以对下一时段的初始RED冗余度RED_redundance_by_lossrate(t+1)进行提高，得到下一时段的自适应RED冗余度RED_redundance(t+1)。
在一些可能的实施方式中，所述终端可以同时采用RED冗余和ARQ技术来解决音频数据传输过程中出现的丢包问题。在这种情况下，所述终端基于获得的该终端在当前时段的选路概率值，除了可以对下一时段的初始RED冗余度进行自适应调整，还可以对下一时段的初始NACK响应频率进行自适应调整，从而不仅可以减少该终端发送给所述服务端的冗余编码后的音频流的数据量，而且可以减少该终端向所述服务端重传音频流的数据量，进而可以同时减少该终端基于RED冗余和ARQ技术抗丢包的性能开销，减少占用的上行带宽，缓解网络堵塞的风险。
所述方法还可以包括：确定下一时段的初始NACK响应频率；基于所述当前时段的选路概率值，对所述下一时段的初始NACK响应频率进行自适应调整，得到下一时段的自适应NACK响应频率；按照所述下一时段的自适应NACK响应频率，在下一时段中响应于接收到所述服务端发送的NACK请求，向所述服务端重新发送所述冗余编码后的音频流。
其中，所述NACK响应频率，可以为所述终端响应于接收到所述服务端发送的NACK请求，向所述服务端重传数据包的频率。
例如，终端220可以确定下一时段的初始NACK响应频率NACK_response_freq_by_RTT(t+1)；终端220可以基于该终端在当前时段的选路概率值filtered_S(t)，对下一时段的初始NACK响应频率NACK_response_freq_by_RTT(t+1)进行自适应调整；具体地，可以采用如下所示的公式：
NACK_response_freq(t+1)＝
NACK_response_freq_by_RTT(t+1)*filtered_S(t)，
以得到下一时段的自适应NACK响应频率NACK_response_freq(t+1)。进一步地，终端220可以按照下一时段的自适应NACK响应频率NACK_response_freq(t+1)，在下一时段中响应于接收到服务端210发送的NACK请求，向服务端210重新发送所述冗余编码后的音频流。
在这种情况下，该终端在下一时段的初始NACK响应频率，可以是基于该终端与所述服务端之间的RTT(Round-Trip Time，往返时延)而确定的。其中，所述RTT，可以表示从所述终端向所述服务端发送音频数据开始，到所述终端接收到来自所述服务端的确认消息之间的时长。
所述确定下一时段的初始NACK响应频率，具体可以包括：获得该终端与所述服务端之间的RTT；根据所获得的该终端与所述服务端之间的RTT，确定所述下一时段的初始NACK响应频率。
例如，终端220可以获得该终端与服务端210之间的RTT；根据所获得的该终端与所述服务端之间的RTT，可以确定下一时段的初始NACK响应频率
Figure BDA0003471520530000141
在一种示例性的实施方式中，所述终端可以根据接收到的所述服务端发送的RTCP报文，获得该终端与所述服务端之间的RTT；所述RTCP报文中可以包括与该终端与所述服务端之间的RTT相关的参数信息。
例如，服务端210与终端220之间互相交互的RTCP报文中，可以包括终端220向服务端210发送音频数据包的第一时间戳、以及终端220接收到服务端210发送的针对所述音频数据包的确认消息的第二时间戳；终端220在接收到所述RTCP报文之后，可以根据所述第一时间戳和所述第二时间戳进行计算，以获得终端220与服务端210之间的RTT。其中，所述RTCP报文，具体可以包括SR(Sender Report，发送端报告)报文和RR(Receiver Report，接收端报告)报文。关于获得所述RTT的具体实现方式，以上示出的实施例中仅仅是一种示例性的描述方式，未详尽描述之处请参见相关技术，在此不再赘述。
在以上实施例中，一方面，终端可以基于自身在当前时段的选路概率值，对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并且该终端可以按照所述下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给服务端。由于终端在当前时段所发送的音频流未被服务端选中时，该终端在当前时段的选路概率值会减少，进而该终端在下一时段的RED冗余度会降低(也即下一时刻的自适应RED冗余度小于下一时刻的初始RED冗余度)，因此按照降低后的RED冗余度，对下一时刻的待发送音频流进行基于RED协议的冗余编码，得到的冗余编码后的音频流的数据量会减少，从而可以减少终端性能开销，减少占用的上行带宽，缓解网络堵塞的风险。
另一方面，从系统整体来看，不同的终端在同一时刻的选路概率值可能存在差异，通过每个终端基于自身的选路概率值，对该终端的RED冗余度进行自适应调整，可以实现不同的终端在同一时刻的RED冗余度也存在差异(也即不同的终端在同一时刻的自适应RED冗余度不同)，从而在每个终端都可以保证针对音频数据的抗丢包能力的同时，能够优化音频传输过程中的系统整体性能。
与上述音频传输方法相对应，在本公开的另一个实施例中，所述服务端可以向所述终端提供该终端在当前时段的选路概率值，以使所述终端可以基于所述当前时段的选路概率值对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码；进一步地，所述服务端可以接收所述终端发送的冗余编码后的音频流。
请参见图4，图4是一示例性实施例提供的一种音频传输方法的流程图。所述方法可以应用于如图2所示的服务端。所述方法可以包括以下步骤：
步骤401：为终端提供该终端在当前时段的选路概率值，以使所述终端基于所述当前时段的选路概率值对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码；其中，所述选路概率值，用于表征在相应时段，所述服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值。
例如，当前时刻可以为第t个时段，服务端210可以为终端220提供该终端在当前时段的选路概率值filtered_S(t)；以使终端220可以基于所述当前时段的选路概率值filtered_S(t)对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码。
在一些可能的实施方式中，所述为终端提供该终端在当前时段的选路概率值，具体可以包括：根据当前时段所述终端发送的音频流是否被所述服务端选中的状态结果，确定该终端在当前时段的选中标记的标记值；其中，所述选中标记的标记值取第一值时，表征在相应时段下相应终端所发送的音频流已被该服务端选中；所述选中标记的标记值取第二值时，表征在相应时段下相应终端所发送的音频流未被该服务端选中；根据该终端在当前时段的选中标记的标记值进行计算，以获得该终端在当前时段的选路概率值；向所述终端周期性发送RTCP报文，所述RTCP报文中包括由所述服务端进行计算而获得的该终端在当前时段的选路概率值。
在这种情况下，所述根据该终端在当前时段的选中标记的标记值进行计算，以获得该终端在当前时段的选路概率值，具体可以包括：根据该终端在上一时段的选路概率值以及该终端在当前时段的选中标记的标记值，进行滑动加权平均计算，以获得该终端在当前时段的选路概率值。
在另一些可能的实施方式中，所述为终端提供该终端在当前时段的选路概率值，具体可以包括：根据当前时段所述终端发送的音频流是否被所述服务端选中的状态结果，确定该终端在当前时段的选中标记的标记值；向所述终端周期性发送RTCP报文，所述RTCP报文中包括该终端在当前时段的选中标记的标记值，以使所述终端根据所述RTCP报文中包括的该终端在当前时段的选中标记的标记值进行计算，以获得该终端在当前时段的选路概率值。
步骤402：接收所述终端发送的冗余编码后的音频流。
例如，服务端210可以接收终端220发送的冗余编码后的音频流。
需要说明的是，在本公开的实施方式中，所述步骤401-步骤402的具体实现方式与上述步骤301-步骤304相似，在此不再赘述。
在一些可能的实施方式中，除了在终端一侧做出的自适应调整，所述服务端还可以基于所述终端在当前时段的选路概率值，对下一时段的初始NACK请求频率和/或下一时段的初始NACK最大请求次数进行自适应调整，从而避免音频传输过程中的资源浪费，缓解网络堵塞的风险。
所述方法还可以包括：确定下一时段的初始NACK请求频率和/或下一时段的初始NACK最大请求次数；基于该终端在当前时段的选路概率值，对所述下一时段的初始NACK请求频率和/或所述下一时段的初始NACK最大请求次数进行自适应调整，以得到下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数；根据所述下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数，向所述终端发送NACK请求。
其中，所述NACK请求频率，可以为所述服务端向所述终端发送NACK请求的频率；所述NACK最大请求次数，可以为所述服务端向所述终端发送NACK请求的最大次数。
例如，服务端210可以确定下一时段的初始NACK请求频率NACK_req_freq_by_RTT(t+1)；服务端210可以基于该终端在当前时段的选路概率值filtered_S(t)，对下一时段的初始NACK请求频率NACK_req_freq_by_RTT(t+1)进行自适应调整；具体地，可以采用如下所示的公式：
NACK_req_freq(t+1)＝NACK_req_freq_by_RTT(t+1)*filtered_S(t)，
以得到下一时段的自适应NACK请求频率NACK_req_freq(t+1)。进一步地，服务端210可以根据所述下一时段的自适应NACK请求频率NACK_req_freq(t+1)，向终端220发送NACK请求。
又例如，服务端210可以确定下一时段的初始NACK最大请求次数NACK_max_req_time_by_RTT(t+1)；服务端210可以基于该终端在当前时段的选路概率值filtered_S(t)，对下一时段的初始NACK最大请求次数NACK_max_req_time_by_RTT(t+1)进行自适应调整；具体地，可以采用如下所示的公式：
NACK_max_req_time(t+1)＝NACK_max_req_time_by_RTT(t+1)*filtered_S(t)，
以得到下一时段的自适应NACK最大请求次数NACK_max_req_time(t+1)。进一步地，服务端210可以根据所述下一时段的自适应NACK最大请求次数NACK_max_req_time(t+1)，向终端220发送NACK请求。
又例如，服务端210可以确定下一时段的初始NACK请求频率NACK_req_freq_by_RTT(t+1)，和下一时段的初始NACK最大请求次数NACK_max_req_time_by_RTT(t+1)；进一步地，服务端210可以基于该终端在当前时段的选路概率值filtered_S(t)，分别对下一时段的初始NACK请求频率NACK_req_freq_by_RTT(t+1)、以及下一时段的初始NACK最大请求次数NACK_max_req_time_by_RTT(t+1)进行自适应调整，以得到下一时段的自适应NACK请求频率NACK_req_freq(t+1)、以及下一时段的自适应NACK最大请求次数，NACK_max_req_time(t+1)。进一步地，服务端210可以根据所述下一时段的自适应NACK请求频率NACK_req_freq(t+1)、以及下一时段的自适应最大请求次数NACK_max_req_time(t+1)，向终端220发送NACK请求。
在这种情况下，该终端在下一时段的初始NACK响应频率，可以是基于该终端与所述服务端之间的RTT(Round-Trip Time，往返时延)而确定的。所述确定下一时段的初始NACK请求频率，具体可以包括：获得所述终端与所述服务端之间的RTT；根据所述终端与所述服务端之间的RTT，确定所述下一时段的初始NACK请求频率。
例如，服务端210可以获得该终端与服务端210之间的RTT；根据所获得的该终端与所述服务端之间的RTT，可以确定下一时段的初始NACK请求频率
Figure BDA0003471520530000161
在以上实施例中，所述服务端可以向所述终端提供该终端在当前时段的选路概率值，以使所述终端可以基于自身在当前时段的选路概率值，对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并且可以按照所述下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给服务端。由于终端在当前时段所发送的音频流未被服务端选中时，该终端在当前时段的选路概率值会减少，进而该终端在下一时段的RED冗余度会降低(也即下一时刻的自适应RED冗余度小于下一时刻的初始RED冗余度)，因此按照降低后的RED冗余度，对下一时刻的待发送音频流进行基于RED协议的冗余编码，得到的冗余编码后的音频流的数据量会减少，从而可以减少终端性能开销，减少占用的上行带宽，缓解网络堵塞的风险。
在本公开的另一个实施例中，至少可以采用ARQ技术来解决音频传输过程中出现的抗丢包问题；也即，所述终端可以获得该终端在当前时段的选路概率值，并基于所述当前时段的选路概率值，对该终端在下一时段的初始NACK响应频率进行自适应调整，得到下一时段的自适应NACK响应频率；进一步地，所述终端可以按照所述下一时段的自适应NACK响应频率，在下一时段中响应于接收到所述服务端发送的NACK请求，向所述服务端重新发送所述冗余编码后的音频流。
请参见图5，图5是一示例性实施例提供的另一种音频传输方法的流程图。所述方法可以应用于如图2所示的任一终端。所述方法可以包括以下步骤：
步骤501：获得终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端。
例如，当前时刻可以为第t个时段，服务端210可以为终端220提供该终端在当前时段的选路概率值filtered_S(t)；终端220可以获得该终端在当前时段的选路概率值filtered_S(t)。
步骤502：确定下一时段的初始NACK响应频率；
步骤503：基于所述当前时段的选路概率值，对所述下一时段的初始NACK响应频率进行自适应调整，得到下一时段的自适应NACK响应频率。
例如，终端220还可以确定下一时段的初始NACK响应频率NACK_response_freq_by_RTT(t+1)；终端220可以基于该终端在当前时段的选路概率值filtered_S(t)，对下一时段的初始NACK响应频率NACK_response_freq_by-RTT(t+1)进行自适应调整；具体地，可以采用如下所示的公式：
NACK_response_freq(t+1)＝
NACK_response_freq_by_RTT(t+1)*filtered_S(t)，
以得到下一时段的自适应NACK响应频率NACK_response_freq(t+1)。
步骤504：按照所述下一时段的自适应NACK响应频率，在下一时段中响应于接收到所述服务端发送的NACK请求，向所述服务端重新发送音频流。
例如，在基于该终端在当前时段的选路概率值filtered_S(t)，对下一时段的初始NACK响应频率NACK_response_freq_by_RTT(t+1)进行自适应调整，得到下一时段的自适应NACK响应频率NACK_response-freq(t+1)，之后，终端220可以按照所述下一时段的自适应NACK响应频率NACK_response_freq(t+1)，在下一时段中响应于接收到服务端210发送的NACK请求，向服务端210重新发送所述冗余编码后的音频流。
需要说明的是，在以上示出的实施例中，关于所述步骤501-步骤504的具体实现方式，可以参见所述步骤301-步骤304的具体实现方式，在此不再赘述。
在以上实施例中，由于终端在当前时段所发送的音频流未被服务端选中时，该终端在当前时段的选路概率值会减少，因此该终端可以基于该终端在当前时段的选路概率值，对下一时段的初始NACK响应频率进行自适应调整，以得到下一时段的自适应NACK响应频率，并且可以按照所述下一时段的自适应NACK响应频率，在下一时段中响应于接收到所述服务端发送的NACK请求，向所述服务端重新发送所述冗余编码后的音频流。从而可以减少该终端向所述服务端重传音频流的数据量，进而可以减少该终端基于ARQ处理抗丢包的性能开销，减少重传音频流所占用的上行带宽，缓解网络堵塞的风险。
与上述音频传输方法相对应，在本公开的另一个实施例中，至少可以采用ARQ技术来解决音频传输过程中出现的抗丢包问题；也即，所述服务端可以获得终端在当前时段的选路概率值，并可以基于该终端在当前时段的选路概率值，对所述下一时段的初始NACK请求频率和/或所述下一时段的初始NACK最大请求次数进行自适应调整，以得到下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数；进一步地，所述服务端可以根据所述下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数，向所述终端发送NACK请求。
请参见图6，图6是一示例性实施例提供的另一种音频传输方法的流程图。所述方法可以应用于如图2所示的服务端。所述方法可以包括以下步骤：
步骤601：获得终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，所述服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端。
例如，服务端210可以获得终端220在当前时段的选路概率值filtered_S(t)。
步骤602：确定下一时段的初始NACK请求频率和/或下一时段的初始NACK最大请求次数；
步骤603：基于该终端在当前时段的选路概率值，对所述下一时段的初始NACK请求频率和/或所述下一时段的初始NACK最大请求次数进行自适应调整，以得到下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数；
步骤604：根据所述下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数，向所述终端发送NACK请求。
例如，服务端210可以确定下一时段的初始NACK请求频率NACK_req_freq_by_RTT(t+1)；服务端210可以基于该终端在当前时段的选路概率值filtered_S(t)，对下一时段的初始NACK请求频率NACK_req_freq_by_RTT(t+1)进行自适应调整；具体地，可以采用如下所示的公式：
NACK_req_freq(t+1)＝NACK_req_freq_by_RTT(t+1)*filtered_S(t)，
以得到下一时段的自适应NACK请求频率NACK_req_freq(t+1)。进一步地，服务端210可以根据所述下一时段的自适应NACK请求频率NACK_req_freq(t+1)，向终端220发送NACK请求。
又例如，服务端210可以确定下一时段的初始NACK最大请求次数NACK_max_req_time_by_RTT(t+1)；服务端210可以基于该终端在当前时段的选路概率值filtered_S(t)，对下一时段的初始NACK最大请求次数NACK_max_req_time_by_RTT(t+1)进行自适应调整；具体地，可以采用如下所示的公式：
NACK_max_req_time(t+1)＝NACK_max_req_time_by_RTT(t+1)*filtered_S(t)，
以得到下一时段的自适应NACK最大请求次数NACK_max_req_time(t+1)。进一步地，服务端210可以根据所述下一时段的自适应NACK最大请求次数NACK_max_req_time(t+1)，向终端220发送NACK请求。
又例如，服务端210可以确定下一时段的初始NACK请求频率NACK_req_freq_by_RTT(t+1)，和下一时段的初始NACK最大请求次数NACK_max_req_time_by_RTT(t+1)；进一步地，服务端210可以基于该终端在当前时段的选路概率值filtered_S(t)，分别对下一时段的初始NACK请求频率NACK_req_freq_by_RTT(t+1)、以及下一时段的初始NACK最大请求次数NACK_max_req_time_by_RTT(t+1)进行自适应调整，以得到下一时段的自适应NACK请求频率NACK_req_freq(t+1)、以及下一时段的自适应NACK最大请求次数，NACK_max_req-time(t+1)。进一步地，服务端210可以根据所述下一时段的自适应NACK请求频率NACK_req_freq(t+1)、以及下一时段的自适应最大请求次数NACK_max_req_time(t+1)，向终端220发送NACK请求。
需要说明的是，在以上示出的实施例中，关于所述步骤601-步骤604的具体实现方式，可以参见所述步骤401-步骤402的具体实现方式，在此不再赘述。
在以上实施例中，由于终端在当前时段所发送的音频流未被服务端选中时，该终端在当前时段的选路概率值会减少，因此服务端可以基于该终端在当前时段的选路概率值，对下一时段的初始NACK请求频率和/或初始NACK最大请求次数进行自适应调整，以得到下一时段的自适应NACK请求频率和/或自适应NACK最大请求次数，并且可以按照所述下一时段的自适应NACK请求频率和/或自适应NACK最大请求次数，向该终端发送NACK请求。从而可以减少服务端向该终端发送NACK请求的次数，进而可以减少该终端基于ARQ处理抗丢包的性能开销，减少重传音频流所占用的上行带宽，缓解网络堵塞的风险。
示例性装置
在本公开的示例性实施例中，还提供了一种音频传输装置。
请参见图7，图7是一示例性实施例提供的一种音频传输装置的框图。
如图7所示，音频传输装置700可以包括：获得模块701、确定模块702、调整模块703、编码模块704和发送模块705。其中：
所述获得模块701，用于获得该终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
所述确定模块702，用于确定下一时段的初始RED冗余度；其中，RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值；
所述调整模块703，用于基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度；
所述编码模块704，用于按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码；
所述发送模块705，用于将冗余编码后的音频流发送给所述服务端。
在一实施例中，所述获得模块701，具体用于：
接收所述服务端周期性发送的RTCP报文，所述RTCP报文中包括由所述服务端进行计算而获得的该终端在当前时段的选路概率值；
获得所述RTCP报文中包括的该终端在当前时段的选路概率值。
在一实施例中，所述获得模块701，具体用于：
接收所述服务端周期性发送的RTCP报文，所述RTCP报文中包括该终端在当前时段的选中标记的标记值；其中，所述选中标记的标记值，用于表征在相应时段下相应终端所发送的音频流是否被所述服务端选中的状态结果；所述选中标记的标记值取第一值时，表征在相应时段下相应终端所发送的音频流已被所述服务端选中；所述选中标记的标记值取第二值时，表征在相应时段下相应终端所发送的音频流未被所述服务端选中；
获得所述RTCP报文中包括的该终端在当前时段的选中标记的标记值；
根据所获得的该终端在当前时段的选中标记的标记值进行计算，以获得该终端在当前时段的选路概率值。
在一实施例中，所述获得模块701，具体用于：
根据该终端在上一时段的选路概率值以及该终端在当前时段的选中标记的标记值，进行滑动加权平均计算，以获得该终端在当前时段的选路概率值。
在一实施例中，所述确定模块702，具体用于：
获得该终端在当前时段的丢包率；
基于该终端在当前时段的丢包率，确定下一时段的初始RED冗余度。
在一实施例中，所述确定模块702，还用于：
基于所述下一时段的初始RED冗余度，确定下一时段的初始码率；以及，基于所述下一时段的自适应RED冗余度，确定下一时段的自适应码率；
计算所述下一时段的自适应码率与所述下一时段的初始码率之间的差值，并将所述差值确定为下一时段的第一类可分配码率；所述下一时段的第一类可分配码率，用于该终端在下一时段将待发送的其他数据流发送给所述服务端；所述其他数据流，包括该终端在下一时段待发送的除所述冗余编码后的音频流之外的数据流；
所述装置还包括：
分配模块，用于将所述下一时段的第一类可分配码率分配给所述其他数据流。
在一实施例中，所述其他数据流，包括：该终端在下一时段待发送的视频流。
在一实施例中，所述分配模块，具体用于：
将所述下一时段的第一类可分配码率中的部分，分配给所述其他数据流。
在一实施例中，所述分配模块，还用于：
响应于所获得的该终端在当前时段的选路概率值大于预设阈值，将下一时段的第二类可分配码率，分配给该终端在下一时段的待发送音频流；所述下一时段的第二类可分配码率，包括下一时段该终端在码率资源池中预留的码率；
基于所分配的所述下一时段的第二类可分配码率，提高所述下一时段的自适应RED冗余度。
在一实施例中，所述确定模块702，还用于确定下一时段的初始NACK响应频率；
所述调整模块703，还用于基于所述当前时段的选路概率值，对所述下一时段的初始NACK响应频率进行自适应调整，得到下一时段的自适应NACK响应频率；
所述发送模块705，还用于按照所述下一时段的自适应NACK响应频率，在下一时段中响应于接收到所述服务端发送的NACK请求，向所述服务端重新发送所述冗余编码后的音频流。
在一实施例中，所述确定模块702，具体用于：
获得该终端与所述服务端之间的往返时延RTT；
根据所获得的该终端与所述服务端之间的RTT，确定所述下一时段的初始NACK响应频率。
请参见图8，图8是一示例性实施例提供的另一种音频传输装置的框图。
如图8所示，音频传输装置800可以包括：提供模块801和接收模块802。其中：
所述提供模块801，用于为终端提供该终端在当前时段的选路概率值，以使所述终端基于所述当前时段的选路概率值对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码；其中，所述选路概率值，用于表征在相应时段，所述服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值；
所述接收模块802，用于接收所述终端发送的冗余编码后的音频流。
在一实施例中，所述提供模块801，具体用于：
根据当前时段所述终端发送的音频流是否被所述服务端选中的状态结果，确定该终端在当前时段的选中标记的标记值；其中，所述选中标记的标记值取第一值时，表征在相应时段下相应终端所发送的音频流已被该服务端选中；所述选中标记的标记值取第二值时，表征在相应时段下相应终端所发送的音频流未被该服务端选中；
根据该终端在当前时段的选中标记的标记值进行计算，以获得该终端在当前时段的选路概率值；
向所述终端周期性发送RTCP报文，所述RTCP报文中包括由所述服务端进行计算而获得的该终端在当前时段的选路概率值。
在一实施例中，所述提供模块801，具体用于：
根据当前时段所述终端发送的音频流是否被所述服务端选中的状态结果，确定该终端在当前时段的选中标记的标记值；
向所述终端周期性发送RTCP报文，所述RTCP报文中包括该终端在当前时段的选中标记的标记值，以使所述终端根据所述RTCP报文中包括的该终端在当前时段的选中标记的标记值进行计算，以获得该终端在当前时段的选路概率值。
在一实施例中，所述提供模块801，具体用于：
根据该终端在上一时段的选路概率值以及该终端在当前时段的选中标记的标记值，进行滑动加权平均计算，以获得该终端在当前时段的选路概率值。
在一实施例中，所述装置还包括：
确定模块，用于确定下一时段的初始NACK请求频率和/或下一时段的初始NACK最大请求次数；
调整模块，用于基于该终端在当前时段的选路概率值，对所述下一时段的初始NACK请求频率和/或所述下一时段的初始NACK最大请求次数进行自适应调整，以得到下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数；
发送模块，用于根据所述下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数，向所述终端发送NACK请求。
在一实施例中，所述确定模块，具体用于：
获得所述终端与所述服务端之间的RTT；
根据所述终端与所述服务端之间的RTT，确定所述下一时段的初始NACK请求频率。
请参见图9，图9是一示例性实施例提供的另一种音频传输装置的框图。
如图9所示，音频传输装置900可以包括：获得模块901、确定模块902、调整模块903和发送模块904。其中：
所述获得模块901，用于获得该终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
所述确定模块902，用于确定下一时段的初始NACK响应频率；
所述调整模块903，用于基于所述当前时段的选路概率值，对所述下一时段的初始NACK响应频率进行自适应调整，得到下一时段的自适应NACK响应频率；
所述发送模块904，用于按照所述下一时段的自适应NACK响应频率，在下一时段中响应于接收到所述服务端发送的NACK请求，向所述服务端重新发送音频流。
请参见图10，图10是一示例性实施例提供的另一种音频传输装置的框图。
如图10所示，音频传输装置1000可以包括：获得模块1001、确定模块1002、调整模块1003和发送模块1004。其中：
所述获得模块1001，用于获得终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，所述服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
所述确定模块1002，用于确定下一时段的初始NACK请求频率和/或下一时段的初始NACK最大请求次数；
所述调整模块1003，用于基于该终端在当前时段的选路概率值，对所述下一时段的初始NACK请求频率和/或所述下一时段的初始NACK最大请求次数进行自适应调整，以得到下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数；
所述发送模块1004，用于根据所述下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数，向所述终端发送NACK请求。
上述音频传输装置700、音频传输装置800、音频传输装置900、以及音频传输装置1000的各个模块的具体细节，已经在之前描述音频传输方法流程中进行了详细的描述，因此，此处不再赘述。
应当注意，尽管在上文详细描述中提及音频传输装置700、音频传输装置800、音频传输装置900、以及音频传输装置1000的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
示例性介质
在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施例中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施例的步骤。
请参见图11，图11是一示例性实施例提供的一种音频传输方法对应的可读存储介质的示意图。
参考图11所示，描述了根据本公开的实施例的用于实现上述方法的可读存储介质1100，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的可读存储介质不限于此，在本公开中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
所述可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
示例性电子设备
在本公开的示例性实施例中，还提供了一种能够实现上述音频传输方法的电子设备。
请参见图12，图12是一示例性实施例提供的一种能够实现上述方法的电子设备的示意图。
下面参照图12来描述根据本公开的这种实施例的电子设备1200。图12显示的电子设备1200仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
如图12所示，电子设备1200以通用计算设备的形式表现。电子设备1200的组件可以包括但不限于：上述至少一个处理单元1201、上述至少一个存储单元1202、连接不同系统组件(包括存储单元1202和处理单元1201)的总线1203。
其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1201执行，使得所述处理单元1201执行本说明书上述各种实施例的步骤。
存储单元1202可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)12021和/或高速缓存存储单元12022，还可以进一步包括只读存储单元(ROM)12023。
存储单元1202还可以包括具有一组(至少一个)程序模块12025的程序/使用工具12024，这样的程序模块12025包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包含网络环境的现实。
总线1203可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
电子设备1200也可以与一个或多个外部设备1204(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1200交互的设备通信，和/或与使得该电子设备1200能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1205进行。并且，电子设备1200还可以通过网络适配器1206与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器1206通过总线1203与电子设备1200的其它模块通信。应当明白，尽管图12中未示出，可以结合电子设备1200使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施例的方法。
本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。
应当注意，尽管在上文详细描述中提及了装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种音频传输方法，应用于终端，所述方法包括：
获得该终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
确定下一时段的初始RED冗余度；其中，RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值；
基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度；
按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码，并将冗余编码后的音频流发送给所述服务端。
2.根据权利要求1所述的方法，所述方法还包括：
确定下一时段的初始NACK响应频率；
基于所述当前时段的选路概率值，对所述下一时段的初始NACK响应频率进行自适应调整，得到下一时段的自适应NACK响应频率；
按照所述下一时段的自适应NACK响应频率，在下一时段中响应于接收到所述服务端发送的NACK请求，向所述服务端重新发送所述冗余编码后的音频流。
3.一种音频传输方法，应用于服务端，所述方法包括：
为终端提供该终端在当前时段的选路概率值，以使所述终端基于所述当前时段的选路概率值对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码；其中，所述选路概率值，用于表征在相应时段，所述服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值；
接收所述终端发送的冗余编码后的音频流。
4.根据权利要求3所述的方法，所述方法还包括：
确定下一时段的初始NACK请求频率和/或下一时段的初始NACK最大请求次数；
基于该终端在当前时段的选路概率值，对所述下一时段的初始NACK请求频率和/或所述下一时段的初始NACK最大请求次数进行自适应调整，以得到下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数；
根据所述下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数，向所述终端发送NACK请求。
5.一种音频传输方法，应用于终端，所述方法包括：
获得该终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
确定下一时段的初始NACK响应频率；
基于所述当前时段的选路概率值，对所述下一时段的初始NACK响应频率进行自适应调整，得到下一时段的自适应NACK响应频率；
按照所述下一时段的自适应NACK响应频率，在下一时段中响应于接收到所述服务端发送的NACK请求，向所述服务端重新发送音频流。
6.一种音频传输方法，应用于服务端，所述方法包括：
获得终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，所述服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
确定下一时段的初始NACK请求频率和/或下一时段的初始NACK最大请求次数；
基于该终端在当前时段的选路概率值，对所述下一时段的初始NACK请求频率和/或所述下一时段的初始NACK最大请求次数进行自适应调整，以得到下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数；
根据所述下一时段的自适应NACK请求频率和/或所述下一时段的自适应NACK最大请求次数，向所述终端发送NACK请求。
7.一种音频传输装置，应用于终端，所述装置包括：
获得模块，用于获得该终端在当前时段的选路概率值；其中，所述选路概率值，用于表征在相应时段，服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；
确定模块，用于确定下一时段的初始RED冗余度；其中，RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值；
调整模块，用于基于所述当前时段的选路概率值，对所述下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度；
编码模块，用于按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码；
发送模块，用于将冗余编码后的音频流发送给所述服务端。
8.一种音频传输装置，应用于服务端，所述装置包括：
提供模块，用于为终端提供该终端在当前时段的选路概率值，以使所述终端基于所述当前时段的选路概率值对下一时段的初始RED冗余度进行自适应调整，以得到下一时段的自适应RED冗余度，并按照所得到的下一时段的自适应RED冗余度，对下一时段的待发送音频流进行基于RED协议的冗余编码；其中，所述选路概率值，用于表征在相应时段，所述服务端从所接收到的若干路音频流中选中该终端所发送的音频流的概率，被选中的该终端所发送的音频流将由所述服务端转发至其他终端；RED冗余度，用于表征基于RED协议对待发送音频流进行冗余编码后，该冗余编码后的音频流中冗余音频数据与原音频数据之间的比值；
接收模块，用于接收所述终端发送的冗余编码后的音频流。
9.一种电子设备，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述权利要求1-2或3-4或5或6中任一所述的方法。
10.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现权利要求1-2或3-4或5或6中任一所述的方法中的步骤。
CN202210044235.5A 2022-01-14 2022-01-14 音频传输方法、装置、电子设备及计算机可读存储介质 Active CN114448588B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210044235.5A CN114448588B (zh) 2022-01-14 2022-01-14 音频传输方法、装置、电子设备及计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210044235.5A CN114448588B (zh) 2022-01-14 2022-01-14 音频传输方法、装置、电子设备及计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN114448588A true CN114448588A (zh) 2022-05-06
CN114448588B CN114448588B (zh) 2024-01-23

Family

ID=81366948

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210044235.5A Active CN114448588B (zh) 2022-01-14 2022-01-14 音频传输方法、装置、电子设备及计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN114448588B (zh)

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101026553A (zh) * 2005-11-09 2007-08-29 索尼株式会社 分组传输装置、通信系统和程序
CN101808244A (zh) * 2010-03-24 2010-08-18 北京邮电大学 一种视频传输控制方法及系统
WO2012079321A1 (zh) * 2010-12-14 2012-06-21 中兴通讯股份有限公司 一种提供流媒体服务的方法及系统、设备
WO2015074073A1 (en) * 2013-11-18 2015-05-21 Qualcomm Incorporated Techniques for outer loop management in a multiple output system
CN106973253A (zh) * 2016-01-13 2017-07-21 华为技术有限公司 一种调整媒体流传输的方法及装置
CN111371957A (zh) * 2020-05-26 2020-07-03 腾讯科技（深圳）有限公司 一种冗余度控制方法、装置、电子设备和存储介质
CN111389017A (zh) * 2020-04-14 2020-07-10 网易（杭州）网络有限公司 游戏中的交互控制方法、装置、电子设备及计算机介质
US20200235864A1 (en) * 2019-01-23 2020-07-23 Hong Kong Applied Science And Technology Research Institute Co., Ltd. Method and an Apparatus for Improving a Determination of HARQ-ACK Messages in a Wireless Communications System
CN111585776A (zh) * 2020-05-26 2020-08-25 腾讯科技（深圳）有限公司 数据传输方法、装置、设备及计算机可读存储介质
CN111628992A (zh) * 2020-05-26 2020-09-04 腾讯科技（深圳）有限公司 一种多人通话控制方法、装置、电子设备及存储介质
WO2021197008A1 (zh) * 2020-04-02 2021-10-07 京东方科技集团股份有限公司 音视频通信方法、终端、服务器、计算机设备和存储介质
WO2021209037A1 (zh) * 2020-04-16 2021-10-21 华为技术有限公司 数据恢复方法及装置

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101026553A (zh) * 2005-11-09 2007-08-29 索尼株式会社 分组传输装置、通信系统和程序
CN101808244A (zh) * 2010-03-24 2010-08-18 北京邮电大学 一种视频传输控制方法及系统
WO2012079321A1 (zh) * 2010-12-14 2012-06-21 中兴通讯股份有限公司 一种提供流媒体服务的方法及系统、设备
WO2015074073A1 (en) * 2013-11-18 2015-05-21 Qualcomm Incorporated Techniques for outer loop management in a multiple output system
CN106973253A (zh) * 2016-01-13 2017-07-21 华为技术有限公司 一种调整媒体流传输的方法及装置
US20200235864A1 (en) * 2019-01-23 2020-07-23 Hong Kong Applied Science And Technology Research Institute Co., Ltd. Method and an Apparatus for Improving a Determination of HARQ-ACK Messages in a Wireless Communications System
WO2021197008A1 (zh) * 2020-04-02 2021-10-07 京东方科技集团股份有限公司 音视频通信方法、终端、服务器、计算机设备和存储介质
CN111389017A (zh) * 2020-04-14 2020-07-10 网易（杭州）网络有限公司 游戏中的交互控制方法、装置、电子设备及计算机介质
WO2021209037A1 (zh) * 2020-04-16 2021-10-21 华为技术有限公司 数据恢复方法及装置
CN111371957A (zh) * 2020-05-26 2020-07-03 腾讯科技（深圳）有限公司 一种冗余度控制方法、装置、电子设备和存储介质
CN111585776A (zh) * 2020-05-26 2020-08-25 腾讯科技（深圳）有限公司 数据传输方法、装置、设备及计算机可读存储介质
CN111628992A (zh) * 2020-05-26 2020-09-04 腾讯科技（深圳）有限公司 一种多人通话控制方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN114448588B (zh) 2024-01-23

Similar Documents

Publication Publication Date Title
US11349900B2 (en) Voice encoding and sending method and apparatus
Wu et al. Enabling adaptive high-frame-rate video streaming in mobile cloud gaming applications
JP4287429B2 (ja) 階層型通信シナリオにおける複数の通信層の動作を制御する装置および方法
KR102051504B1 (ko) 무선 통신 시스템에서 데이터 패킷 송수신 방법 및 장치
CN111800218B (zh) 一种数据流的传输方法和设备
US9237105B2 (en) Data communication with compensation for packet loss
US9246973B2 (en) Identifying and transitioning to an improved VoIP session
US9961509B2 (en) Base station and a plurality of member nodes for transmitting and receiving network coding based multicast traffic
MX2015004596A (es) Metodo y aparato para el control de envio de datos de medios.
EP1733331B1 (en) Codec-assisted capacity enhancement of wireless voip
CN111629210A (zh) 一种数据处理的方法、装置及电子设备
US20110055656A1 (en) Systems, Methods, and Media for Checking Available Bandwidth Using Forward Error Correction
US20230071243A1 (en) Conserving network resources during transmission of packets of interactive services
US20170084280A1 (en) Speech Encoding
JP2007028623A (ja) ネットワークストリームベースの伝送速度を加速するためにｂｅｒ／ｐｅｒを調整するためのシステムおよび方法
CN111585776B (zh) 数据传输方法、装置、设备及计算机可读存储介质
CN114448569A (zh) 数据传输方法、设备及计算机存储介质
CN112751644A (zh) 数据传输方法、装置及系统、电子设备
KR20150026405A (ko) 음성 패킷 송수신 방법 및 이를 구현하는 전자 장치
CN112771875B (zh) 在保持视频质量的同时提高视频比特率
CN114448588B (zh) 音频传输方法、装置、电子设备及计算机可读存储介质
CN112737971B (zh) 数据处理方法、装置、存储介质及网络设备
CN115550459A (zh) 语音数据的发送和接收方法以及相关设备
CN109005011B (zh) 一种用于水声网络的数据传输方法、系统及可读存储介质
CN112165655A (zh) 基于视联网的数据传输方法、装置、设备及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant