CN115052172A - 音视频数据传输方法、装置、电子设备和存储介质 - Google Patents

音视频数据传输方法、装置、电子设备和存储介质 Download PDF

Info

Publication number
CN115052172A
CN115052172A CN202210626312.8A CN202210626312A CN115052172A CN 115052172 A CN115052172 A CN 115052172A CN 202210626312 A CN202210626312 A CN 202210626312A CN 115052172 A CN115052172 A CN 115052172A
Authority
CN
China
Prior art keywords
audio
bandwidth
video data
path
receiving end
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.)
Pending
Application number
CN202210626312.8A
Other languages
English (en)
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.)
Beijing Century TAL Education Technology Co Ltd
Original Assignee
Beijing Century TAL Education 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 Beijing Century TAL Education Technology Co Ltd filed Critical Beijing Century TAL Education Technology Co Ltd
Priority to CN202210626312.8A priority Critical patent/CN115052172A/zh
Publication of CN115052172A publication Critical patent/CN115052172A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26216—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the channel capacity, e.g. network bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本公开涉及一种音视频数据传输方法、装置、电子设备和存储介质。音视频数据传输方法应用于接收端，方法包括：基于预先构建的一个带宽评估模块对接收端的带宽进行评估，生成带宽评估结果；将带宽评估结果发送至和接收端连接的服务端，服务端用于通过预先构建的一个转发控制模块根据带宽评估结果生成控制参数；接收基于控制参数进行调整后的多路音视频数据，其中，多路音视频数据是由服务端连接的多路发送端生成的。本公开提供的方法能够解决客户端同时拉取多路音视频数据流时因带宽资源限制所产生的音视频卡顿问题，最大限度提升用户体验。

Description

