CN109982100A - 一种音视频处理方法和系统 - Google Patents

一种音视频处理方法和系统 Download PDF

Info

Publication number
CN109982100A
CN109982100A CN201910244604.3A CN201910244604A CN109982100A CN 109982100 A CN109982100 A CN 109982100A CN 201910244604 A CN201910244604 A CN 201910244604A CN 109982100 A CN109982100 A CN 109982100A
Authority
CN
China
Prior art keywords
audio
client
time
visual quality
server
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
CN201910244604.3A
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 Chalk Blue Sky Technology Co Ltd
Original Assignee
Beijing Chalk Blue Sky 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 Chalk Blue Sky Technology Co Ltd filed Critical Beijing Chalk Blue Sky Technology Co Ltd
Priority to CN201910244604.3A priority Critical patent/CN109982100A/zh
Publication of CN109982100A publication Critical patent/CN109982100A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N17/00—Diagnosis, testing or measuring for television systems or their details
    • H04N17/004—Diagnosis, testing or measuring for television systems or their details for digital television systems
    • 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/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2385—Channel allocation; Bandwidth allocation
    • 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
    • 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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • 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/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/4424—Monitoring of the internal components or processes of the client device, e.g. CPU or memory load, processing speed, timer, counter or percentage of the hard disk space used
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/6473—Monitoring network processes errors
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

一种音视频处理方法和系统，其中，该方法包括：获取客户端接收到的音视频数据的质量参数；基于所述音视频数据的质量参数，计算得到音视频质量；当所述音视频质量低于音视频质量阈值时，为所述客户端切换服务器。从而能够提升弱网环境下的音视频质量。

Description