音视频数据传输方法、装置、电子设备和存储介质
技术领域
本公开涉及计算机技术领域，尤其涉及一种音视频数据传输方法、装置、电子设备和存储介质。
背景技术
在线教育场景中，无论是纯小班课的教育场景或者大班套小组的教育场景，为了最大限度还原线下课堂真实氛围，学生之间会进行实时音视频互动，学生除了需要拉取老师那路音视频数据流外，还会拉取其他学生的音视频数据流，由于每个学生端需要拉流的数量较多，因此对网络环境的要求较高。
目前，学生端通常需要同时去拉取多路音视频数据流，但是，该种拉流方式会导致少部分处于极端弱网环境的学生端在观看直播课时出现音视频卡顿的现象，进而影响学生的上课体验。
发明内容
为了解决上述技术问题，本公开提供了一种音视频数据传输方法、装置、电子设备和存储介质，能够解决客户端同时拉取多路音视频数据流时因带宽资源限制所产生的音视频卡顿问题，最大限度提升用户体验。
根据本公开的一方面，提供了一种音视频数据传输方法，应用于接收端，所述方法包括：
基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果；
将所述带宽评估结果发送至和所述接收端连接的服务端，所述服务端用于通过预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数；
接收基于所述控制参数进行调整后的多路音视频数据，其中，所述多路音视频数据是由所述服务端连接的多路发送端生成的。
根据本公开的另一方面，提供了一种音视频数据传输方法，应用于服务端，所述方法包括：
接收带宽评估结果，其中，所述带宽评估结果是由所述服务端连接的接收端根据上述音视频数据传输方法生成的；
利用预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数，将基于所述控制参数调整后的多路音视频数据发送至所述接收端，其中，所述多路音视频数据是和所述服务端连接的多路发送端生成的。
根据本公开的另一方面，提供了一种音视频数据传输装置，应用于接收端，包括：
评估单元，用于基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果；
发送单元，用于将所述带宽评估结果发送至和所述接收端连接的服务端，所述服务端用于通过预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数；
接收单元，用于接收基于所述控制参数进行调整后的多路音视频数据，其中，所述多路音视频数据是由所述服务端控制的多路发送端生成的。
根据本公开的另一方面，提供了一种音视频数据传输装置，应用于服务端，包括：
接收单元，用于接收带宽评估结果，其中，所述带宽评估结果是由所述服务端连接的接收端根据上述音视频数据传输方法生成的；
生成单元，用于利用预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数，将基于所述控制参数调整后的多路音视频数据发送至所述接收端，其中，所述多路音视频数据是和所述服务端连接的多路发送端生成的。
根据本公开的另一方面，提供了一种电子设备，所述电子设备包括：处理器；以及存储程序的存储器，其中，所述程序包括指令，所述指令在由所述处理器执行时使所述处理器执行根据上述音视频数据传输方法。
根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行根据音视频数据传输方法。
根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现上述音视频数据传输方法。
本公开实施例提供的技术方案与现有技术相比具有如下优点：
本公开提供的一种音视频数据传输方法，应用于接收端，接收端可以理解为客户端，方法包括：基于预先构建的一个带宽评估模块对接收端的带宽进行评估，生成带宽评估结果；将带宽评估结果发送至和接收端连接的服务端，服务端用于通过预先构建的一个转发控制模块根据带宽评估结果生成控制参数；接收基于控制参数进行调整后的多路音视频数据，其中，多路音视频数据是由服务端连接的多路发送端生成的。本公开能够解决客户端同时拉取多路音视频数据流时因带宽资源限制所产生的音视频卡顿问题，最大限度提升用户体验。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本公开实施例提供的一种应用场景的示意图；
图2为本公开实施例提供的一种客户端和服务端的交互示意图；
图3为本公开实施例提供的一种音视频数据传输的结构图；
图4为本公开实施例提供的一种音视频数据传输方法流程图；
图5为本公开实施例提供的另一种音视频数据传输的结构图；
图6为本公开实施例提供的另一种音视频数据传输方法流程图；
图7为本公开实施例提供的一种音视频数据传输装置的结构示意图；
图8为本公开实施例提供的一种音视频数据传输装置的结构示意图；
图9为本公开实施例提供的一种电子设备的结构示意图。
具体实施方式
为了能够更清楚地理解本公开的上述目的、特征和优点，下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。
应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。
本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。
需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。
本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。
下面首先对本公开的权利要求书和说明书中涉及的一些名词或者术语进行解释说明。
RTC：Real-timeCommunication(实时通信)，是一种实时通信技术，其特点是延迟低，主要用于远程实时通话。
RTP：Real-time Transport Protocol，实时传输协议，用于传输实时数据，是实时通信技术里常用的传输协议。
RTCP：Real-time Control Ptotocol，实时控制协议，用于QoS反馈和同步媒体流，控制数据传输质量。
RTMP：Real Time Messaging Protocol(实时消息传输协议)，是标准直播的通用协议，主要用于实时推流。
CNN：Convolutional Neural Networks，卷积神经网络，是一类包含卷积计算且具有深度结构的前馈神经网络(Feedforward Neural Networks)。
H5：HTML5(HyperText Markup Language 5)HTML5是构建Web内容的一种语言描述方式。HTML5是互联网的下一代标准，是构建以及呈现互联网内容的一种语言方式。
PCM：Pulse Code Modulation(脉冲编码调制)，是一种数字通信的编码方式之一，是常见的原始音频数据格式。
AAC：Advanced Audio Coding(高级音频编码)，AAC作为一种高压缩比的音频编码算法，压缩比通常为18：1；在音质方面，由于采用多声道，和使用低复杂性的描述方式，使用性能比较高。
Opus：Opus是一种有损音频压缩的数字音频编码格式，且适用于网络上低延迟的即时声音传输，可以用在各种音频应用场景，包括IP语音、视频会议、游戏内聊天、流音乐、甚至远程现场音乐表演。
IM：Instant Messaging(即时消息)，指可以在线实时交流的工具，也就是通常所说的在线聊天工具。
本公开提供的音视频数据传输方法可以应用在实时音视频通信(Real-timeCommunication，RTC)、互动直播、在线教育、音视频会议等场景中。在这些场景中，每个客户端可能会观看和/或收听多个远端的音视频数据流，例如：多人视频会议场景、在线教育小班课场景、在线教育大班小组课场景等。下述一个或多个实施例以在线教育场景为例对本公开提供的音视频数据传输方法进行详细说明。
具体的，图1为本公开实施例提供的一种应用场景的示意图，图1包括老师音视频数据流110、学生本人音视频数据流120、其他同学音视频数据流130和聊天区140。在图1中的在线教育场景中，无论是纯小班课的教育场景或者大班套小组的教育场景，为了最大限度还原线下课堂真实氛围，学生之间会进行实时音视频互动，学生除了要拉取老师那路音视频直播流外，还会拉取其他学生的音视频数据流，具体的，如图1所示，N+1位学生一起上在线直播课，图1中只示出了一为其他同学130的音视频数据流，其余N-1位学生的音视频数据流未示出，学生本人120需要拉取老师的音视频数据流110，加上其他N(N为正整数)位同学的音视频数据流130，还可以在聊天区140回答老师的问题或者记录的问题，聊天区140具体可以是IM聊天区。每个学生拉取老师的音视频直播流主要是听老师讲课，每个学生(学生本人)还会拉取其他N位同学的音视频数据流，来营造一种课堂氛围，还原线下的教学场景。每位学生会拉N+1路音视频数据流(1路老师的直播流和N路其他学生的直播流)，由于每个学生端(客户端)的拉流数量较多，因此对网络环境的要求较高，由于现存技术或方案的不足，导致少部分极端弱网环境的学生观看直播课时出现音视频卡顿的现象，影响上课体验，主要是因为弱网环境的网络质量较差(网络带宽小、丢包率较高、延迟较大、网络抖动较大)，较差的网络质量不足以支撑同时观看多路直播流，进而导致用户观看在线教学直播的体验比较差，甚至可能无法正常观看老师那路音视频数据流。
针对上述技术问题，本公开实施例提供了一种音视频数据传输方法，接收端对多路音视频数据流进行综合的带宽评估结果，也就是能够根据不同质量的网络条件，自动评估接收端的拉流数量，服务端基于该带宽评估结果进行决策控制生成针对每路音视频数据流的控制参数，随后接收端再接收基于控制参数调整后的多路音视频数据流，以解决接收端同时拉取多路音视频数据流时因带宽资源限制所产生的音视频卡顿问题，最大限度的提升了用户体验。具体通过下述一个或多个实施例进行详细说明。
在对本公开提供的方法进行说明之前，优先对音视频直播领域的相关技术问题进行说明。具体的，图2为本公开实施例提供的一种客户端和服务端的交互示意图，图2包括作为推流端的RTC客户端210(发送端)、RTC流媒体服务端220和作为拉流端的RTC客户端230(接收端)，其中，RTC客户端210包括摄像头和麦克风采集音频/视频、对音频/视频进行前处理、音频/视频编码、音频/视频发送等流程，发送后的视频/音频经过网络到达RTC服务端220。RTC流媒体服务端220(简称RTC服务端)是一套高度复杂的系统，RTC服务端220是一系列服务的集合，其中包含多种服务，例如调度系统、房间服务、转发服务、转码服务录制服务、截图服务、混流服务等，RTC流媒体服务端220的功能主要是负责转发音视频数据流式数据、处理音视频内容，RTC流媒体服务端220的另一部分功能，负责收集接收端230(RTC客户端(拉流端))带宽评估模块REMB(Receiver Estimated Maximum Bitrate)的带宽评估结果，根据接收端230的带宽评估结果，平滑地向接收端230转发音视频资源，但是，在RTC(实时通信)领域，通常都是独立的去评估每一路音视频数据流所需要的带宽，RTC服务端220不区分每一路音视频数据流的优先级，而是根据每一路音视频数据流的网络质量动态调整发送策略、处理弱网对抗相关逻辑，但是当网络条件极端差的情况下，现有的弱网对抗逻辑无法保证接收端230观看每一路音视频数据流都是正常的，任何一路直播流都可能会出现卡断等无法正常观看的情况。RTC客户端(拉流端)230执行从RTC服务端220接收音频/视频、对音频/视频进行解码、对音频/视频进行后处理、播放音频/视频等流程，此外，接收端230(也称拉流端)还会对客户端所处的网络环境进行评估，即多个带宽评估模块REMB(ReceiverEstimated Maximum Bitrate)中的每个带宽评估模块评估一路音视频数据流，并将评估信息上报给RTC服务端220。
示例性的，参见图3，图3为本公开实施例提供的一种音视频数据传输的结构图，也就是现有方法中音视频数据传输的结构图，图3包括多路发送端310、服务端和接收端350，其中，多路发送端310中每路发送端都会生成一路音视频数据流(直播流)，如图3所示的发送端1生成音视频数据流1，发送端2生成音视频数据流2，服务端包括每一路音视频数据流对应的转发控制模块320、每一路音视频数据流对应的带宽分配模块330和每一路音视频数据流对应的平滑模块340，接收端350包括多个对每一路音视频数据流的带宽进行评估的带宽评估模块。下述示例以传输一路直播流的音视频数据为例进行说明，接收端350中的带宽评估模块351接收对应的平滑模块341传输的一路音视频数据流，并根据该音视频数据流对该路音视频数据流进行带宽评估，生成该路的带宽评估结果发送至服务端中的转发控制模块321，转发控制模块321根据该路的带宽评估结果生成转发控制逻辑，具体的，带宽评估结果会返回以下三种信号：网络空闲(underuse)、网络过载(overuse)和网络正常(normal)，网络空闲对于某一路音视频数据流来说可以理解为当前接收端350的网络带宽资源空闲，也就是说当前带宽资源能够满足该某一路音视频数据流的带宽消耗，状态机进入“hold”状态，此时需要通知服务端保持发送速率(码率)来发送音视频数据流至接收端350；网络过载对于某一路音视频数据流来说当前带宽资源已经被过度使用，也就是说当前带宽资源已经不能够满足该路音视频数据流的带宽消耗，状态机进入“decrease降低”状态，此时需要通知发送端311降低发送速率(码率)来发送直播流；网络正常对于某一路音视频数据流来说当前带宽资源使用正常，状态机进入“increase增加”状态，此时需要通知服务端开始增加发送速率(码率)，服务端也会向发送端返回参数，以确保发送端发送稳定的音视频数据流。转发控制模块321根据该路的带宽评估结果生成转发控制逻辑后，将转发逻辑发送至发送该路音视频数据流311对应的带宽分配模块331，带宽分配模块331根据转发控制模块321发送的转发逻辑调整音视频数据流311传输的音视频数据的码率，随后将码率调整后的该路音视频数据发送至对应的平滑模块341，最后平滑模块341对该路音视频数据进行平滑处理并将其传输至接收端350，以供用户观看音视频数据，完成该路音视频数据的传输。但是，当一个接收端350需要拉多路音视频直播流时，采用现有方法，分别对每一路音视频数据流独立的进行带宽评估，生成每路音视频数据流对应的带宽评估结果，也就是每一个带宽评估结果只反应当前接收端的带宽资源与该路音视频数据流所消耗的带宽的情况，例如接收端350接收10路音视频数据流，会生成10个音视频数据流各自对应的带宽评估结果，即使每一路音视频数据流的带宽评估后评估结果信号均为underuse或者normal，但是不代表接收端350当前的带宽资源能满足所有音视频数据流的带宽需要，按照现有技术规则，在这种状态下，网络拥塞状态机进入“hold”或者“increase”状态。若网络拥塞状态机进入“hold”状态，此时需要通知RTC服务端的转发控制模块320来保持当前服务器的数据转发逻辑，进而通知服务端保持发送速率(码率)来向接收端发送音视频数据流，也就是说每一路音视频数据流都会保持当前码率发送音视频数据，该种情况就会出现当每一路音视频数据流都保持各自的数据发送逻辑时，由于每一路音视频数据流的带宽评估周期、开始拉流、结束拉流的时间点不同，无法保证当前接收端350的网络条件在拉每一路音视频数据流时都不会出现卡顿现象，当接收端350网络的条件较差时，接收端350同时去拉所有音视频数据流时，实际情况会出现每一路音视频数据流相互争抢带宽资源的情况，当接收端350的网络环境较差时，就会出现严重卡顿的现象发生。若每一个带宽评估结果显示的信号均为normal状态，按照现有技术规则，在这种状态下，状态机进入“increase”状态，此时需要通知RTC服务端的转发控制模块320来加快当前服务器的数据转发速率，进而通知发送端310开始增加发送速率(码率)，也就是说每一路音视频数据流都会增加发送码率，在实际中也会出现每一路音视频数据流相互争抢接收端350带宽资源的情况，当接收端350网络环境较差时，就会出现严重卡顿的现象发生，导致接收端350播放的每一路音视频数据流都出现卡顿，严重影响了用户体验。
针对上述技术问题，参见图4，图4为本公开实施例提供的一种音视频数据传输方法流程图，应用于接收端，接收端是指每个学生本人的客户端，具体包括如图4所示的如下步骤S410至S430：
S410、基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果。
可理解的，接收端包括预先构建的一个带宽评估模块，该带宽评估模块记为MultiREMB模块，该带宽评估模块能够对多路音视频数据流进行综合评估，生成带宽评估结果，也就是确定接收端当前带宽资源能否满足多路音视频数据流。例如，接收端需要接收10路音视频数据流，利用一个预先构建的带宽评估模块对10路音视频数据流和接收端的当前带宽资源进行评估，生成带宽评估结果。
示例性的，参见图5，图5为本公开实施例提供的另一种音视频数据传输的结构图，图5可以理解为本公开中涉及到的音视频数据传输装置的结构图，图5包括多路发送端(多路音视频数据流)510、服务端和接收端550，其中，服务端包括一个转发控制模块520、每路音视频数据流对应的带宽分配模块530、一个平滑模块540，接收端550包括一个带宽评估模块551，多路音视频数据流510连接对应的带宽分配模块530，接收端550中的带宽评估模块551针对多个音视频数据流确定一个综合带宽评估结果，并将其发送至转发控制模块520，转发控制模块520用于根据生成的控制参数对每路音视频数据流对应的带宽分配模块530进行控制，也就是进行综合决策分析，平滑模块540接收每路音视频数据流对应的带宽分配模块530传输的调整后的音视频数据(带宽分配后的音视频数据)并进行平滑处理，随后将多路音视频数据传输至接收端550，保证在网络抖动比较厉害的时候，能够匀速地发送音视频数据，提升接收端550观看直播的流畅率。
可选的，在基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果之前，所述方法还包括如下步骤：
调用预先配置的接口为所述多路发送端设置优先级，其中，所述接收端和所述多路发送端处于同一个频道。
可理解的，在客户端发起音视频音视频通话/互动直播/视频会议之前，需要将待通话的用户加入频道，线上频道可以理解位开会议的房间，多个用户加入同一个频道，在同一个频道内的用户可以互相音视频通话、音视频会议等，接收端在加入频道前，调用预先构建的接口为其他待加入同一个频道的远端用户设置优先级，可以将指定的远端用户的优先级设置为高，例如可以根据远端用户的标识userId来设置优先级。可理解的是，接收端(拉流端)用户为近端用户，发送端(推流端)用户为远端用户。预先构建的接口可以通过下述语句调用，调用接口的语句为setRemoteUserPriority(userId:longint,userPriority:string)，可选的，语句的实现逻辑可以通过CNN或者H5语言描述构建，具体构建方式不作限定；其中，接口语句包括2个参数userId(远端用户标识)和userPriority(远端用户优先级)，还包括每个参数对应的数据类型，userId对应的数据类型为长整型(Longint)，userPriority对应的数据类型为整型(int)，可选的，以远端用户的优先级设置2个等级为例进行说明，优先级的等级数量不作限定，可以根据用户需求自行确定，2个等级为高优先级(high)和正常优先级(normal)，默认的优先级为正常优先级，高优先级对应的参数值可以是1，正常优先级对应的参数值可以是0，例如，调用的接口语句可以设置为setRemoteUserPriority(userId:123456789,userPriority:1)，该语句可以理解为远端用户123456789设置为高优先级。可以理解的是，加入同一频道进行音视频通话的过程中还可以调用接口实时设置每个远端用户的优先级，例如，在教育场景中，在加入频道之前，优先将老师那路的音视频直播流设置为高优先级，在加入频道讲课的过程中，还可以将回答问题的同学的优先级设置为高优先级，也可以实时将高优先级调整为正常优先级，以保证弱网环境下的直播体验。
可选的，上述S410具体可以通过下述步骤实现：
接收由预先构建的一个平滑模块传输的数据信息，其中，所述数据信息是所述平滑模块根据所述多路发送端发送的多路音视频数据的传输信息进行整合得到的。
基于预先构建的一个带宽评估模块，根据设置的所述多路发送端的优先级、所述接收端的带宽信息和所述数据信息生成带宽评估结果。
示例性的，接收端550中的一个带宽评估模块551接收由预先构建的一个平滑模块540传输的数据信息，平滑模块540记为PacedSender，其中，数据信息是平滑模块根据多路发送端发送的多路音视频数据的传输信息进行整合得到的，数据信息可以是每个发送端向接收端发送的数据包的时间和大小，接收端可以记录每个数据包到达的时间并计算出每个数据分组之间的延迟变化，也就是接收端可以采用基于延迟(delay-based)的拥塞控制算法来评估带宽情况，继而生成带宽评估结果，带宽评估结果包括接收端要接收多路音视频直播流所需的码率以及接收端能够承接的最大码率等；接收端还可以采用基于丢包(loss-based)的拥塞控制算法，具体的，发送端通过从接收端周期性发来的接收端报告(ReceiverReport，RTCP RR)中获取丢包信息以及计算往返时延(Round-Trip Time，RTT)，随后接收端通过自身携带的码率信息和往返时延算得最终的码率值，构建的带宽评估模块551计算多路音视频直播流码率的方法不作限定，可以根据用户需求自行确定。随后预先构建的一个带宽评估模块会根据设置的多路发送端中每路发送端的优先级、接收端的带宽信息(最大限度的带宽承载量)和数据信息生成带宽评估结果。
可选的，上述根据设置的所述多路发送端的优先级、所述接收端的带宽信息和所述数据信息生成带宽评估结果，具体可以通过下述步骤实现：
根据所述数据信息确定所述多路音视频数据中每路音视频数据的码率，并根据每路音视频数据的码率计算所述多路音视频数据的码率和值。
根据所述接收端的带宽信息确定所述接收端的带宽评估值。
根据设置的所述多路发送端的优先级、所述码率和值、所述带宽评估值和每路音视频数据的码率生成带宽评估结果。
可理解的，根据数据信息确定多路音视频数据中每路音视频数据的码率，也就是接收端要接收每路音视频直播数据需要消耗的带宽，并根据每路音视频数据的码率计算多路音视频数据的码率和值，也就是接收端若要同一时间接收多路音视频数据所要消耗的带宽和值，例如，接收端要接收10路音视频数据，每路音视频数据的码率为10，10路音视频数据的码率和值为100，也就是说，接收端要接收10路音视频数据至少需要具备100码率的带宽资源；根据接收端的带宽信息确定接收端的带宽评估值，也就是确定接收端可用于接收音视频数据的带宽资源；随后，根据设置的多路发送端的优先级、码率和值、带宽评估值和每路音视频数据的码率生成带宽评估结果，带宽评估结果包括上述每路发送端的优先级、码率和值、带宽评估值和每路音视频数据的码率，后续将带宽评估结果发送至连接的服务端中转发控制模块520进行综合决策控制。
S420、将所述带宽评估结果发送至和所述接收端连接的服务端，所述服务端用于通过预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数。
可理解的，在上述S410的基础上，带宽评估模块551将生成的带宽评估结果发送至连接的服务端中转发控制模块520，转发控制模块520会基于带宽评估结果进行综合决策控制生成对应的控制参数，控制参数中包括每路音视频数据流的传输码率和分配的带宽，也就是根据每路音视频数据的实际情况进行带宽分配，决策控制原则为将接收端有限的带宽资源优先用于传输高优先级那路音视频数据，满足高优先级的码率后，再将剩余带宽资源分配至其他路音视频数据。
可选的，服务端中转发控制模块520基于带宽评估结果生成控制参数的实现步骤具体参见下述图6所示的实施例，在此不作赘述。
S430、接收基于所述控制参数进行调整后的多路音视频数据，其中，所述多路音视频数据是由所述服务端连接的多路发送端生成的。
示例性的，在上述S420的基础上，转发控制模块520基于带宽评估结果生成针对每一路音视频数据流的控制参数后，将每一路音视频数据流相关的控制参数发送至该路音视频数据流对应的带宽分配模块530，随后带宽配置模块530根据接收到的控制参数调整接收到的音视频数据的码率并向平滑模块540发送调整后的音视频数据，随后平滑模块540对调整后的多路音视频数据进行平滑处理，随后将平滑处理后的多路音视频数据发送至接收端550，接收端550接收调整后的多路音视频数据并显示，以提高用户体验。
本公开实施例提供的一种音视频数据传输方法，接收端通过预先构建的一个带宽评估模块评估多路音视频数据流的带宽，从而确定接收端当前带宽资源是否支持拉取多路音视频数据，并生成带宽评估结果；随后将带宽评估结果发送至连接的服务端中的一个转发控制模块，转发控制模块基于带宽评估结果进行综合决策控制，为每路音视频数据分配带宽，生成针对每路音视频数据的控制参数，其中优先满足高优先级的发送端发送的音视频数据所需的带宽；接收端接收基于控制参数调整后的多路音视频数据。本公开提供的方法，解决了接收端同时拉多路音视频数据时因带宽资源限制而产生的音视频卡顿问题，能够根据自身不同质量的网络条件，自动评估接收端的可拉流数量，也就是能够对多路音视频数据进行综合评估，避免出现每路音视频数据相互争抢接收端带宽资源的情况，还能够将有限的带宽资源优先用于传输高优先级那路的音视频数据，避免用户错过重要讯息，最大限度的提升用户体验。
在上述实施例的基础上，图6为本公开实施例提供的另一种音视频数据传输方法流程图，应用于和接收端连接的服务端，具体应用于服务端预先构建的一个转发控制模块，也就是上述转发控制模块接收到带宽评估模块生成并发送的带宽评估结果后，基于带宽评估结果生成针对每路音视频数据带宽的控制参数的过程，具体包括如图6所示的如下步骤S610至S620：
S610、接收带宽评估结果，其中，所述带宽评估结果是由所述服务端连接的接收端根据上述音视频数据传输方法生成的。
可选的，带宽评估结果包括所述多路发送端的优先级、所述多路发送端传输的多路音视频数据的码率和值、所述接收端的带宽评估值和所述多路音视频数据中每路音视频数据的码率。
示例性的，转发控制模块520接收由接收端550中带宽评估模块551生成并传输的带宽评估结果。其中，带宽评估结果中包括每路音视频数据的优先级、多路音视频数据的码率和值、反应接收端带宽资源的带宽评估值和每路音视频数据的码率，每路音视频数据的码率是指音视频数据正常传输所需的码率。
S620、利用预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数，并将基于所述控制参数调整后的多路音视频数据发送至所述接收端，其中，所述多路音视频数据是和所述服务端连接的多路发送端生成的。
示例性的，在上述S610的基础上，转发控制模块520根据带宽评估结果生成针对每路音视频数据的控制参数，并将控制参数发送至每路音视频数据流对应的带宽分配模块530，控制参数包括为每路音视频数据分配的带宽，转发控制模块520还会根据带宽评估模块551的带宽评估结果调整丢包重传(NACK)/前向纠错(FEC)逻辑，具体的调整方式不作赘述。其中，对于接收端550(拉流端)来说多路发送端均属于推流端，发送端510会向服务端传输正常码率的音视频数据流，随后服务端会根据控制参数调整传输至接收端550的每路音视频数据流的码率，具体的，每路音视频数据对应的带宽分配模块530会根据接收到的控制参数调整待传输至接收端550的音视频数据的码率，可以是降低发送码率、增加发送码率和保持发送码率等，随后平滑模块540接收调整后的多路音视频数据，并向接收端550传输调整后的多路音视频数据。
可选的，上述S620中利用预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数，具体可以通过下述步骤实现：
根据所述码率和值以及所述带宽评估值确定所述接收端的带宽资源状况，其中，所述带宽资源状况包括带宽资源空闲和带宽资源被过度使用。
根据所述带宽资源状况、所述多路发送端的优先级和每路音视频数据的码率生成控制参数。
示例性的，转发控制模块520根据码率和值以及带宽评估值确定接收端的带宽资源状况，其中，带宽资源状况包括带宽资源空闲和带宽资源被过度使用，若接收端的带宽评估值大于多路音视频数据的码率和值，则说明接收端的带宽资源空闲，也就是说当前带宽资源能够满足多路直播流的带宽消耗，该种情况下可以直接拉取多路音视频数据；若接收端的带宽评估值小于或等于多路音视频数据的码率和值，则说明接收端的带宽资源被过度使用，也就是说当前带宽资源已经不能够满足多路直播流的带宽消耗，需要自动针对每路音视频数据的情况调整拉流策略。随后转发控制模块520在不同的带宽资源状况下，按照不同的预设规则基于多路发送端的优先级和每路音视频数据的码率生成控制参数。
可选的，上述根据所述带宽资源状况、所述多路发送端的优先级和每路音视频数据的码率生成控制参数可以通过下述步骤实现。
若所述带宽资源状况为带宽资源空闲，则按照第一预设规则根据每路音视频数据的码率生成控制参数，其中，所述第一预设规则为满足每路音视频数据的码率；或者，
若所述带宽资源状况为带宽资源被过度使用，则在所述多路发送端中确定优先级大于预设阈值的目标发送端，并按照第二预设规则根据每路音视频数据的码率生成控制参数，其中，所述第二预设规则为优先满足所述目标发送端对应的码率，在满足所述目标发送端对应的码率的情况下，按照预设比例满足除所述目标发送端之外的其他路发送端对应的码率。
示例性的，转发控制模块520在不同资源状态下，生成对应的控制参数的方法如下：若确定的带宽资源状况为带宽资源空闲，则按照第一预设规则根据每路音视频数据的码率生成控制参数，其中，第一预设规则为满足每路音视频数据的码率，也就是说客户端当前带宽资源能够满足多路直播流的带宽消耗，该种情况下可以直接以每路音视频数据的当前所需码率拉取多路音视频数据，若码率和值和带宽评估值的差值的绝对值大于预设数值，也就是在拉取多路音视频数据后，接收端的带宽资源还比较空闲，该种情况下可以增加高优先级那路音视频数据的码率，以提供给用户更好的观看体验；或者，若确定的带宽资源状况为带宽资源被过度使用，也就是说接收端当前带宽资源不能够满足多路音视频数据流的带宽消耗，接收端可能处于弱网环境，该种情况下可以在多路发送端中确定优先级大于预设阈值的目标发送端，每个发送端都存在对应的优先级参数值，例如优先级参数值可以0还可以是1，对于优先级等级为2级的情况，预设阈值可以设置为0，确定优先级参数值大于预设阈值的发送端为目标发送端，随后按照第二预设规则根据每路音视频数据的码率生成控制参数，其中，第二预设规则为优先满足目标发送端对应的码率，也就是优先级最高的那路音视频数据所需要的带宽要100％给足，在满足目标发送端对应的码率的情况下接收端还存在剩余带宽资源，按照预设比例满足除目标发送端之外的其他路发送端对应的码率，也就是接收端的剩余带宽按照预设比例分给其他音视频数据，预设比例可以是5％或者10％，具体比例可根据用户需求自行确定，在此不作限定；还比如，优先级等级设置为3个等级，每个等级的优先级参数值分别设置为2、1和0，预设阈值包括第一子预设阈值和第二子预设阈值，在带宽资源被过度使用的情况下，优先满足优先级参数值大于第一子预设阈值的目标发送端所需的码率，随后直接满足或者按照预设比例满足优先级参数值小于或等于第一子预设阈值且大于第二子预设阈值的目标发送端所需的码率，最后再按照预设比例满足小于或等于第二子预设阈值的发送端所需的码率，其中，第一子预设阈值为1，第二子预设阈值为0；再比如，接收端带宽不能满足优先级最高那路音视频数据所需的码率时，可以将接收端的全部带宽资源分配给优先级最高的那路音视频数据，该种情况下可以根据接收端的带宽评估值降低优先级最高的那路音视频数据的码率。
本公开实施例提供的一种音视频数据传输方法，应用于服务端，服务端接收到接收端发送的带宽评估结果后，采用预先构建的一个转发控制模块基于带宽评估结果进行综合决策控制，根据当前接收端的带宽资源状况自动为每路音视频数据分配对应的带宽，避免出现拉多路音视频数据时因带宽资源有限而产生的音视频卡顿问题，还能够避免出现每路音视频数据流相互争抢带宽资源的情况，其次，在弱网环境下优先考虑高优先级的音视频数据所需的码率，最大限度的提升用户体验。
图7为本公开实施例提供的一种音视频数据传输装置的结构示意图，该装置可以采用软件和/或硬件实现，并可集成在任意具有计算能力的电子设备上。
如图7所示，本公开实施例提供的音视频数据传输装置包括评估单元710、发送单元720和接收单元730，其中：
评估单元710，用于基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果；
发送单元720，用于将所述带宽评估结果发送至和所述接收端连接的服务端，所述服务端用于通过预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数；
接收单元730，用于接收基于所述控制参数进行调整后的多路音视频数据，其中，所述多路音视频数据是由所述服务端连接的多路发送端生成的。
可选的，装置还包括配置单元，配置单元用于在基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果之前，具体用于：
调用预先配置的接口为多路发送端设置优先级，其中，所述接收端和所述多路发送端处于同一个频道。
可选的，评估单元710中基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果，具体用于：
接收由预先构建的一个平滑模块传输的数据信息，其中，所述数据信息是所述平滑模块根据所述多路发送端发送的多路音视频数据的传输信息进行整合得到的；
基于预先构建的一个带宽评估模块，根据设置的所述多路发送端的优先级、所述接收端的带宽信息和所述数据信息生成带宽评估结果。
可选的，评估单元中所述根据设置的所述多路发送端的优先级、所述接收端的带宽信息和所述数据信息生成带宽评估结果，具体用于：
根据所述数据信息确定所述多路音视频数据中每路音视频数据的码率，并根据每路音视频数据的码率计算所述多路音视频数据的码率和值；
根据所述接收端的带宽信息确定所述接收端的带宽评估值；
根据设置的所述多路发送端的优先级、所述码率和值、所述带宽评估值和每路音视频数据的码率生成带宽评估结果。
本公开实施例所提供的音视频数据传输装置可执行本公开实施例所提供的音视频数据传输方法，具备执行方法相应的功能模块和有益效果。本公开装置实施例中未详尽描述的内容可以参考本公开中音视频数据传输方法实施例中的描述。
图8为本公开实施例提供的一种音视频数据传输装置的结构示意图，该装置可以采用软件和/或硬件实现，并可集成在任意具有计算能力的电子设备上。
如图8所示，本公开实施例提供的音视频数据传输装置800可以包括接收单元810和生成单元820，其中：
接收单元810，用于接收带宽评估结果，其中，所述带宽评估结果是由所述服务端连接的接收端根据上述音视频数据传输方法生成的；
生成单元820，用于利用预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数，并将基于所述控制参数调整后的多路音视频数据发送至所述接收端，其中，所述多路音视频数据是和所述服务端连接的多路发送端生成的。
可选的，接收单元810中所述带宽评估结果包括所述多路发送端的优先级、所述多路发送端传输的多路音视频数据的码率和值、所述接收端的带宽评估值和所述多路音视频数据中每路音视频数据的码率。
可选的，生成单元820中所述利用预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数，具体用于：
根据所述码率和值以及所述带宽评估值确定所述接收端的带宽资源状况，其中，所述带宽资源状况包括带宽资源空闲和带宽资源被过度使用；
根据所述带宽资源状况、所述多路发送端的优先级和每路音视频数据的码率生成控制参数。
可选的，生成单元820中所述根据所述带宽资源状况、所述多路发送端的优先级和每路音视频数据的码率生成控制参数，具体用于：
若所述带宽资源状况为带宽资源空闲，则按照第一预设规则根据每路音视频数据的码率生成控制参数，其中，所述第一预设规则为满足每路音视频数据的码率；或者，
若所述带宽资源状况为带宽资源被过度使用，则在所述多路发送端中确定优先级大于预设阈值的目标发送端，并按照第二预设规则根据每路音视频数据的码率生成控制参数，其中，所述第二预设规则为优先满足所述目标发送端对应的码率，在满足所述目标发送端对应的码率的情况下，按照预设比例满足除所述目标发送端之外的其他路发送端对应的码率。
本公开实施例所提供的音视频数据传输装置可执行本公开实施例所提供的音视频数据传输方法，具备执行方法相应的功能模块和有益效果。本公开装置实施例中未详尽描述的内容可以参考本公开中音视频数据传输方法实施例中的描述。
本公开示例性实施例还提供一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器。所述存储器存储有能够被所述至少一个处理器执行的计算机程序，所述计算机程序在被所述至少一个处理器执行时用于使所述电子设备执行根据本公开实施例的方法。
本公开示例性实施例还提供一种计算机程序产品，包括计算机程序，其中，所述计算机程序在被计算机的处理器执行时用于使所述计算机执行根据本公开实施例的方法。
参考图9，现将描述可以作为本公开的服务端或客户端的电子设备900的结构框图，其是可以应用于本公开的各方面的硬件设备的示例。电子设备旨在表示各种形式的数字电子的计算机设备，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务端、刀片式服务端、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
如图9所示，电子设备900包括计算单元901，其可以根据存储在只读存储器(ROM)902中的计算机程序或者从存储单元908加载到随机访问存储器(RAM)903中的计算机程序，来执行各种适当的动作和处理。在RAM 903中，还可存储设备900操作所需的各种程序和数据。计算单元901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。
电子设备900中的多个部件连接至I/O接口905，包括：输入单元906、输出单元907、存储单元908以及通信单元909。输入单元906可以是能向电子设备900输入信息的任何类型的设备，输入单元906可以接收输入的数字或字符信息，以及产生与电子设备的用户设置和/或功能控制有关的键信号输入。输出单元907可以是能呈现信息的任何类型的设备，并且可以包括但不限于显示器、扬声器、视频/音频输出终端、振动器和/或打印机。存储单元904可以包括但不限于磁盘、光盘。通信单元909允许电子设备900通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据，并且可以包括但不限于调制解调器、网卡、红外通信设备、无线通信收发机和/或芯片组，例如蓝牙TM设备、WiFi设备、WiMax设备、蜂窝通信设备和/或类似物。
计算单元901可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元901的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元901执行上文所描述的各个方法和处理。例如，在一些实施例中，音视频数据传输方法或识别网络的训练方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元908。在一些实施例中，计算机程序的部分或者全部可以经由ROM 902和/或通信单元909而被载入和/或安装到电子设备900上。在一些实施例中，计算单元901可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行音视频数据传输方法或识别网络的训练方法。
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务端上执行。
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
如本公开使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。
为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务端)、或者包括中间件部件的计算系统(例如，应用服务端)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。
计算机系统可以包括客户端和服务端。客户端和服务端一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务端关系的计算机程序来产生客户端和服务端的关系。
以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (11)