一种音视频处理方法和系统
技术领域
本发明属于移动互联网领域，具体涉及一种音视频处理方法和系统。
背景技术
视频直播在最近几年呈现爆发式增长，处于互联网风口。视频直播平台目前应用于游戏和歌舞脱口秀领域较多，视频直播平台因其众多优点，在线上教育和企业商业领域中也得到了很好的应用。以在线教育为例，视频直播平台凭借良好的音视频效果、操作上的简便性以及网络适应的灵活性等，通过“直播+教育”新模式，为互联网教育行业提供了全新的思路，使得教育内容更多样化，教育资源分布更公平化。
在移动互联网盛行的今天，视频直播参与者多数是在移动端，随时随地享受着直播带来的价值。采用手机在多变的网络环境下进行直播已成为常态，在享受到了便捷、实惠和优质教育资源的同时，随之而来的是高丢包、低带宽等因素而导致的直播质量不稳定问题。因此，如何有效地解决在线教育网络质量不稳定，持续不断地为弱网环境下的学员提供较好的直播质量，保障学员的在线听课体验，是当前在线教育领域所面临的一大重点与难点。
为了提升弱网环境的音视频质量，传统的技术方案是采取前向纠错和重传技术，利用发送端重传数据包进行直播质量优化。但该方案存在明显缺陷，即单个数据传输链路如果网络环境较差，不断重传数据包可能会进一步增加网络拥塞，从而适得其反；另外，音视频数据包对时效性要求较高，如果延迟过高，即使收到了音视频数据包但过了播放时间点，对于播放端听直播的用户已经没有意义。
发明内容
(一)发明目的
本发明的目的是提供一种保障音视频质量，且能够节约成本的音视频处理方法和系统。
(二)技术方案
为解决上述问题，本发明的第一方面提供了一种音视频处理方法，包括：获取客户端接收到的音视频数据的质量参数；基于所述音视频数据的质量参数，计算得到音视频质量；当所述音视频质量低于音视频质量阈值时，为所述客户端切换服务器。
进一步地，该方法还包括：在切换了预设次数次服务器，且所述音视频质量仍低于音视频质量阈值时，为所述客户端开启用于传输所述音视频数据的多条链路。
进一步地，所述质量参数包括：时延、丢包率和抖动中的至少一种；其中，基于所述音视频数据的质量参数，计算得到音视频质量，包括：将丢包率和编码器的设备损伤系数Ie输入预先配置的Ie-model模型；所述Ie-model模型基于所述丢包率和所述编码器的设备损伤系数Ie，输出有效设备损伤系数Ie_eff值；将时延输入预先配置的Id-model模型；所述Id-model模型基于所述时延，输出延迟损伤系数Id；将所述有效设备损伤系数Ie_eff值和所述延迟损伤系数Id输入预先配置的E-Model模型；所述E-Model模型基于所述有效设备损伤系数Ie_eff值和所述延迟损伤系数Id，输出R值；基于所述R值计算得到Mos值。
进一步地，对每一客户端，统计预定时间内从服务器接收到的音视频的Mos值，所述MOS值为所述音视频质量的量化结果；生成客户端、服务器和Mos值的对应关系；在接收到所述音视频数据的调用请求时，将所述客户端连接至最大Mos值对应的服务器。
进一步地，所述客户端包括第一客户端和第二客户端；其中，所述第一客户端的所述时延按照如下方程式计算：rttc1＝rtt1*0.5；式中，rttc1为第一客户端的时延，rtt1＝t4-(t1+t2)，t1为第一客户端发送SR包至服务器时的时刻，t2为服务器生成ReportBlock的耗时，t4为第一客户端收到服务器回复的RR包时的时刻。
进一步地，所述客户端包括第一客户端和第二客户端；所述第二客户端的所述时延按照如下方程式计算：rttc2＝(rtt1+rtt2)*0.5+系统内部转发时间；式中，rttc2为第二客户端的时延，rtt1＝t4-(t1+t2)，rtt2＝t6-(t3+t5)，t3为服务器将SR包转发给第二客户端的时刻，t5为第二客户端生成ReportBlock的耗时，t6为服务器收到第二客户端回复的RR包的时刻。
根据本发明的另一个方面，还提供一种音视频处理系统，包括：获取模块，用于获取客户端接收到的音视频数据的质量参数；计算模块，用于基于所述音视频数据的质量参数，计算得到音视频质量；切换模块，用于当所述音视频质量低于音视频质量阈值时，为所述客户端切换服务器。
进一步地，还包括：启动模块，用于在切换了预设次数次服务器，且所述音视频质量仍低于音视频质量阈值时，为所述客户端开启用于传输所述音视频数据的多条链路。
进一步地，所述质量参数包括：时延、丢包率和抖动中的至少一种；其中，所述计算模块，包括：第一输入单元，用于将丢包率和编码器的设备损伤系数Ie输入预先配置的Ie-model模型；所述Ie-model模型，用于基于所述丢包率和所述编码器的设备损伤系数Ie，输出有效设备损伤系数Ie_eff值；第二输入单元，用于将时延输入预先配置的Id-model模型；所述Id-model模型，用于基于所述时延输出延迟损伤系数Id；第三输入单元，用于将所述有效设备损伤系数Ie_eff值和所述延迟损伤系数Id输入预先配置的E-Model模型；所述E-Model模型，用于基于所述有效设备损伤系数Ie_eff值和所述延迟损伤系数Id，输出R值；计算单元，用于基于所述R值计算得到Mos值。
进一步地，该系统还包括：统计模块，用于对每一客户端，统计预定时间内从服务器接收到的音视频的Mos值，所述MOS值为所述音视频质量的量化结果；生成模块，用于生成客户端、服务器和Mos值的对应关系；连接模块，用于在接收到所述音视频数据的调用请求时，将所述客户端连接至最大Mos值对应的服务器。
进一步地，还包括：第一客户端时延计算模块，所述第一客户端时延计算模块对所述时延按照如下方程式计算：rttc1＝rtt1*0.5；式中，rttc1为第一客户端的时延，rtt1＝t4-(t1+t2)，t1为第一客户端发送SR包至服务器时的时刻，t2为服务器生成ReportBlock的耗时，t4为第一客户端收到服务器回复的RR包时的时刻。
进一步地，还包括：第二客户端时延计算模块，所述第二客户端时延计算模块对所述时延按照如下方程式计算：rttc2＝(rtt1+rtt2)*0.5+系统内部转发时间；式中，rttc2为第二客户端的时延，rtt1＝t4-(t1+t2)，rtt2＝t6-(t3+t5)，t3为服务器将SR包转发给第二客户端的时刻，t5为第二客户端生成ReportBlock的耗时，t6为服务器收到第二客户端回复的RR包的时刻。
根据本发明实施例的另一个方面，提供一种非暂态计算机可读存储介质，非暂态计算机可读存储介质存储计算机指令，计算机指令用于使计算机执行上述任一种音视频处理方法。
根据本发明实施例的另一个方面，提供一种计算机程序产品，计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，计算机程序包括程序指令，当程序指令被计算机执行时，使计算机执行上述任一种音视频处理方法。
(三)有益效果
本发明的上述技术方案具有如下有益的技术效果：通过获取客户端接收到的音视频数据的质量参数；基于所述音视频数据的质量参数，计算得到音视频质量；当所述音视频质量低于音视频质量阈值时，为所述客户端切换服务器。进一步地，如果多次切换服务器之后音视频质量仍然较差，则为客户端开启多链路传输，从而提升弱网环境下的音视频质量。
附图说明
图1是本发明实施例一的一种音视频处理方法的流程图；
图2是本发明实施例一的一种音视频处理方法所依赖的硬件架构的示意图；
图3是根据本发明实施例进行音视频处理的效果图；
图4是本发明实施例的基于大数据处理的智能监控平台的系统框架图；
图5是本发明实施例的一种基于大数据处理的智能监控平台的界面展示图；
图6是本发明实施例的音视频帧率监控图；
图7是本发明实施例的房间音频质量指标监控图；
图8是本发明实施例的地域分析图；
图9是本发明实施例的一种电子设备的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明了，下面结合具体实施方式并参照附图，对本发明进一步详细说明。应该理解，这些描述只是示例性的，而并非要限制本发明的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。
本发明实施例为了保障学员在听课时的音视频质量，提升弱网环境下学员的听课体验，提出了一种音视频处理方法，能够实时监控每个直播用户的链路音频质量情况，在检测到用户音视频质量变差的时候能够自动开启多路链接，并在接收端进行多路合并，保障用户的直播体验。基于以上需求，通过实时检测音视频直播过程中的质量参数，并基于算法模型实时计算音视频质量，实时指导客户端自适应地调整选择与服务器的多链路参数，在多变的网络环境始终能持续优化用户的连接。此外，还通过收集大量数据，对数据进行实时、离线分析，不断改善优化策略，充分利用“互联网+”大数据提升在线教育的教学质量，更好的为用户提供优质服务。
本发明实施例在搭建一套实时音视频质量评价系统的基础上，通过自适应调整音频或视频关键帧等音视频数据的连接数以及码率，从而降低直播的整体延时，抖动及丢包，达到持续提升弱网用户音视频直播体验的目的，并通过大数据分析技术手段提供一个全方位的掌握系统长期运行状况并能智能调整及反馈的监控系统。
本发明实施例在推流端和播放端解耦，能根据自身网络状况自适应匹配不同的连接数，并连接不同区域的数据中心，在保证音视频直播质量的条件下降低带宽消耗，具体请参见以下实施例的详细介绍：
图1是本发明实施例一的一种音视频处理方法的流程图。
如图1所示，一种音视频处理方法，包括如下步骤：
S1，获取客户端接收到的音视频数据的质量参数；
具体地，音视频数据的质量参数包括：时延、丢包、抖动、客户端帧率、客户端机器实时CPU信息、客户端机器实时内存使用率和客户端机器核数中的至少一种；
在一个优选的实施例中，通过在服务器和客户端分段计算rtt时间，从而得到时延。避免了音视频数据的质量参数的采集需要服务器和客户端同时打点，但是客户端和服务器参考的ntp时钟难以一致，造成时延计算不准确的问题。
本发明实施例采用实时传输协议(Real-time Transport Protocol，RTP)进行音视频数据包传输，并配合RTP控制协议(Real-time Transport Control Protocol，RTCP)一起使用，其中RTCP协议用于监控服务质量并传送正在进行的会话参与者的相关信息。例如RTCP协议中的发送端报告包(Sender Report，SR)用来使发送端周期性地向所有接收端以多播方式进行报告，而接收端报告包(Receiver Report，RR)用来使接收端周期性地向所有的点以多播方式进行报告。SR包和RR包都包含0至31个接收报告块(Report Blocks)，每个报告块对应一个同步信源标识符(Synchronization source，SSRC)，报告从该SSRC接收数据包的统计信息，如丢包、抖动等，通过SR包和RR包就可以获取丢包率和抖动等质量参数。
其中，时延的计算方式可以通过如下实施方式实现：
rttc1＝rtt1*0.5；式中，rttc1为第一客户端的时延，rtt1＝t4-(t1+t2)，t1为第一客户端发送SR包至服务器时的时刻，t2为服务器生成reportBlock的耗时，t4为第一客户端收到服务器回复的RR包时的时刻；
或者，rttc2＝(rtt1+rtt2)*0.5+系统内部转发时间；式中，rttc2为第二客户端的时延，rtt1＝t4-(t1+t2)，rtt2＝t6-(t3+t5)，t3为服务器将SR包转发给第二客户端的时刻，t5为第二客户端生成reportBlock的耗时，t6为服务器收到第二客户端回复的RR包的时刻。
需要说明的是，本发明实施例中的客户端包括第一客户端和第二客户端。在一个具体的应用场景中，教师作为第一客户端与服务器交互直播课程，学生作为第二客户端与服务器交互听课，但本发明不以此为限，可以是教师端作为第二客户端，学生端作为第一客户端，另外，在以下实施例中，如无特殊说明，客户端均指第一客户端和第二客户端，在该示例中，对时延的计算请参见如下介绍：
教师端作为发言人会定期发送SR包给服务器，汇报教师端的网络状况，并在发送SR包时记录时间t1；
服务器收到SR包后进行逻辑处理，并生成RR包并回复给教师端(RR包里的reportBlock包含生成该reportBlock耗时t2)，然后将该SR包转发给学生端，并记录此刻时间t3；
教师端收到服务器回复的RR包后，记录此刻的时间t4，并按照如下公式计算：rtt1＝t4-(t1+t2)；
学生端收到服务器转发的SR包后进行逻辑处理，并生成RR包并回复给服务器(RR包里的reportBlock包含生成该reportBlock耗时t5)；
服务器收到学生端回复的RR包后进行逻辑处理，并记录此刻时间t6，计算rtt2＝t6-(t3+t5)；
综上，教师端总时延rttc1＝rtt1*0.5；
学生端总时延rttc2＝(rtt1+rtt2)*0.5+系统内部转发时间。
S2，基于音视频数据的质量参数，计算音视频质量；
其中，音视频数据和音视频质量参数是由服务器集群实时采集，音视频数据是转发至学生端进行播放，音视频质量参数用于步骤S2计算直播过程中的音视频质量。
进一步地，可以是将丢包率和编码器的设备损伤系数Ie输入预先配置的Ie-model模型，Ie-model模型基于所述丢包率和所述编码器的设备损伤系数Ie输出有效设备损伤系数Ie_eff值；进一步地，还可以将时延输入预先配置的Id-model模型，Id-model模型基于所述时延，输出延迟损伤系数Id；最后，将所述有效设备损伤系数Ie_eff值和所述延迟损伤系数Id输入预先配置的E-Model，E-Model模型基于所述有效设备损伤系数Ie_eff值和所述延迟损伤系数Id，输出R值；基于所述R值计算得到Mos值并输出，Mos值即作为音视频质量。
本发明实施例是采用音视频质量评价模型来计算音视频质量，可选的，音视频质量评价模型可以选取E-Model模型，如图2所示，E-Model模型基于主观评测，将用户接听和感知语音质量的行为调研并量化，接听到何种级别的语音质量，就得到多少平均主观值MOS。一般情况下，MOS值为4或更高被认为是较好的语音质量，若平均主观值低于3.6，则多数接收者不能满意语音质量。该模型关注数据全面的网络损伤因素，如时延、噪声、回音和丢包等，可较好地适应在数据网络中的质量评估。本发明实施例在E-Model模型基础上，结合webrtc框架提供的实时抖动缓冲大小变化，综合计算得到音视频质量MOS值，能够更真实地反应出用户接收到的音视频质量，计算粒度在秒级别。
E-Model模型对于R值的计算过程采用如下方程式：R＝R0-Is-Id-Ie_eff-Ijitter+A(其中jitter根据webrtc的JITTER BUFFER大小，由数学公式计算得到)，最后根据R值计算得到MOS值。其中，Ijitter＝s6T6+s5T5+s4T4+s3T3+s2T2+s1T+s0，其中，T＝In(1+tj)，tj为抖动缓冲区的大小，单位为ms；s0-s8均为常数，对于G.711PCM编码ulaw来说，常数取值为：s6＝-0.1465；s5＝3.3877；s4＝-30.9436；s3＝139.0633；s2＝-305.0000；s1＝257.2308；s0＝24.766；
式中，R0是基本信噪比，包括噪声源诸如电路噪声和室内噪声。系数Is是大体上与声音信号同时出现的所有损伤的组合。系数Id代表由延迟引起的损伤，有效设备损伤系数Ie_eff代表由低比特率编解码产生的损伤，也包含由于随机分布的信息包丢失带来的损伤。获益系数A是在有其他优势引入用户时使损伤系数得到补偿。
其中，基本信噪比R0采用如下方程式计算：Ro＝15-1.5(SLR+No)；式中，SLR是发送响度等级，No是各个噪声源的功率和，Nc是所有电路噪声的功率和，全部以0dBr点为参考，Nos是由发送侧室内噪声Ps引起的在0dBr点的等效电路噪声，Nos＝Ps-SLR-Ds-100+0.004(Ps-OLR-Ds-14)2，其中，Ps为发送侧室内噪声，Ds为发送侧电话的D值，OLR＝SLR+RLR，SLR是发送响度等级，RLR是接收响度等级，按照相同的方法，在接收侧的室内噪声Pr被转换为一个在0dBr点的等效电路噪声Nor，Nor＝RLR-121+Pre+0.008(Pre-35)2，Pre是由接收侧音视频通道引起的Pr增强产生的有效室内噪声，其中，LSTR是受话器侧音等级，Nfo代表接收侧的噪声基底，Nfo＝Nfor+RLR，Nfor通常设定为-64dBmp。
其中，Is是与音视频传输大体上同时出现的所有损伤的和，Is＝Iolr+Ist+Iq；
Iolr代表由于OLR值太低引起的质量下降，并由下式给出：其中，Xolr＝OLR+0.2(64+No-RLR)；
Ist代表由非最佳侧音引起的损伤：
其中，其中，STMR是侧音掩蔽等级，T是回声通道的平均单向延迟，TELR是扬声器回声强度等级；
损伤系数Iq代表量化失真产生的损伤：Iq＝15log[1+10Y+10Z]，
其中，G＝1.07+0.258Q+0.0602Q2，Q＝37-15log(qdu)；
需要说明的是，本发明实施例中的qdu代表量化失真单元数量，是指在发送侧和接收侧之间整个连接的qdu的数量，假设损伤系数Ie被用于一部分设备，则对于那个同一部分的设备就一定不使用qdu值。
延迟损伤系数Id代表的是由音视频信号延迟引起的所有损伤，其表达式具体为：Id＝Idte+Idle+Idd；式中，Idte是扬声器回声引起的损伤，表达式为：
其中，Roe＝-1.5(No-RLR)，
Re＝80+2.5(TERV-14)；
式中，TELR是扬声器回声强度等级；
对于T＜1ms的值，将认为扬声器回声是侧音，即Idte＝0。进一步将计算算法结合为STMR对扬声器回声的影响。考虑到STMR的值低，对扬声器回声可能具有一些掩蔽效应，对于很高的STMR值，扬声器回声变得更显著，TERV和Idte调整如下：
对于STMR＜9dB；在Re＝80+2.5(TERV-14)中，采用TERVs取代TERV，而
对于9dB≤STMR≤20dB，可以采用系数Idte的表达式来进行计算；
对于STMR＞20dB，在Id＝Idte+Idle+Idd的表达式中，可以采用Idtes来将Idte代替，其中，系数Idle代表由于接收侧回声引起的损伤，其公式是：其中，Rle＝10.5(WEPL+7)(Tr+1)-0.25，其中，WEPL表示加权回声通道损耗，Tr表示4线环往返行程延迟；
系数Idd代表由于绝对延迟Ta太长带来的损伤，即使使用良好的回声消除手段绝对延迟还是存在；
对于Ta≤100ms，Idd＝0；
对于Ta＞100ms，
而
采用低比特率编解码单元的设备损伤系数Ie的值与其他输入参数无关，他们取决于主观平均意见评分和对网络的经验。工作在随机信息包丢失情况下编解码的特定损伤系数值以前采用信息包丢失与Ie值的关系表来处理，现在，将信息包丢失强度系数Bpl定义为编解码的特定值。利用零信息包丢失时编解码特定的设备损伤系数Ie之值和信息包丢失强度系数Bpl，推导出信息包丢失相关的有效设备损伤系数Ie_eff：
其中，BurstR是突发比，Ppl是随机信息包丢失概率，Bpl是信息包丢失强度系数，
当信息包随机丢失(即不相关)时BurstR＝1，以及
当信息包突发丢失(即相关)时BurstR＞1。
例如，对于符合2种状态的Markov模型的信息包丢失分布，具有“发现”和“丢失”状态间的转移概率p以及“发现”和“丢失”状态间q，BurstR计算为：
需要注意的是，在Ppl＝0(没有信息包丢失)的情况有效设备损伤系数等于Ie值。
对于获益系数A，其与所有其他传输参数无关，下面通过表1给出一些暂定值：
表1获益系数A的暂定值
通信系统示例 A的最大值
常规系数(有线) 0
建筑物内蜂窝网络移动系统 5
地区内或运动的车辆中的移动系统 10
难于达到的地区的接入，例如：经多跳中继的卫星连接 20
S3，当所述音视频质量低于音视频质量阈值时，为所述客户端切换服务器。
具体地，步骤S3可以是多次为客户端切换服务器，即在第一次为客户端切换服务器后，如果发现音视频质量仍然低于音视频质量阈值，则可以继续为客户端切换其他区域的服务器，如此经过预设次数，例如3次或者4次切换其他区域服务器后，音视频质量仍然低于音视频质量阈值，即在切换了预设次数次服务器，且所述音视频质量仍低于音视频质量阈值时，则可以为所述客户端开启用于传输所述音视频数据的多条链路。
此外，在步骤S1之前，还可以包括如下步骤：对每一客户端，统计预定时间内从服务器接收到的音视频的Mos值，所述MOS值为所述音视频质量的量化结果；生成客户端、服务器和Mos值的对应关系；在接收到所述音视频数据的调用请求时，将所述客户端连接至最大Mos值对应的服务器。
请继续参阅图2，结合硬件架构对本发明实施例一的整体流程进行说明，即用户认证成功并进入系统后，Dispatcher集群根据用户IP地址等信息为其分配初始服务器，用户连接服务器在线听课，听课期间通过客户端定时上报信息至消息队列(Message Queue，MQ)，同时服务器集群实时采集用户的音视频数据，利用Flume将数据上传至MQ，然后利用Storm对数据进行实时处理，计算得到用户的实时音视频质量并量化为MOS值，该MOS值一方面用于监控平台显示，另一方面存入MongoDB数据库，供Dispatcher集群优化客户端接入服务器的策略。在检测到用户所连接区域服务器的房间音视频质量普遍较差时，自动为用户更换为其他区域的服务器；并在检测到用户网络质量持续较差时为其开启多链路，通过多路链接提升音视频质量，保障用户在弱网环境下的听课体验。
在一个具体的应用场景中，本发明实施例的流程可以包括如下步骤：
初始化：老师A登录直播平台。平台根据一个月内的后台大数据分析结果，发现该用户在登录北京区域的服务器1时，MOS值最高。因此平台为其初始分配北京区域的音视频服务器。老师A将音频数据发到服务器端，并经由系统转发给学生端。系统每5s钟计算一次老师A的音频质量MOS值。
侦测1：直播平台检测到老师A的实时MOS值持续偏低，最低接近3.0，音频质量变差。
优化1：监控平台对不同区域和运营商的直播质量进行分析，发现此时广州区域的平均MOS值最高(多个房间和用户的平均值)，并且服务器压力处于可承受范围之内。因此通知客户端切换至广州区域的服务器3。
侦测2：切换后短时间内MOS值有好转，但随后又出现降低并震荡。
优化2：根据系统优化算法，老师A达到开启双路音频触发条件，系统为老师A开启双路，客户端同时向北京和广州两个区域的服务器发送两路音频包，并在服务器端或客户端合并播放。之后重新计算整个教室的MOS值，发现双路音频较好地解决了单路音频存在的丢包和抖动，音频质量好转并保持稳定。
通过本实例可以看到，本系统的自适应路由算法很好地解决了在线教育直播中存在的网络抖动、延迟等用户网络环境多变的问题。在两个单路网络都比较差的情况下，通过自适应调整服务器连接获得了较好的音频质量。
请参阅图3，是根据本发明上述示例进行音视频处理的效果图，从图中可以看到，经过两次优化后，音视频质量明显趋于稳定。
在本发明的另一个实施例中，还可以基于大数据进行音视频质量的实时监控和优化，请参阅图4，包括直播监控、业务分析、教学体系反馈优化三部分。主要包括数据采集、数据加工、数据处理分析以及平台反馈。通过大数据实时和离线计算技术，对客户端、后台的日志以及数据库中存放数据进行深入分析。
数据源部分，通过前端埋点、后台定制日志信息、以及数据库中存放的业务数据，精准全面记录多维度数据，为后续分析提供数据基础。
数据采集部分，将各个渠道产生的数据做采集汇总，并分发到实时和离线系统。其中实时系统通过消息队列Kafka对接，离线系统通过Flume将数据写入HDFS文件系统进行对接，并通过DataX将数据库数据同步到离线HDFS。
数据处理分为实时和离线两部分，实时部分主要负责直播系统、用户系统中的实时反馈，并在发现问题后及时作出对应调整，实时部分主要通过Storm/Flink技术框架实现，可以承担十万甚至百万QPS数据量，计算结果根据需求写入到Redis、Hbase、MongoDB和MySQL中。离线部分按小时和天级别进行数据加工，将数据整合并进行维度分析，对每个用户分析其学习情况，对于状况异常的用户分析当前可能出现的问题，给出建议。另一方面分析教学内容，根据日志具体信息去看哪个环节有问题，如什么地方用户暂停回看数较多或用户离开较多，分析问题后期优化整个流程及教学内容，最终结果写入到HDFS、MySQL、HBase中。
最终结果作用到三个平台：第一个是直播监控平台，用来监控当前所有直播课、回放课的上课音视频质量，每个用户的听课质量，在出现异常时及时报警通知直播系统，然后直播系统进行智能调整，减少对用户听课的影响。第二个是直接作用到应用平台，一种情况是反馈给用户，通知用户学习可能出现的问题以及改进方法；另一种情况是实时反馈给教师当前上课情况，哪里出现问题可以及时调整。第三个是BI系统，用来分析用户及内部系统各个环节，充分体现在线教育的优势，线下课如果学生人数较多，教师很难知道每个人的学习程度，但在线教育可以通过分析每个用户的数据去分析用户学习情况，还可以通过数据了解课程效果，对教学过程中存在的问题调整优化，BI系统可以通过多维度定制分析，去看教学系统做的每一次改进的效果，是否对学员的学习起到了预期作用。具体可参见图5至图8的介绍：
图5是实时监控平台的页面，用于监控当前所有房间状态，包括：用于唯一识别的房间ID、房间名称、开课时间、房间状态(包括INIT、RUNNING、STOPPING、STOPPED四种状态，其中INIT表示已建课但老师尚未开课；RUNNING表示正在上课；STOPPING表示已下课，系统正在同步信息；STOPPED表示已下课且信息同步完成)，用于唯一识别的老师ID、老师名称、老师是否在房间、用户数量、音频质量(即利用E-Model计算得到的MOS值，MOS值＝0表示老师未发言，MOS值＝-1表示当前房间没有学生)和所在group(共有两个完全独立的group，例如在对group1进行上线更新时，把所有房间及客户端分配至group2，不影响上课)。
图6是发言人音视频帧率图，用于反应发言人的帧率，包括音频帧率和视频帧率。
图7是房间音频质量指标，纵轴是MOS值，横轴是时间，用于实时监控当前每个房间的音视频质量，并保存历史数据，历史数据用于历史查询和其他离线分析；另外，还有教师端音视频质量监控图(包括MOS值图，网络抖动图、丢包图、时延图)、教师端设备信息图(cpu占用率图、内存占用率图)。
图8是地域分析图，用于实时监控当前房间的客户端分布在全国哪个城市，每个城市各有几名学生；并保存历史数据，用于历史查询和其他离线分析。
本发明实施例通过实时检测音视频直播基础数据，并基于E-Model模型实时计算音视频质量，实时指导客户端自适应地调整选择不同区域的服务器，并能够在检测到用户音视频质量持续低下时自动为其开启多链路，在多变的网络环境下始终能持续优化用户的连接，保证直播质量。
另外，由于多数用户上课的IP地址都具有局部稳定性，因此本发明实施例还通过对数据进行收集、清洗与计算，对每个用户进行统计分析，得到该用户在某一IP段使用某一运营商(以及用WIFI或4G)链接某一区域的服务器时音频质量最好。基于后台大数据的分析指导，在用户刚接入系统时就尽量提供最好的音频质量服务。并且随着时间的推移，即使网络环境发生了变化，大数据监控平台也能提供持续的监控和优化，从而制定音视频质量等指标的优化策略。通过“互联网+”大数据手段来解决在线教育系统不稳定等弊端，能够及时发现产品质量、教育质量等问题，可实现实时数据监控与实时优化；也可以结合历史数据分析出问题，智能调优，为学员提供更稳定的学习平台，更优质适合的教学内容，节约用户时间、金钱成本。
需要说明的是，本发明一种音视频处理系统是与涉及计算机程序流程的一种音视频处理方法一一对应的系统，由于在前已经对一种音视频处理方法的步骤流程进行了详细描述，在此不再对一种音视频处理系统的实施过程进行赘述。
本发明实施例还提供了一种非暂态计算机可读存储介质，非暂态计算机可读存储介质存储计算机指令，计算机指令用于使计算机执行上述任一个实施例的方法。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
如图9所示，一种执行前述方法的电子设备，包括一个或多个处理器901以及与一个或多个处理器通信连接的存储器902，图9中以一个处理器为例。
电子设备还可以包括：输入装置903和输出装置904，输入装置903用于输入获取的至少一个音视频数据，输出装置904用于输出确定的与客户端连接的其他服务器的指令信息。
处理器901、存储器902、输入装置903和输出装置904可以通过总线或者其他方式连接，图9中以通过总线连接为例。
存储器902作为一种非暂态计算机可读存储介质。可用于存储非暂态软件程序、非暂态计算机可执行程序，如本发明实施例中的一种音视频处理方法对应的软件程序、指令以及模块。处理器901通过运行存储在存储器902中的非暂态软件程序、指令以及模块，执行一种音视频处理系统的各种功能应用以及数据处理，即实现上述方法实施例的方法步骤。
存储器902可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据一种音视频处理系统的使用所创建的数据等。此外，存储器902可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件，闪存器件、或其他非暂态固态存储器件。在一些实施例中，存储器902可选包括相对于处理器901远程设置的存储器，这些远程存储器可以通过网络连接至一种任务处理系统。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
输入装置903可接收输入的至少一个音视频数据，以及产生与输入的音视频数据的音视频处理系统的用户设置以及功能控制有关的键信号输入。输入装置903可以包括触摸屏、键盘等，也可以包括有线接口、无线接口等。输出装置904可包括显示屏等显示设备。
一个或多个软件程序、指令存储在存储器902中，当被一个或多个处理器901执行时，执行上述任意方法实施例中的一种音视频处理方法。
在本发明实施例中，一个或多个处理器能够：执行前述任一实施方式的一种音视频处理方法。
应当理解的是，本发明的上述具体实施方式仅仅用于示例性说明或解释本发明的原理，而不构成对本发明的限制。因此，在不偏离本发明的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。此外，本发明所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。

Claims (10)

1.一种音视频处理方法，其特征在于，包括：
获取客户端接收到的音视频数据的质量参数；
基于所述音视频数据的质量参数，计算得到音视频质量；
当所述音视频质量低于音视频质量阈值时，为所述客户端切换服务器。
2.根据权利要求1所述的一种音视频处理方法，其特征在于，还包括：
在切换了预设次数次服务器，且所述音视频质量仍低于音视频质量阈值时，为所述客户端开启用于传输所述音视频数据的多条链路。
3.根据权利要求1所述的一种音视频处理方法，其特征在于，所述质量参数包括：时延、丢包率和抖动中的至少一种；
其中，基于所述音视频数据的质量参数，计算得到音视频质量，包括：
将丢包率和编码器的设备损伤系数Ie输入预先配置的Ie-model模型；
所述Ie-model模型基于所述丢包率和所述编码器的设备损伤系数Ie，输出有效设备损伤系数Ie_eff值；
将时延输入预先配置的Id-model模型；
所述Id-model模型基于所述时延，输出延迟损伤系数Id；
将所述有效设备损伤系数Ie_eff值和所述延迟损伤系数Id输入预先配置的E-Model模型；
所述E-Model模型基于所述有效设备损伤系数Ie_eff值和所述延迟损伤系数Id，输出R值；
基于所述R值计算得到Mos值。
4.根据权利要求3所述的一种音视频处理方法，其特征在于，
对每一客户端，统计预定时间内从服务器接收到的音视频的Mos值，所述MOS值为所述音视频质量的量化结果；
生成客户端、服务器和Mos值的对应关系；
在接收到所述音视频数据的调用请求时，将所述客户端连接至最大Mos值对应的服务器。
5.根据权利要求1所述的一种音视频处理方法，其特征在于，所述客户端包括第一客户端和第二客户端；
其中，所述第一客户端的所述时延按照如下方程式计算：
rttc1＝rtt1*0.5；
式中，rttc1为第一客户端的时延，rtt1＝t4-(t1+t2)，t1为第一客户端发送SR包至服务器时的时刻，t2为服务器生成ReportBlock的耗时，t4为第一客户端收到服务器回复的RR包时的时刻。
6.根据权利要求1所述的一种音视频处理方法，其特征在于，所述客户端包括第一客户端和第二客户端；
所述第二客户端的所述时延按照如下方程式计算：
rttc2＝(rtt1+rtt2)*0.5+系统内部转发时间；
式中，rttc2为第二客户端的时延，rtt1＝t4-(t1+t2)，rtt2＝t6-(t3+t5)，t3为服务器将SR包转发给第二客户端的时刻，t5为第二客户端生成ReportBlock的耗时，t6为服务器收到第二客户端回复的RR包的时刻。
7.一种音视频处理系统，其特征在于，包括：
获取模块，用于获取客户端接收到的音视频数据的质量参数；
计算模块，用于基于所述音视频数据的质量参数，计算得到音视频质量；
切换模块，用于当所述音视频质量低于音视频质量阈值时，为所述客户端切换服务器。
8.如权利要求7所述的一种音视频处理系统，其特征在于，还包括：
启动模块，用于在切换了预设次数次服务器，且所述音视频质量仍低于音视频质量阈值时，为所述客户端开启用于传输所述音视频数据的多条链路。
9.一种计算机存储介质，其特征在于，所述存储介质上存储有计算机程序，所述程序被处理器执行时实现权利要求1-6中任意一项所述一种音视频处理方法的步骤。
10.一种电子设备，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1-6中任意一项所述一种音视频处理方法的步骤。
CN201910244604.3A 2019-03-28 2019-03-28 一种音视频处理方法和系统 Pending CN109982100A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910244604.3A CN109982100A (zh) 2019-03-28 2019-03-28 一种音视频处理方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910244604.3A CN109982100A (zh) 2019-03-28 2019-03-28 一种音视频处理方法和系统