1.一种音视频数据传输方法，其特征在于，应用于接收端，所述方法包括：
基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果；
将所述带宽评估结果发送至和所述接收端连接的服务端，所述服务端用于通过预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数；
接收基于所述控制参数进行调整后的多路音视频数据，其中，所述多路音视频数据是由所述服务端连接的多路发送端生成的。
2.根据权利要求1所述的方法，其特征在于，在基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果之前，所述方法还包括：
调用预先配置的接口为多路发送端设置优先级，其中，所述接收端和所述多路发送端处于同一个频道。
3.根据权利要求2所述的方法，其特征在于，所述基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果，包括：
接收由预先构建的一个平滑模块传输的数据信息，其中，所述数据信息是所述平滑模块根据所述多路发送端发送的多路音视频数据的传输信息进行整合得到的；
基于预先构建的一个带宽评估模块，根据设置的所述多路发送端的优先级、所述接收端的带宽信息和所述数据信息生成带宽评估结果。
4.根据权利要求3所述的方法，其特征在于，所述根据设置的所述多路发送端的优先级、所述接收端的带宽信息和所述数据信息生成带宽评估结果，包括：
根据所述数据信息确定所述多路音视频数据中每路音视频数据的码率，并根据每路音视频数据的码率计算所述多路音视频数据的码率和值；
根据所述接收端的带宽信息确定所述接收端的带宽评估值；
根据设置的所述多路发送端的优先级、所述码率和值、所述带宽评估值和每路音视频数据的码率生成带宽评估结果。
5.一种音视频数据传输方法，其特征在于，应用于服务端，所述方法包括：
接收带宽评估结果，其中，所述带宽评估结果是由所述服务端连接的接收端根据上述权利要求1至权利要求4中任一所述的方法生成的；
利用预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数，并将基于所述控制参数调整后的多路音视频数据发送至所述接收端，其中，所述多路音视频数据是和所述服务端连接的多路发送端生成的。
6.根据权利要求5所述的方法，其特征在于，所述带宽评估结果包括所述多路发送端的优先级、所述多路发送端传输的多路音视频数据的码率和值、所述接收端的带宽评估值和所述多路音视频数据中每路音视频数据的码率，
所述利用预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数，包括：
根据所述码率和值以及所述带宽评估值确定所述接收端的带宽资源状况，其中，所述带宽资源状况包括带宽资源空闲和带宽资源被过度使用；
根据所述带宽资源状况、所述多路发送端的优先级和每路音视频数据的码率生成控制参数。
7.根据权利要求6所述的方法，其特征在于，所述根据所述带宽资源状况、所述多路发送端的优先级和每路音视频数据的码率生成控制参数，包括：
若所述带宽资源状况为带宽资源空闲，则按照第一预设规则根据每路音视频数据的码率生成控制参数，其中，所述第一预设规则为满足每路音视频数据的码率；或者，
若所述带宽资源状况为带宽资源被过度使用，则在所述多路发送端中确定优先级大于预设阈值的目标发送端，并按照第二预设规则根据每路音视频数据的码率生成控制参数，其中，所述第二预设规则为优先满足所述目标发送端对应的码率，在满足所述目标发送端对应的码率的情况下，按照预设比例满足除所述目标发送端之外的其他路发送端对应的码率。
8.一种音视频数据传输装置，其特征在于，应用于接收端，包括：
评估单元，用于基于预先构建的一个带宽评估模块对所述接收端的带宽进行评估，生成带宽评估结果；
发送单元，用于将所述带宽评估结果发送至和所述接收端连接的服务端，所述服务端用于通过预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数；
接收单元，用于接收基于所述控制参数进行调整后的多路音视频数据，其中，所述多路音视频数据是由所述服务端连接的多路发送端生成的。
9.一种音视频数据传输装置，其特征在于，应用于服务端，包括：
接收单元，用于接收带宽评估结果，其中，所述带宽评估结果是由所述服务端连接的接收端根据上述权利要求1至权利要求4中任一所述的方法生成的；
生成单元，用于利用预先构建的一个转发控制模块根据所述带宽评估结果生成控制参数，将基于所述控制参数调整后的多路音视频数据发送至所述接收端，其中，所述多路音视频数据是和所述服务端连接的多路发送端生成的。
10.一种电子设备，其特征在于，所述电子设备包括：
处理器；以及
存储程序的存储器，
其中，所述程序包括指令，所述指令在由所述处理器执行时使所述处理器执行根据权利要求1至权利要求7中任一所述的音视频数据传输方法。
11.一种存储有计算机指令的非瞬时计算机可读存储介质，其特征在于，所述计算机指令用于使所述计算机执行根据权利要求1至权利要求7中任一所述的音视频数据传输方法。
CN202210626312.8A 2022-06-02 2022-06-02 音视频数据传输方法、装置、电子设备和存储介质 Pending CN115052172A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210626312.8A CN115052172A (zh) 2022-06-02 2022-06-02 音视频数据传输方法、装置、电子设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210626312.8A CN115052172A (zh) 2022-06-02 2022-06-02 音视频数据传输方法、装置、电子设备和存储介质