Publications (1)

Publication Number Publication Date
CN109982100A true CN109982100A (zh) 2019-07-05

Family

ID=67081313

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910244604.3A Pending CN109982100A (zh) 2019-03-28 2019-03-28 一种音视频处理方法和系统

Country Status (1)

Country Link
CN (1) CN109982100A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112135119A (zh) * 2020-09-11 2020-12-25 上海七牛信息技术有限公司 实时音视频通信中网络状况的自动监测与告警方法及系统
CN112565057A (zh) * 2020-11-13 2021-03-26 广州市百果园网络科技有限公司 一种可扩展业务的语聊房服务方法及装置
CN113992639A (zh) * 2021-09-29 2022-01-28 阿里巴巴达摩院(杭州)科技有限公司 音视频处理方法及设备
CN114553616A (zh) * 2022-01-12 2022-05-27 广州市迪士普音响科技有限公司 一种会议单元的音频传输方法、装置、系统及终端设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1996897A (zh) * 2005-12-28 2007-07-11 中兴通讯股份有限公司 一种在rtp中实时检测网络传输时延的方法
CN104506387A (zh) * 2014-12-26 2015-04-08 大连理工大学 一种评估lte通信系统语音质量的方法
CN104954866A (zh) * 2015-06-19 2015-09-30 杭州施强网络科技有限公司 一种流媒体数据直播中播放点动态控制方法
CN105392020A (zh) * 2015-11-19 2016-03-09 广州华多网络科技有限公司 一种互联网视频直播方法，及系统
US20180270288A1 (en) * 2016-02-29 2018-09-20 Tencent Technology (Shenzhen) Company Limited Voice encoding and sending method and apparatus

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1996897A (zh) * 2005-12-28 2007-07-11 中兴通讯股份有限公司 一种在rtp中实时检测网络传输时延的方法
CN104506387A (zh) * 2014-12-26 2015-04-08 大连理工大学 一种评估lte通信系统语音质量的方法
CN104954866A (zh) * 2015-06-19 2015-09-30 杭州施强网络科技有限公司 一种流媒体数据直播中播放点动态控制方法
CN105392020A (zh) * 2015-11-19 2016-03-09 广州华多网络科技有限公司 一种互联网视频直播方法，及系统
US20180270288A1 (en) * 2016-02-29 2018-09-20 Tencent Technology (Shenzhen) Company Limited Voice encoding and sending method and apparatus

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112135119A (zh) * 2020-09-11 2020-12-25 上海七牛信息技术有限公司 实时音视频通信中网络状况的自动监测与告警方法及系统
CN112565057A (zh) * 2020-11-13 2021-03-26 广州市百果园网络科技有限公司 一种可扩展业务的语聊房服务方法及装置
CN112565057B (zh) * 2020-11-13 2022-09-23 广州市百果园网络科技有限公司 一种可扩展业务的语聊房服务方法及装置
CN113992639A (zh) * 2021-09-29 2022-01-28 阿里巴巴达摩院(杭州)科技有限公司 音视频处理方法及设备
CN113992639B (zh) * 2021-09-29 2024-04-05 杭州阿里云飞天信息技术有限公司 音视频处理方法及设备
CN114553616A (zh) * 2022-01-12 2022-05-27 广州市迪士普音响科技有限公司 一种会议单元的音频传输方法、装置、系统及终端设备
CN114553616B (zh) * 2022-01-12 2023-11-24 广州市迪士普音响科技有限公司 一种会议单元的音频传输方法、装置、系统及终端设备