Publications (1)

Publication Number Publication Date
CN115052172A true CN115052172A (zh) 2022-09-13

Family

ID=83159748

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210626312.8A Pending CN115052172A (zh) 2022-06-02 2022-06-02 音视频数据传输方法、装置、电子设备和存储介质

Country Status (1)

Country Link
CN (1) CN115052172A (zh)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105357208A (zh) * 2015-11-20 2016-02-24 深圳联友科技有限公司 一种多人网络音频会话方法及系统
US20160112673A1 (en) * 2006-08-07 2016-04-21 Oovoo, Llc Video conferencing over ip networks
CN106878230A (zh) * 2015-12-10 2017-06-20 中国电信股份有限公司 网络电话会议中的音频处理方法、服务器以及系统
CN107438031A (zh) * 2017-08-07 2017-12-05 成都三零凯天通信实业有限公司 多信道自适应网络带宽的音视频流传输控制方法及系统
US9894322B1 (en) * 2017-03-08 2018-02-13 Via Technologies, Inc. Video conference system, server and terminal equipment
US10069755B1 (en) * 2016-07-01 2018-09-04 Mastercard International Incorporated Systems and methods for priority-based allocation of network bandwidth
CN110996038A (zh) * 2019-11-19 2020-04-10 清华大学 一种面向多人互动直播的自适应码率调节方法
CN113347450A (zh) * 2021-04-09 2021-09-03 中科创达软件股份有限公司 一种多应用共享音视频设备的方法、装置和系统

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160112673A1 (en) * 2006-08-07 2016-04-21 Oovoo, Llc Video conferencing over ip networks
CN105357208A (zh) * 2015-11-20 2016-02-24 深圳联友科技有限公司 一种多人网络音频会话方法及系统
CN106878230A (zh) * 2015-12-10 2017-06-20 中国电信股份有限公司 网络电话会议中的音频处理方法、服务器以及系统
US10069755B1 (en) * 2016-07-01 2018-09-04 Mastercard International Incorporated Systems and methods for priority-based allocation of network bandwidth
US9894322B1 (en) * 2017-03-08 2018-02-13 Via Technologies, Inc. Video conference system, server and terminal equipment
CN107438031A (zh) * 2017-08-07 2017-12-05 成都三零凯天通信实业有限公司 多信道自适应网络带宽的音视频流传输控制方法及系统
CN110996038A (zh) * 2019-11-19 2020-04-10 清华大学 一种面向多人互动直播的自适应码率调节方法
CN113347450A (zh) * 2021-04-09 2021-09-03 中科创达软件股份有限公司 一种多应用共享音视频设备的方法、装置和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
张宁 等: "多路视频监控信息传输中网络带宽资源利用的优化策略", 中国铁道科学, no. 03, pages 2 *