Similar Documents

Publication Publication Date Title
CN109982100A (zh) 一种音视频处理方法和系统
US10516718B2 (en) Platform for multiple device playout
JP7230008B2 (ja) リアルタイムオーディオおよびデータを提供するためのシステムおよび方法
CN103957216B (zh) 基于音频信号特性分类的无参考音频质量评价方法和系统
CN101523916B (zh) 确定视频质量的方法
CN102226944B (zh) 混音方法及设备
CN102868666A (zh) 基于用户体验交互的流媒体质量监测报告的实现方法
CN110248204A (zh) 一种直播缓存的处理方法、装置、设备和存储介质
CN102413379B (zh) 流媒体直播系统启动时延方法
CN103354618A (zh) 一种基于hls的多场景流媒体自适应直播方法
JP2010016662A (ja) メディアストリームの階層数を制御する送信装置、方法及びプログラム
CN102665131A (zh) 一种网络视频服务系统接收端的视频缓冲方法
CN108234790A (zh) 多人语音通信方法、装置、终端设备和存储介质
US20230138038A1 (en) Reinforcement learning for jitter buffer control
CN102088623A (zh) 一种自适应网络下载调度系统和方法
CN104683866A (zh) 一种接收视频流的播放处理方法
CN106973253A (zh) 一种调整媒体流传输的方法及装置
CN202759552U (zh) 一种基于ip网络的多终端视频同步播放的系统
CN110324565A (zh) 音频输出方法、装置、会议主机、存储介质及电子装置
JP4460506B2 (ja) ユーザ体感品質推定装置、方法、およびプログラム
CN107205159B (zh) 网络直播中流媒体的比特率调整方法、装置和存储介质
CN104813303B (zh) 回放同步
CN107113283A (zh) 在低延迟多媒体流式传输环境中处理有问题的模式的方法
WO2020068218A1 (en) Increasing video bit rates while maintaining video quality
CN107517401B (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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20190705