Similar Documents

Publication Publication Date Title
US11349900B2 (en) Voice encoding and sending method and apparatus
US20080091838A1 (en) Multi-level congestion control for large scale video conferences
US8966095B2 (en) Negotiate multi-stream continuous presence
CN112104904B (zh) 一种多用户同步观看视频和实时互动的方法和系统
US9246973B2 (en) Identifying and transitioning to an improved VoIP session
US20020112244A1 (en) Collaborative video delivery over heterogeneous networks
US20140218464A1 (en) User interface control in a multimedia conference system
US9232244B2 (en) Efficient frame forwarding in large scale real-time screen content sharing meetings
Wang et al. Multilive: Adaptive bitrate control for low-delay multi-party interactive live streaming
Liubogoshchev et al. Adaptive cloud-based extended reality: Modeling and optimization
US20170208105A1 (en) Replaying content of a virtual meeting
Petrangeli et al. Improving quality and scalability of WebRTC video collaboration applications
US9325853B1 (en) Equalization of silence audio levels in packet media conferencing systems
CN113194335B (zh) 流媒体传输方法、传输设备和播放设备
US20210227005A1 (en) Multi-user instant messaging method, system, apparatus, and electronic device
WO2021082479A1 (zh) 调整视频流的属性的方法和装置
WO2022228689A1 (en) Predicted audio and video quality preview in online meetings
CN115052172A (zh) 音视频数据传输方法、装置、电子设备和存储介质
Petrangeli et al. Dynamic video bitrate adaptation for WebRTC-based remote teaching applications
KR20210064222A (ko) 비디오 품질을 유지하면서 비디오 비트 레이트를 향상시키는 기법
CN111951821B (zh) 通话方法和装置
US11632404B2 (en) Data stream prioritization for communication session
Yeo Finding perceptually optimal operating points of a real time interactive video-conferencing system
CN115623249A (zh) 无线投屏的自适应调整方法、移动端、计算机设备和介质
CN118055277A (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