CN112822521A - 音视频传输的码率控制方法、装置、设备及存储介质 - Google Patents

音视频传输的码率控制方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN112822521A
CN112822521A CN202011643196.8A CN202011643196A CN112822521A CN 112822521 A CN112822521 A CN 112822521A CN 202011643196 A CN202011643196 A CN 202011643196A CN 112822521 A CN112822521 A CN 112822521A
Authority
CN
China
Prior art keywords
code rate
time length
data
sent
client
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
CN202011643196.8A
Other languages
English (en)
Other versions
CN112822521B (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.)
Bigo Technology Pte Ltd
Original Assignee
Bigo Technology Pte 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 Bigo Technology Pte Ltd filed Critical Bigo Technology Pte Ltd
Priority to CN202011643196.8A priority Critical patent/CN112822521B/zh
Publication of CN112822521A publication Critical patent/CN112822521A/zh
Application granted granted Critical
Publication of CN112822521B publication Critical patent/CN112822521B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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
    • 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 encoded video stream packets from an IP 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明实施例公开了音视频传输的码率控制方法、装置、设备及存储介质。其中，该方法包括：接收客户端反馈的播放情况信息，其中，播放情况信息包括所述客户端已接收且未播放的音视频数据对应的待播放时长以及最后播放帧的时间戳，根据播放情况信息估算客户端的接收码率，确定音视频数据的发送情况信息，根据播放情况信息、客户端的接收码率和发送情况信息确定音视频数据传输的码率控制方式。本发明实施例提供的技术方案，参考多个维度的信息进行综合评估，可以更加合理地控制音视频传输的码率，进而更好地兼顾音视频播放的流畅性以及音视频播放的质量。

Description

音视频传输的码率控制方法、装置、设备及存储介质
技术领域
本发明实施例涉及音视频传输的码率控制技术领域，尤其涉及音视频传输的码率控制方法、装置、设备及存储介质。
背景技术
随着多媒体信息技术的不断发展，音视频信息大量涌现。音视频作为一种表达信息的综合媒体，已成为现实生活中一个重要的信息载体。
音视频数据中通常包含了大量的图像以及声音信息，在一些应用场景中，在进行音视频传输时，通常需要对音视频数据进行编码，而由于实际场景中网络情况存在差异，为了兼顾音视频播放的流畅性以及音视频播放的质量，一般会根据实际情况选择不同档位的码率，并进行相应码率的音视频流的传输。
目前，音视频数据播放侧的客户端应用程序(Application，APP)一般提供多种码率档位供用户选择，码率越高，清晰度越高，对网络带宽和稳定性要求也更高。用户自己手动选择码率的操作通常都是在卡顿发生后进行，如调低码率档位，有时用户的带宽可以支持更高的码率，可以有更高清晰度的观看体验，但是为了防止网络状况突变时产生卡顿，很多用户保守地选择了更低的码率档位，这种方式既没有充分利用用户的网络带宽，也降低了用户的观看体验。
为了进一步提高用户体验，当前已经有部分APP提供了自适应码率的功能。自适应码率就是通过采用某种算法，自动为用户选择合适的码率，在减少卡顿的同时，尽可能选择更高的码率，为用户提供更好的画质，从而提升用户体验。现有技术中，码率切换的决策方式通常是基于带宽的方法，根据发送音视频数据时采用的拥塞控制算法探测到的网络带宽情况切换到对应码率，然而在复杂多变的网络环境中，仅仅通过拥塞控制算法探测到准确的带宽是非常困难的，带宽估计不准确会导致这类方法效果不佳。
综上，目前音视频传输的码率控制方案仍不够完善，需要改进。
发明内容
本发明实施例提供了音视频传输的码率控制方法、装置、设备及存储介质，可以优化现有的音视频传输的码率控制方案。
第一方面，本发明实施例提供了一种音视频传输的码率控制方法，应用于音视频传输***中的服务端，所述方法包括：
接收客户端反馈的播放情况信息，其中，所述播放情况信息包括剩余可播时长以及最后播放帧的时间戳，所述剩余可播时长包括所述客户端已接收且未播放的音视频数据对应的待播放时长；
根据所述播放情况信息估算所述客户端的接收码率；
确定音视频数据的发送情况信息；
根据所述播放情况信息、所述客户端的接收码率和所述发送情况信息确定音视频数据传输的码率控制方式。
第二方面，本发明实施例提供了一种音视频传输的码率控制装置，配置于音视频传输***中的服务端，所述装置包括：
播放情况信息接收模块，用于接收客户端反馈的播放情况信息，其中，所述播放情况信息包括剩余可播时长以及最后播放帧的时间戳，所述剩余可播时长包括所述客户端已接收且未播放的音视频数据对应的待播放时长；
接收码率估算模块，用于根据所述播放情况信息估算所述客户端的接收码率；
发送情况信息确定模块，用于确定音视频数据的发送情况信息；
码率控制模块，用于根据所述播放情况信息、所述客户端的接收码率和所述发送情况信息确定音视频数据传输的码率控制方式。
第三方面，本发明实施例提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如本发明实施例提供的音视频传输的码率控制方法。
第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明实施例提供的音视频传输的码率控制方法。
本发明实施例中提供的音视频传输的码率控制方案，应用于音视频传输***中的服务端，接收客户端反馈的播放情况信息，其中，播放情况信息包括剩余可播时长以及最后播放帧的时间戳，剩余可播时长包括客户端已接收且未播放的音视频数据对应的待播放时长，根据播放情况信息估算所述客户端的接收码率，确定音视频数据的发送情况信息，根据播放情况信息、客户端的接收码率和发送情况信息确定音视频数据传输的码率控制方式。通过采用上述技术方案，参考多个维度的信息进行综合评估，可以更加合理地控制音视频传输的码率，进而更好地兼顾音视频播放的流畅性以及音视频播放的质量。
附图说明
图1为本发明实施例提供的一种音视频传输的码率控制方法的流程示意图；
图2为本发明实施例提供的一种服务端与客户端交互过程示意图；
图3为本发明实施例提供的又一种音视频传输的码率控制方法的流程示意图；
图4为本发明实施例提供的一种视频流状态示意图；
图5为本发明实施例提供的又一种视频流状态示意图；
图6为本发明实施例提供的再一种视频流状态示意图；
图7为本发明实施例提供的另一种音视频传输的码率控制方法的流程示意图；
图8为本发明实施例提供的再一种音视频传输的码率控制方法的流程示意图；
图9为本发明实施例提供的一种音视频传输的码率控制装置的结构框图；
图10为本发明实施例提供的一种计算机设备的结构框图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。此外，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。
图1为本发明实施例提供的一种音视频传输的码率控制方法的流程示意图，该方法可以由音视频传输的码率控制装置执行，其中该装置可由软件和/或硬件实现，一般可集成在服务器等计算机设备中。本发明实施例提供音视频传输的码率控制方法可以适用于多种音视频传输场景，包括但不限于如互联网中的音视频直播、音视频点播、视频通话、语音通话、视频会议、语音会议、远程医疗以及远程教育等多种涉及到音视频传输的应用场景。音视频传输场景中可将发送端和接收端构成的***称为音视频传输***，本发明实施例的技术方案应用于音视频传输***中负责音视频数据发送的服务端，接收端作为音视频数据的播放端被称为客户端。
如图1所示，该方法包括：
步骤101、接收客户端反馈的播放情况信息，其中，所述播放情况信息包括剩余可播时长以及最后播放帧的时间戳，所述剩余可播时长包括所述客户端已接收且未播放的音视频数据对应的待播放时长。
示例性的，服务端可以在所属服务器中维护一个与当前客户端(以下简称客户端)对应的发送窗口，利用该发送窗口采用预设拥塞控制算法来计算下行发送速率，并以该下行发送速率向客户端发送数据包，也即发送音视频数据。客户端在接收到服务端发送的数据包后，可以向服务端返回播放情况信息，该播放情况信息可以包含于确认字符(Acknowledge character，ack)数据包(简称ack包)中，ack包的发送时机具体不做限定，例如可以是定时发送。ack包中可以附带剩余可播时长(jitterLen)以及最后播放帧的时间戳(lastPlayedPts)，jitterLen可以表示客户端在发送ack包的时刻确定的本地已接收数据的剩余播放时长，也即从发送ack包的时刻起算，客户端播放已接收数据中未播放过的音视频数据所需要的时长。lastPlayedPts可以表示客户端在发送ack包的时刻确定的已播放的数据帧中最后一帧的时间戳。
示例性的，本步骤中的播放情况信息可以包括客户端连续多次发送的ack包中的播放情况信息。
步骤102、根据所述播放情况信息估算所述客户端的接收码率。
示例性的，可以采用第一预设估算算法来计算客户端的接收码率，考虑到网络状况的变化在不同的应用场景下一般受到多重因素影响，可以根据实际情况选择第一预设估算算法。例如，当网络状况相对稳定时，可以根据最近两次接收到的ack包中的播放情况信息来计算客户端的接收码率；当对计算精度要求较高时，可以根据连续多次接收到的ack包中的播放情况信息来计算客户端的接收码率。可选的，本发明实施例中可以根据连续多次接收到的ack包中的播放情况信息计算最近一个画面组(Group of Pictures，GOP)前第一预设时长的接收码率。第一预设时长可以根据实际需求设置，例如200毫秒(ms)。示例性的，在根据播放情况信息计算接收码率时，对于两个ack包发送时刻，第一时刻对应的剩余可播放时长记为jitterLen1，最后播放帧的时间戳记为lastPlayedPts1，第二时刻对应的剩余可播放时长记为jitterLen2，最后播放帧的时间戳记为lastPlayedPts2，可以计算第一时刻和第二时刻之间接收到的音视频数据对应的播放时长，如(lastPlayedPts2-lastPlayedPts1)+(jitterLen2-jitterLen1)，根据该播放时长和播放速率计算第一时刻和第二时刻之间接收到的音视频数据的数据量，根据该数据量与相应的时间差(第一时刻和第二时刻的时间差)估算客户端的接收码率。
步骤103、确定音视频数据的发送情况信息。
示例性的，发送情况信息可以包括服务端的音视频数据的发送相关的信息，例如，可包括当前画面组的已发送时长、当前画面组的已发送数据量大小、当前画面组的已发送比例、当前画面组的未发送时长、当前画面组的未发送数据量大小、当前画面组的未发送比例、发送音视频数据的当前码率或当前码率档位、服务端等待发送队列的时长、以及服务端等待发送队列的音视频数据量等等；对于视频直播等应用场景来说，服务端还需要从主播端或内容分发平台等接收音视频流，此时，发送情况信息还可包括服务端的剩余可发送数据、服务端的剩余可发送时长、以及当前画面组中的未接收数据的时长等等。
步骤104、根据所述播放情况信息、所述客户端的接收码率和所述发送情况信息确定音视频数据传输的码率控制方式。
示例性的，播放情况信息能够体现客户端播放进度以及对抗网络波动的能力，接收码率能够体现客户端接收音视频数据的能力，发送情况信息能够体现服务端发送音视频数据的能力，可以综合上述多种信息基于预设控制策略来进行码率控制，具体的控制策略可以根据实际需求设置，本发明实施例不做限定。
本发明实施例提供的音视频传输的码率控制方法，接收客户端反馈的播放情况信息，其中，播放情况信息包括所述客户端已接收且未播放的音视频数据对应的待播放时长以及最后播放帧的时间戳，根据播放情况信息估算客户端的接收码率，确定音视频数据的发送情况信息，根据播放情况信息、客户端的接收码率和发送情况信息确定音视频数据传输的码率控制方式。本发明实施例提供的技术方案，参考多个维度的信息进行综合评估和决策，可提高决策的准确性和及时性，更加合理地控制音视频传输的码率，进而更好地兼顾音视频播放的流畅性以及音视频播放的质量。
码率指单位时间内的比特率，用于衡量音视频数据的单位时间体积。可以对码率进行划档，每个码率档位可对应一个码率值或一个码率值区间，当对应一个码率值时，相邻两个码率档位对应的码率值可以是连续的，也可以是跳跃的，具体的划档策略可根据实际需求设置。例如，音视频传输***可以为客户端的播放提供几种可选码率档位，如标清、高清、超清和蓝光等，当然，还可以有精度更高的档位划分方式，由于音视频流转换码率需要计算资源，通常不会选择任意的码率值，可以在服务端或内容分发平台等处预先将音视频流转换成不同码率档位的音视频数据，再根据具体的码率控制策略选择合适的码率档位的音视频数据发送给客户端。对于音视频数据传输过程中的码率控制，一般可包括维持当前码率档位不变、降低码率档位和升高码率档位等。
下面先对降低码率档位的控制策略进行进一步介绍。
在一些实施例中，所述根据所述播放情况信息、所述客户端的接收码率和所述发送情况信息确定音视频数据传输的码率控制方式，包括：根据所述播放情况信息估算所述客户端的第一数据接收时刻对应的预估剩余可播时长，其中，所述第一数据接收时刻包括当前发送数据预计在所述客户端被接收的时刻；根据所述发送情况信息确定第一待发送数据；确定所述第一待发送数据对应的可播放时长，并根据所述客户端的接收码率确定所述第一待发送数据对应的第一待发送时长；根据所述预估剩余可播时长和所述可播放时长确定所述客户端在经过所述第一待发送时长后对应的目标剩余可播时长；当所述目标剩余可播时长小于第一预设阈值时，确定降低音视频数据传输的码率档位。这样设置的好处在于，可以更加合理地进行降低码率档位的控制。
图2为本发明实施例提供的一种服务端与客户端交互过程示意图，以音视频数据为视频数据为例，如图2所示，t1时刻，服务端(sever)向客户端(client)发送了视频数据(video)；t1’时刻，客户端接收到服务端t1时刻发送的视频数据并向服务端返回了对应该视频数据的ack包，且附带了客户端t1’时刻的jitterlen和lastPlayedPts；t2时刻，服务端收到ack包并进行升降档判断。当前发送数据指当前时刻预计向客户端发送的数据，也就是说，当前时刻假设为t2时刻，若在t2时刻向客户端发送视频数据，则预计客户端在t2’时刻接收到该视频数据，则t2’时刻相当于上述的第一数据接收时刻，第一数据接收时刻对应的预估剩余可播时长可理解为服务端估计的在第一数据接收时刻客户端侧的剩余可播时长，可记为jitterLen’，因为服务端t2时刻开始判断切档，t2之后发的数据包，全都是需要t2'之后才能到达客户端，所以要估算jitterLen’，可根据播放情况信息估算预估剩余可播时长的具体数值，具体的估算方式不做限定。
在一些实施例中，所述根据所述播放情况信息估算所述客户端的第一数据接收时刻对应的预估剩余可播时长，可包括：根据所述播放情况信息确定第一预设历史时段内的最大往返时延；根据所述播放情况信息中最新的剩余可播放时长、所述最大往返时延、最近一次的往返时延、所述客户端的接收码率以及当前码率档位的码率计算第一预估剩余可播时长；和/或，根据最后发送帧的时间戳、所述播放情况信息中最新的最后播放帧的时间戳以及所述最大往返时延计算第二预估剩余可播时长；将所述第一预估剩余可播时长、所述第二预估剩余可播时长、或者第一预估剩余可播时长和所述第二预估剩余可播时长中的最小值确定为所述客户端的第一数据接收时刻对应的预估剩余可播时长。这样设置的好处在于，可以更加准确地估算预估剩余可播时长，进而有利于准确地判定是否需要进行降档控制。
示例性的，估算预估剩余可播时长可以有两种方式。
第一种，根据播放情况信息中最新的剩余可播放时长、第一数据接收时刻与最新的剩余可播放时长的发送时刻的第一差值、当前时刻与上一次发送数据包的时刻的第二差值、所述客户端的接收码率以及当前码率档位的码率计算第一预估剩余可播时长(可理解为采用第一种方式计算得到的估算预估剩余可播时长)。具体的，可计算最新的剩余可播放时长减去第一差值加上第二差值与第一比值的乘积，得到第一预估剩余可播时长，其中，第一比值(可记为R0)为客户端的接收码率(可记为recvCodeRate)与当前码率档位的码率(可记为curCodeRate)的比值。例如，估算预估剩余可播时长以如下公式计算：
jitterLen’＝jitterLen–(t2’-t1’)+(t2-t1)*R0
其中，第一差值可以替换为第一预设历史时段内的最大往返时延(Round-TripTime，RTT)，第二差值可以替换为最近一次的往返时延。最大往返时延可记为maxRtt，第一预设历史时段可以根据实际情况设置，一般是从当前时刻向前追溯一段时间；最近一次的往返时延可记为lastRtt。相应的，t2’-t1’取maxRtt，t2-t1取lastRtt，则上述公式可表示为：
jitterLen’＝jitterLen–maxRtt+lastRtt*R0
第二种，根据最后发送帧的时间戳、所述播放情况信息中最新的最后播放帧的时间戳以及所述第一差值计算第二预估剩余可播时长(可理解为采用第二种方式计算得到的估算预估剩余可播时长)。具体的，可计算最后发送帧的时间戳与第一和值的差值，第一和值为最新的最后播放帧的时间戳与第一差值的和。其中，最后发送帧的时间戳可记为lastSentPts。例如，估算预估剩余可播时长以如下公式计算：
jitterLen’＝lastSentPts–(lastPlayedPts+(t2’-t1’))
其中，t2’-t1’取maxRtt，则上述公式可表示为：
jitterLen’＝lastSentPts-lastPlayedPts–maxRtt
可选的，可以综合上述两种计算方式，考虑最坏情况，取其中的最小值。这样，预估剩余可播时长可表示为：
jitterLen’＝min(jitterLen-maxRtt+lastRtt*R0，lastSentPts-lastPlayedPts-maxRtt)。
示例性的，根据所述发送情况信息确定第一待发送数据，可理解为根据服务端当前的音视频数据发送情况来确定用于模拟接下来的数据收发过程的数据量。确定第一待发送数据对应的可播放时长，可理解为预估客户端将第一待发送数据接收完毕后，可以增加的播放时长。根据客户端的接收码率确定第一待发送数据对应的第一待发送时长，可理解为预估客户端以服务端当前计算出来的接收码率进行第一待发送数据的接收所需要消耗的时长。
在得到预估剩余可播时长、可播放时长和第一待发送时长之后，便可预估客户端在经过第一待发送时长后对应的目标剩余可播时长。从第一数据接收时刻起，等待第一待发送时长后，预计客户端能够成功接收第一待发送数据，因此，在预估剩余可播时长基础上，会新增第一待发送数据对应的可播放时长，而由于客户端在进行第一待发送数据接收的过程中依然在进行播放，因此，剩余可播放时长会由于播放操作的继续而有减少，减少的量即为第一待发送时长。目标剩余可播时长的具体数值可以是预估剩余可播时长和可播放时长的和，减去第一待发送时长。
示例性的，剩余可播时长可理解为客户端已缓存的数据能够继续进行播放的时长，若发生网络质量较差等情况，无法成功继续接收音视频数据时，仍可根据缓存的数据进行后续的播放，因此能够体现客户端对抗网络波动的能力。在得到目标剩余可播时长后，可以判断目标剩余可播时长与第一预设阈值的大小，若小于该第一预设阈值，则可说明当前对抗网络波动的能力较差，为了减少同等播放时长的传输数据量，则需要降低音视频数据传输的码率档位，进而有利于提升剩余可播时长。
在一些实施例中，所述第一预设阈值通过以下方式确定：根据所述播放情况信息确定第二预设历史时段内的最大剩余可播时长；根据所述最大剩余可播时长和预设比重值的乘积确定第一剩余可播时长阈值；将所述第一剩余可播时长阈值和预设剩余可播时长阈值中的最小值确定为第一预设阈值。这样设置的好处在于，合理地确定第一预设阈值，进而准确判断是否需要进行降档处理。其中，预设剩余可播时长阈值可以是根据实际情况设置的经验值，可记为jitterThr；第二预设历史时段可以根据实际情况设置，一般是从当前时刻向前追溯一段时间，从第二预设历史时段内接收到的ack包中可以选出数值最大的剩余可播放时长，可记为maxJitter，将maxJitter与预设比重值(可以是根据实际情况设置的经验值，可记为maxJitterScale，范围可以在0至100％之间)的乘积确定为第一剩余可播时长阈值。将第一剩余可播时长阈值和预设剩余可播时长阈值中的最小值确定为第一预设阈值，也就是说第一预设阈值可以表示为min(jitterThr,maxJitter*maxJitterScale)。
在一些实施例中，所述发送情况信息包括当前画面组的已发送时长；所述根据所述发送情况信息确定第一待发送数据，包括：当所述已发送时长小于或等于第二预设阈值时，所述第一待发送数据包括所述当前画面组中的当前码率档位对应的未发送数据；当所述已发送时长大于所述第二预设阈值时，所述第一待发送数据包括所述当前画面组中的当前码率档位对应的未发送数据和下一画面组中的当前码率档位对应的数据。这样设置的好处在于，能够合理地确定第一待发送数据，进而准确地确定降档判定的时机。
示例性的，由于在同一个GOP中，靠后的视频帧需要参考前面的视频帧才能进行解码及播放，因此切换视频流时需要整个GOP进行切换。因此需要考虑从当前GOP开始切换还是从下一个GOP开始切换，当前GOP一般已经发送了一部分视频时长，假如当前GOP已经发送了很长时间(比如GOP的长度是2s，而已发送时长curGopSent是1.5s)，此时从当前GOP切换已经不太合适，因为有1.5s的数据是重复发送的，因此设置一个阈值gopSentThr(也即第二预设阈值)，在curGopSent<＝gopSentThr时，考虑从当前GOP开始切换，在curGopSent>gopSentThr时，考虑从下一个GOP开始切换。第二预设阈值可以根据一个GOP的长度(时长)来确定，例如可以是GOP时长的第一预设比例(如0.5等)。
在一些实施例中，当所述已发送时长小于或等于所述第二预设阈值时，在所述确定降低音视频数据传输的码率档位之后，还包括：根据所述客户端的接收码率，确定第二待发送数据对应的第二待发送时长，其中，所述第二待发送数据包括当前画面组中的候选码率对应的数据，所述候选码率低于所述当前码率档位的码率；根据所述预估剩余可播时长确定所述客户端在经过所述第二待发送时长后对应的候选剩余可播时长；将大于或等于所述第一预设阈值的候选剩余可播时长确定为第一候选剩余可播时长，并根据所述第一候选剩余可播时长确定对应的第一目标码率档位；从所述当前画面组的第一帧开始进行所述第一目标码率档位的音视频数据的传输。这样设置的好处在于，针对从当前画面组开始切换的情况，快速准确地选出满足要求的降档档位。
示例性的，在确定从当前画面组开始切换后，则需要以降档后的码率进行音视频传输，也就是说要传输当前画面组的降档码率对应的全部数据，将降档后的码率称为候选码率，可以是低于当前码率档位的任意一个码率，也可以是需要求取的未知码率。根据客户端的接收码率确定将当前画面组的候选码率对应的全部数据发送完毕所需要的时间，也即第二待发送时长。随后，确定客户端在经过第二待发送时长后对应的候选剩余可播时长，并与第一预设阈值进行比较，若大于或等于第一预设阈值，则说明候选剩余可播时长对应的候选码率符合预期。可以理解的是，符合预期的候选码率可能存在多个，为了兼顾音视频播放的画面清晰度等质量指标，可以选择其中最高的候选码率。可选的，所述根据所述第一候选剩余可播时长确定对应的第一目标码率档位，包括：将所述第一候选剩余可播时长对应的候选码率中的最高码率档位确定为第一目标码率档位，也即将小于候选码率最大值中的最高码率档位确定为第一目标码率档位。
在一些实施例中，当所述已发送时长大于所述第二预设阈值时，在所述确定降低音视频数据传输的码率档位之后，还包括：判断所述发送情况信息中的所述服务端的剩余可发送数据中是否包含下一个画面组中的当前码率档位对应的数据，所述剩余可发送数据包括所述服务端中已接收且未发送的音视频数据；根据判断结果采用相应的码率降低策略确定第二目标码率档位；继续进行当前画面组的当前码率档位的音视频数据的传输，并从下一个画面组的第一帧开始进行所述第二目标码率档位的音视频数据的传输。这样设置的好处在于，对于当前画面组已经发送较多数据的情况，先将当前画面组发送完毕再开始下一个画面组的降档后的数据传输，避免传输过多重复的音视频内容，节省带宽资源。
由于在进行档位切换时，新档位的音视频流和旧档位的音视频流之间可能存在延迟，也即，可能发送完当前画面组的数据包之后，切换档位的下一个画面组不会马上开始接收，也即切换档位的下一个画面组的数据还未到达，只能暂停发送音视频数据并等待下一个画面组的到来。若服务端的剩余可发送数据中未包含下一个画面组中的当前码率档位对应的数据，则需要将当前画面组的当前码率档位对应的数据接收完毕后，至少再经过上述延迟才能够开始进行下一个画面组中的降档码率对应的数据的传输。若服务端的剩余可发送数据中已包含下一个画面组中的当前码率档位对应的数据，则不需要接收当前画面组的数据，在当前画面组的已接收数据发送完毕之前，可以直接接收下一个画面组中的降档码率对应的数据。因此，针对上述两种情况，需要采用不同的码率降低策略确定第二目标码率档位。
在一些实施例中，所述根据判断结果采用相应的码率降低策略确定第二目标码率档位，包括：根据判断结果采用相应的确定方式根据所述客户端的接收码率确定第三待发送数据对应的第三待发送时长，其中，所述第三待发送数据包括所述当前画面组中的当前码率档位对应的未发送数据和下一画面组中的候选码率对应的数据，其中，所述候选码率低于所述当前码率档位的码率；根据所述预估剩余可播时长确定所述客户端在经过所述第三待发送时长后对应的候选剩余可播时长；将大于或等于所述第一预设阈值的候选剩余可播时长确定为第二候选剩余可播时长，并根据所述第二候选剩余可播时长确定对应的第二目标码率档位。这样设置的好处在于，针对从下一个画面组开始切换的情况，快速准确地选出满足要求的降档档位。可选的，所述根据所述第二候选剩余可播时长确定对应的第二目标码率档位，包括：将所述第二候选剩余可播时长对应的候选码率中的最高码率档位确定为第二目标码率档位，也即将小于候选码率最大值中的最高码率档位确定为第二目标码率档位。
在一些实施例中，当所述服务端的剩余可发送数据中未包含下一个画面组中的当前码率档位对应的数据时，所述根据判断结果采用相应的确定方式根据所述客户端的接收码率确定第三待发送数据对应的第三待发送时长，包括：根据所述客户端的接收码率计算所述当前画面组中的当前码率档位对应的未发送数据的第四待发送时长；将所述当前画面组中的当前码率档位对应的未接收数据的第一接收时长和第一预估切换延迟时长的和确定为第五待发送时长；根据候选码率、所述客户端的接收码率以及下一个画面组的时长计算第六待发送时长；将所述第四待发送时长和所述第五待发送时长中的最大值与所述第六待发送时长的和确定为第三待发送数据对应的第三待发送时长。这样设置的好处在于，可以针对服务端的剩余可发送数据中未包含下一个画面组中的当前码率档位对应的数据的情况，有针对性地计算第三待发送时长，进而准确地计算第二目标码率档位。
示例性的，第四待发送时长可理解为服务端将当前画面组中剩余的未发送数据发送完毕所需要的时间。第五待发送时长可以理解为将当前画面组的未接收数据接收完毕并等待切换延迟的总时长，其中，第一预估切换延迟时长可以通过历史的音视频流切换过程进行估算，例如可以是多次切换延迟时长的平均值，切换前的码率档位和切换后的码率档位中任意一者的不同可以使得对应的第一预估切换延迟时长不同。第六待发送时长可理解为发送下一个画面组的候选码率对应的数据所需要的时间，具体可以是候选码率的码率与下一个画面组的时长的乘积除以客户端的接收码率得到的数值。由于下一个画面组的数据的发送需要在当前画面组发送完毕后且已开始接收下一个画面组的数据之后才可以进行发送，因此，总的待发送时长(第三待发送时长)是第四待发送时长和第五待发送时长中的较大值与第六待发送时长的和。
在一些实施例中，当所述服务端的剩余可发送数据中已包含下一个画面组中的当前码率档位对应的数据时，所述根据判断结果采用相应的确定方式根据所述客户端的接收码率确定第三待发送数据对应的第三待发送时长，包括：根据所述客户端的接收码率计算所述当前画面组中的当前码率档位对应的未发送数据的第四待发送时长；将第一预估切换延迟时长与第一时长的差确定为第七待发送时长，其中，所述第一时长为所述服务端的剩余可发送数据对应的发送时长与所述第四待发送时长的差；根据候选码率、所述客户端的接收码率以及下一个画面组的时长计算第六待发送时长；将所述第四待发送时长和所述第七待发送时长中的最大值与所述第六待发送时长的和确定为第三待发送数据对应的第三待发送时长。这样设置的好处在于，可以针对服务端的剩余可发送数据中已包含下一个画面组中的当前码率档位对应的数据的情况，有针对性地计算第三待发送时长，进而准确地计算第二目标码率档位。
示例性的，这里的第四待发送时长和第六待发送时长与服务端的剩余可发送数据中未包含下一个画面组中的当前码率档位对应的数据时的计算方式可以相同。第七待发送时长可理解为等待切换延迟结束所需要的时间。
图3为本发明实施例提供的又一种音视频传输的码率控制方法的流程示意图，如图3所示，该方法可以包括：
步骤301、接收客户端反馈的播放情况信息以及确定音视频数据的发送情况信息，根据播放情况信息估算客户端的接收码率以及客户端的第一数据接收时刻对应的预估剩余可播时长。
其中，所述播放情况信息包括剩余可播时长(jitterLen)以及最后播放帧的时间戳(lastPlayedPts)，所述剩余可播时长包括所述客户端已接收且未播放的音视频数据对应的待播放时长。音视频数据的发送情况信息包括当前画面组的已发送时长(curGopSent)、服务端的剩余可发送数据对应的时长(waitLen)。示例性的，客户端的接收码率为recvCodeRate，预估剩余可播时长为jitterLen’，具体计算方式可参照上文相关内容。
步骤302、判断当前画面组的已发送时长是否小于或等于第二预设阈值，若是，则执行步骤303；否则，执行步骤305。
其中，当前画面组的已发送时长可记为curGopSent，第二预设阈值可记为gopSentThr。在curGopSent<＝gopSentThr时，考虑从当前GOP开始切换，在curGopSent>gopSentThr时，考虑从下一个GOP开始切换。
图4为本发明实施例提供的一种视频流状态示意图，如图4所示，当前流可以理解为当前码率档位对应的音视频流，切换流可以理解为切换后的码率档位对应的音视频流，当前画面组中已发送的最后一个帧的位置可记为lastSent，waitLen表示服务端等待发送队列的时长(单位ms)，也即服务端的剩余可发送数据对应的时长，curGopIncome表示当前画面组未到达时长(单位：ms)。
步骤303、将当前画面组中的当前码率档位对应的未发送数据确定为第一待发送数据，确定第一待发送数据对应的可播放时长以及第一待发送时长，根据预估剩余可播时长和第一待发送数据对应的可播放时长确定客户端在第一数据接收时刻起经过第一待发送时长后对应的目标剩余可播时长。
示例性的，当前GOP的剩余可播放时长(第一待发送数据对应的可播放时长)：T0＝curGopLeft＝waitLen+curGopIncome。
当前GOP的预计剩余发送时长(第一待发送时长)为：T1＝curGopLeftSize*8/recvCodeRate。
经过T1时间后，可以估算客户端的可播放时长(目标剩余可播时长)：jitterLenT1＝jitterLen’+T0-T1。
步骤304、当目标剩余可播时长小于第一预设阈值时，确定对应的第一目标码率档位，从当前画面组的第一帧开始进行第一目标码率档位的音视频数据的传输。
其中，第一预设阈值可以表示为min(jitterThr,maxJitter*maxJitterScale)，具体计算方式可参照上文相关内容。也即，当jitterLenT1<min(jitterThr,maxJitter*maxJitterScale)时需要降档，随后，确定具体降到哪个码率档位，降档后，当前GOP发送完时jitterLenT1不能低于第一预设阈值。
从当前GOP切换需要发送整个GOP，也即第二待发送数据包括当前画面组中的候选码率对应的数据，则降档后当前GOP的预计剩余发送时长(第二待发送时长)为：T2＝targetCodeRate*gopLen/recvCodeRate，其中，targetCodeRate为目标码率(也即候选码率)，gopLen表示GOP的时长(单位：ms)。
经过T2时间后，可以估算客户端的可播放时长(候选剩余可播时长)：
jitterLenT2＝jitterLen’+T0–T2
＝jitterLen’+T0-targetCodeRate*gopLen/recvCodeRate。
令jitterLenT2＝min(jitterThr,maxJitter*maxJitterScale)可以算出targetCodeRate的临界值(也即最大值)：
targetCodeRate＝(min(jitterThr,maxJitter*maxJitterScale)-jitterLen’-T0)*recvCodeRate/gopLen。
在降档时选择一个码率低于targetCodeRate的档位中码率最高的档位即可，也即将码率低于targetCodeRate的档位中码率最高的档位确定为第一目标码率档位。
可选的，目标剩余可播时长大于或等于第一预设阈值时，可认为无需降档，可返回执行步骤301，或者，可进行升档判定。
步骤305、将当前画面组中的当前码率档位对应的未发送数据和下一画面组中的当前码率档位对应的数据确定为第一待发送数据，确定第一待发送数据对应的可播放时长以及第一待发送时长，根据预估剩余可播时长和第一待发送数据对应的可播放时长确定客户端在第一数据接收时刻起经过第一待发送时长后对应的目标剩余可播时长。
示例性的，下一个GOP为止的可播放时长(第一待发送数据对应的可播放时长)为：T0＝curGopLeft+gopLen。
下一个GOP为止的预计发送时长(第一待发送时长)为：T1＝curGopLeftSize*8/recvCodeRate+gopLen/R0。
经过T1时间后，可以估算客户端的可播放时长(目标剩余可播时长)：jitterLenT1＝jitterLen’+T0-T1。
步骤306、当目标剩余可播时长小于第一预设阈值时，确定对应的第二目标码率档位，继续进行当前画面组的当前码率档位的音视频数据的传输，并从下一个画面组的第一帧开始进行所述第二目标码率档位的音视频数据的传输。
当jitterLenT1<min(jitterThr,maxJitter*maxJitterScale)时需要降档，随后，确定具体降到哪个码率档位，降档后，当前GOP发送完时jitterLenT1不能低于第一预设阈值。具体的，根据服务端的剩余可发送数据中是否包含下一个画面组中的当前码率档位对应的数据，也即根据服务端的剩余可发送数据对应的时长中是否包含下一个画面组中的时长，分两种情况确定第二目标码率档位。
第一种情况，服务端的剩余可发送数据中未包含下一个画面组中的当前码率档位对应的数据。图5为本发明实施例提供的又一种视频流状态示意图，如图5所示，now表示当前时刻，当前waitLen对应的数据没有下一个画面组的包。
切换档位后，下一个GOP为止的预计发送时长：
T2＝max(curGopLeftSize*8/recvCodeRate,curGopIncom+delay)+targetCodeRate*gopLen/recvCodeRate
这里curGopLeftSize*8/recvCodeRate是发送完当前GOP的时长(第四待发送时长)，curGopIncom+delay是等待切换档位的下一个GOP的时长(第五待发送时长)，由于可能发送完当前GOP的视频包，切换档位的下一个GOP还没有到，这时只能不发包空等，所以经过max(curGopLeftSize*8/recvCodeRate,curGopIncom+delay)的时长后才能发送切换档位的GOP，targetCodeRate*gopLen/recvCodeRate就是切换档位后的下一个GOP的发送时长(第六待发送时长)，两者相加就是下一个GOP为止的预计发送时长T2(第三待发送时长)。
经过T2时间后，可以估算客户端的可播放时长(候选剩余可播时长)：
jitterLenT2＝jitterLen’+T0–T2
＝jitterLen’+T0–max(curGopLeftSize*8/recvCodeRate,curGopIncom+delay)+targetCodeRate*gopLen/recvCodeRate
令jitterLenT2＝min(jitterThr,maxJitter*maxJitterScale)可以算出targetCodeRate的临界值：
targetCodeRate＝((jitterLen’+T0-min(jitterThr,maxJitter*maxJitterScale))-max(curGopLeftSize*8/recvCodeRate,curGopIncome+delay))*recvCodeRate/gopLen
则降档时选择一个码率低于targetCodeRate的档位中，码率最高的档位即可。
第二种情况，服务端的剩余可发送数据中已包含下一个画面组中的当前码率档位对应的数据。图6为本发明实施例提供的再一种视频流状态示意图，如图6所示，now表示当前时刻，当前waitLen对应的数据已包含下一个画面组的包。
切换档位后，下一个GOP为止预计发送时长：
T2＝max(curGopLeftSize*8/recvCodeRate,delay-(waitLen-curGopLeft))+targetCodeRate*gopLen/recvCodeRate。
经过T2时间后，可以估算客户端的可播放时长：
jitterLenT2＝jitterLen’+T0-T2
＝jitterLen’+T0-max(curGopLeftSize*8/recvCodeRate,delay-(waitLen-curGopLeft))+targetCodeRate*gopLen/recvCodeRate。
令jitterLenT2＝min(jitterThr,maxJitter*maxJitterScale)可以算出targetCodeRate的临界值：
targetCodeRate＝((jitterLen+T0-min(jitterThr,maxJitter*maxJitterScale))-max(curGopLeftSize/recvCodeRate,delay-(waitLen-curGopLeft))*recvCodeRate/gopLen。
则降档时选择一个码率低于targetCodeRate的档位中，码率最高的档位即可。
在一些实施例中，还可根据播放情况信息、所述客户端的接收码率和所述发送情况信息进行码率控制的升档判定。
下面先对升高码率档位的控制策略进行进一步介绍。
示例性的，所述根据所述播放情况信息、所述客户端的接收码率和所述发送情况信息确定音视频数据传输的码率控制方式，包括：当所述发送情况信息满足预设升档探测条件时，开始发送探测冗余包并逐渐增加探测冗余包在发送数据中的占比；在发送探测冗余包的过程中，若确定所述播放情况信息和所述客户端的接收码率满足预设升档条件，则停止发送探测冗余包，并提升音视频数据传输的码率档位。这样设置的好处在于，在进行升档之前，可以通过发送探测冗余包的方式进行模拟升档，进而确认当前网络是否达到升档条件以达到防止误判的目的，防止出现盲目升档导致网络拥塞出现卡顿的问题。其中，预设升档探测条件可以根据实际需求设置，一般为初步判定存在升档需求的条件，具体不做限定。探测冗余包也可自由设置，例如可以是重传队列里的重传包，也可以是新接收到的数据包等。在发送探测冗余包的过程中，不断增加探测冗余包的占比，也即提升冗余率，同时，服务端估算的客户端的接收码率也不断增大，当满足预设升档条件时，可真正开始升档。其中，预设升档条件可以根据实际需求设置，一般为确定当前网络带宽支持升档的条件。在进行升档时，升档幅度具体不做限定，例如可以是提升一个码率档位。
在一些实施例中，所述发送情况信息满足预设升档探测条件，包括：所述发送情况信息中包含的所述服务端的剩余可发送数据小于或等于第三预设阈值，且发送窗口计算的最小带宽大于预设系数与最大发送速率的乘积。这样设置的好处在于，通过合理地设定预设升档探测条件，可以准确地确定升档探测的时机。其中，最小带宽可记为minBandwidth，可采用预设拥塞控制算法计算得到。最大发送速率可记为maxSendRate，可以根据发送窗口的实际发送速率确定。预设系数可记为n，可以是1至2之间的经验值。示例性的，最大发送速率可以是实际发送速率与当前码率*(1+lossRate)中的较大值，其中，lossRate表示当前的丢包率，具体计算方式不做限定。
在一些实施例中，所述确定所述播放情况信息和所述客户端的接收码率满足预设升档条件，包括：所述播放情况信息中最新的剩余可播放时长与第一预估切换延迟时长的差大于或等于第一预设阈值，且所述客户端的接收码率大于备选码率，其中，所述备选码率的档位高于当前码率档位。这样设置的好处在于，通过合理地设定预设升档条件，可以准确地确定升档的时机，确保在网络带宽支持升档的情况下才开始真正地升档。
示例性的，最新的剩余可播放时长与第一预估切换延迟时长的差大于或等于第一预设阈值时，说明即使经过码率档位切换对应的第一预估切换延迟时长之后，客户端的剩余可播放时长也能够达到对抗网络波动的能力的最低要求，因此，具备一定的升档基础，另外，由于在探测冗余包的发送过程中服务端所估算的客户端的接收码率是不断增大的，当客户端的接收码率大于备选码率时，说明客户端的接收能力较强，可以持续接收更高码率档位的音视频数据一段时间，而保证客户端的剩余可播放时长不会大幅减少。因此，在满足上述两个条件时，可以真正开始升档。
在一些实施例中，在所述开始发送探测冗余包并逐渐增加探测冗余包在发送数据中的占比之后，还包括：当所述发送情况信息中包含的所述服务端的剩余可发送数据大于第三预设阈值时，停止发送探测冗余包。这样设置的好处在于，当服务端的剩余可发送数据大于一定值时，说明已存在一些未发送数据的积压，此时客户端的接收码率可能无法支持升档，可停止发送探测冗余包，也即结束升档探测。第三预设阈值可以根据实际情况设置，可以为0，或其他大于0的数值。
在一些实施例中，所述开始发送探测冗余包并逐渐增加探测冗余包在发送数据中的占比，包括：从重传队列中获取重传包作为探测冗余包进行发送；经过第二时长后，获取新接收的视频包作为探测冗余包进行发送，并在发送过程中逐渐增加探测冗余包在发送数据中的占比，直到所述占比达到冗余率上限。这样设置的好处在于，优先将重传包作为探测冗余包进行发送，可以在实现升档探测的同时提高重传包被成功接收的概率。另外，通过设置冗余率上限来控制探测冗余包的占比，避免发送过多的探测冗余包占用过多的网络带宽资源。冗余率上限可以根据实际情况设置，例如可以是100％、200％等。
在一些实施例中，所述冗余率上限根据当前码率档位和高于所述当前码率档位的相邻档位之间的码率差值确定。这样设置的好处在于，可以合理地设置冗余率上限。例如，两个档位之间码率相差不到一倍，则可设置为100％。
需要说明的是，本发明实施例中，进行降档判断和升档判断时均参考了播放情况信息、客户端的接收码率和发送情况信息，但在具体的判定策略上存在一定的差别，可以先进行降档判断再进行升档判断，也可以先进行升档判断再进行降档判断，当然，也可以同时并行地进行降档判断和升档判断，具体不做限定。
图7为本发明实施例提供的另一种音视频传输的码率控制方法的流程示意图，该方法主要介绍升档判断相关步骤，如图7所示，该方法可包括：
步骤701、接收客户端反馈的播放情况信息，其中，所述播放情况信息包括剩余可播时长以及最后播放帧的时间戳，所述剩余可播时长包括所述客户端已接收且未播放的音视频数据对应的待播放时长。
步骤702、根据所述播放情况信息估算所述客户端的接收码率。
步骤703、确定音视频数据的发送情况信息。
步骤704、当所述发送情况信息满足预设升档探测条件时，开始发送探测冗余包并逐渐增加探测冗余包在发送数据中的占比。
示例性的，预设升档探测条件可表示为：waitLen＝0且minBandwidth>n*maxSendRate。
步骤705、在发送探测冗余包的过程中，若确定所述播放情况信息和所述客户端的接收码率满足预设升档条件，则停止发送探测冗余包，并提升音视频数据传输的码率档位。
其中，预设升档条件可表示为：jitterLen-delay>＝jitterThr，且recvCodeRate>nextCodeRate。也即，在增加冗余包的过程中，假如jitterLen-delay>＝jitterThr时，如果recvCodeRate>nextCodeRate，则停止发送冗余包，并开始升档。其中，nextCodeRate表示高于当前码率档位的下一个码率档位。
本发明实施例提供的音视频传输的码率控制方法，参考多个维度的信息进行综合评估，可以更加合理地控制音视频传输的码率升档，在进行升档之前，可以通过发送探测冗余包的方式进行模拟升档，进而确认当前网络是否达到升档条件以达到防止误判的目的，防止出现盲目升档导致网络拥塞出现卡顿的问题。
图8为本发明实施例提供的再一种音视频传输的码率控制方法的流程示意图，如图8所示，该方法可包括：
步骤801、接收客户端反馈的播放情况信息以及确定音视频数据的发送情况信息，根据播放情况信息估算客户端的接收码率以及客户端的第一数据接收时刻对应的预估剩余可播时长。
步骤802、判断当前画面组的已发送时长是否小于或等于第二预设阈值，若是，则执行步骤803；否则，执行步骤806。
步骤803、将当前画面组中的当前码率档位对应的未发送数据确定为第一待发送数据，确定客户端在第一数据接收时刻起经过第一待发送时长后对应的目标剩余可播时长。
步骤804、判断目标剩余可播时长是否小于第一预设阈值，若是，则执行步骤805；否则，执行步骤809。
步骤805、确定对应的第一目标码率档位，从当前画面组的第一帧开始进行第一目标码率档位的音视频数据的传输。
其中，第一目标码率档位低于当前码率档位。
步骤806、将当前画面组中的当前码率档位对应的未发送数据和下一画面组中的当前码率档位对应的数据确定为第一待发送数据，确定客户端在第一数据接收时刻起经过第一待发送时长后对应的目标剩余可播时长。
步骤807、判断目标剩余可播时长是否小于第一预设阈值，若是，则执行步骤808；否则，执行步骤809。
步骤808、确定对应的第二目标码率档位，继续进行当前画面组的当前码率档位的音视频数据的传输，并从下一个画面组的第一帧开始进行所述第二目标码率档位的音视频数据的传输。
步骤809、判断发送情况信息是否满足预设升档探测条件，若是，则执行步骤810；否则，执行步骤801。
步骤810、开始发送探测冗余包并逐渐增加探测冗余包在发送数据中的占比。
步骤811、判断播放情况信息和客户端的接收码率是否满足预设升档条件，若是，则执行步骤812；否则，执行步骤801。
步骤812、停止发送探测冗余包，并提升音视频数据传输的码率档位，执行步骤801。
示例性的，在提升码率档位时，可以从下一个画面组开始进行切换，因为对于升档情况来说，不会出现卡顿情况，为避免对网络带宽资源的占用，可以等当前画面组的数据传输完毕后再进行切换。可选的，提升音视频数据传输的码率档位，可以是从下一个画面组的第一帧开始进行升高一档后的码率档位的音视频数据的传输。
综上，本发明实施例提供的音视频传输码率控制方法，通过客户端播放器缓存时长、当前GOP的发送情况和当前接收速率等多个网络指标的综合评判能够更准确地估算出当前网络的实际带宽，同时使用冗余包探测来进一步确认当前网络是否达到升档条件以达到防止误判的目的，码率切换更及时，避免由于码率切换不及时导致的卡顿，可以在用户观看音视频直播时根据用户实时的网络状况及时自动地提升或降低码率，相比传统方法码率切换决策更准确，切换动作更及时，能够显著减少卡顿并提高网络带宽利用率，在避免卡顿的情况下尽可能提供给用户更高的清晰度，可显著提升用户观看体验。
图9为本发明实施例提供的一种音视频传输的码率控制装置的结构框图，该装置可由软件和/或硬件实现，一般可集成在计算机设备中，可通过执行音视频传输的码率控制方法来进行码率控制。如图9所示，该装置包括：
播放情况信息接收模块901，用于接收客户端反馈的播放情况信息，其中，所述播放情况信息包括剩余可播时长以及最后播放帧的时间戳，所述剩余可播时长包括所述客户端已接收且未播放的音视频数据对应的待播放时长；
接收码率估算模块902，用于根据所述播放情况信息估算所述客户端的接收码率；
发送情况信息确定模块903，用于确定音视频数据的发送情况信息；
码率控制模块904，用于根据所述播放情况信息、所述客户端的接收码率和所述发送情况信息确定音视频数据传输的码率控制方式。
本发明实施例提供的音视频传输的码率控制装置，应用于音视频传输***中的服务端，接收客户端反馈的播放情况信息，其中，播放情况信息包括剩余可播时长以及最后播放帧的时间戳，剩余可播时长包括客户端已接收且未播放的音视频数据对应的待播放时长，根据播放情况信息估算所述客户端的接收码率，确定音视频数据的发送情况信息，根据播放情况信息、客户端的接收码率和发送情况信息确定音视频数据传输的码率控制方式。通过采用上述技术方案，参考多个维度的信息进行综合评估，可以更加合理地控制音视频传输的码率，进而更好地兼顾音视频播放的流畅性以及音视频播放的质量。
本发明实施例提供了一种计算机设备，该计算机设备中可集成本发明实施例提供的音视频传输的码率控制装置。图10为本发明实施例提供的一种计算机设备的结构框图。计算机设备1000包括存储器1001、处理器1002及存储在存储器1001上并可在处理器1002上运行的计算机程序，所述处理器1002执行所述计算机程序时实现本发明实施例提供的音视频传输的码率控制方法。
本发明实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行本发明实施例提供的音视频传输的码率控制方法。
上述实施例中提供的音视频传输的码率控制装置、设备以及存储介质可执行本发明任意实施例所提供的音视频传输的码率控制方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的音视频传输的码率控制方法。
注意，上述仅为本发明的较佳实施例。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由权利要求范围决定。

Claims (19)

1.一种音视频传输的码率控制方法，其特征在于，应用于音视频传输***中的服务端，所述方法包括：
接收客户端反馈的播放情况信息，其中，所述播放情况信息包括剩余可播时长以及最后播放帧的时间戳，所述剩余可播时长包括所述客户端已接收且未播放的音视频数据对应的待播放时长；
根据所述播放情况信息估算所述客户端的接收码率；
确定音视频数据的发送情况信息；
根据所述播放情况信息、所述客户端的接收码率和所述发送情况信息确定音视频数据传输的码率控制方式。
2.根据权利要求1所述的方法，其特征在于，所述根据所述播放情况信息、所述客户端的接收码率和所述发送情况信息确定音视频数据传输的码率控制方式，包括：
根据所述播放情况信息估算所述客户端的第一数据接收时刻对应的预估剩余可播时长，其中，所述第一数据接收时刻包括当前发送数据预计在所述客户端被接收的时刻；
根据所述发送情况信息确定第一待发送数据；
确定所述第一待发送数据对应的可播放时长，并根据所述客户端的接收码率确定所述第一待发送数据对应的第一待发送时长；
根据所述预估剩余可播时长和所述可播放时长确定所述客户端在经过所述第一待发送时长后对应的目标剩余可播时长；
当所述目标剩余可播时长小于第一预设阈值时，确定降低音视频数据传输的码率档位。
3.根据权利要求2所述的方法，其特征在于，所述根据所述播放情况信息估算所述客户端的第一数据接收时刻对应的预估剩余可播时长，包括：
根据所述播放情况信息确定第一预设历史时段内的最大往返时延；
根据所述播放情况信息中最新的剩余可播放时长、所述最大往返时延、最近一次的往返时延、所述客户端的接收码率以及当前码率档位的码率计算第一预估剩余可播时长；和/或，根据最后发送帧的时间戳、所述播放情况信息中最新的最后播放帧的时间戳以及所述最大往返时延计算第二预估剩余可播时长；
将所述第一预估剩余可播时长、所述第二预估剩余可播时长、或者第一预估剩余可播时长和所述第二预估剩余可播时长中的最小值确定为所述客户端的第一数据接收时刻对应的预估剩余可播时长。
4.根据权利要求2所述的方法，其特征在于，所述发送情况信息包括当前画面组的已发送时长；
所述根据所述发送情况信息确定第一待发送数据，包括：
当所述已发送时长小于或等于第二预设阈值时，所述第一待发送数据包括所述当前画面组中的当前码率档位对应的未发送数据；当所述已发送时长大于所述第二预设阈值时，所述第一待发送数据包括所述当前画面组中的当前码率档位对应的未发送数据和下一画面组中的当前码率档位对应的数据。
5.根据权利要求2所述的方法，其特征在于，所述第一预设阈值通过以下方式确定：
根据所述播放情况信息确定第二预设历史时段内的最大剩余可播时长；
根据所述最大剩余可播时长和预设比重值的乘积确定第一剩余可播时长阈值；
将所述第一剩余可播时长阈值和预设剩余可播时长阈值中的最小值确定为第一预设阈值。
6.根据权利要求4所述的方法，其特征在于，当所述已发送时长小于或等于所述第二预设阈值时，在所述确定降低音视频数据传输的码率档位之后，还包括：
根据所述客户端的接收码率，确定第二待发送数据对应的第二待发送时长，其中，所述第二待发送数据包括当前画面组中的候选码率对应的数据，所述候选码率低于所述当前码率档位的码率；
根据所述预估剩余可播时长确定所述客户端在经过所述第二待发送时长后对应的候选剩余可播时长；
将大于或等于所述第一预设阈值的候选剩余可播时长确定为第一候选剩余可播时长，并根据所述第一候选剩余可播时长确定对应的第一目标码率档位；
从所述当前画面组的第一帧开始进行所述第一目标码率档位的音视频数据的传输。
7.根据权利要求6所述的方法，其特征在于，所述根据所述第一候选剩余可播时长确定对应的第一目标码率档位，包括：
将所述第一候选剩余可播时长对应的候选码率中的最高码率档位确定为第一目标码率档位。
8.根据权利要求4所述的方法，其特征在于，当所述已发送时长大于所述第二预设阈值时，在所述确定降低音视频数据传输的码率档位之后，还包括：
判断所述发送情况信息中的所述服务端的剩余可发送数据中是否包含下一个画面组中的当前码率档位对应的数据，所述剩余可发送数据包括所述服务端中已接收且未发送的音视频数据；
根据判断结果采用相应的码率降低策略确定第二目标码率档位；
继续进行当前画面组的当前码率档位的音视频数据的传输，并从下一个画面组的第一帧开始进行所述第二目标码率档位的音视频数据的传输。
9.根据权利要求8所述的方法，其特征在于，所述根据判断结果采用相应的码率降低策略确定第二目标码率档位，包括：
根据判断结果采用相应的确定方式根据所述客户端的接收码率确定第三待发送数据对应的第三待发送时长，其中，所述第三待发送数据包括所述当前画面组中的当前码率档位对应的未发送数据和下一画面组中的候选码率对应的数据，其中，所述候选码率低于所述当前码率档位的码率；
根据所述预估剩余可播时长确定所述客户端在经过所述第三待发送时长后对应的候选剩余可播时长；
将大于或等于所述第一预设阈值的候选剩余可播时长确定为第二候选剩余可播时长，并根据所述第二候选剩余可播时长确定对应的第二目标码率档位。
10.根据权利要求9所述的方法，其特征在于，当所述服务端的剩余可发送数据中未包含下一个画面组中的当前码率档位对应的数据时，所述根据判断结果采用相应的确定方式根据所述客户端的接收码率确定第三待发送数据对应的第三待发送时长，包括：
根据所述客户端的接收码率计算所述当前画面组中的当前码率档位对应的未发送数据的第四待发送时长；
将所述当前画面组中的当前码率档位对应的未接收数据的第一接收时长和第一预估切换延迟时长的和确定为第五待发送时长；
根据候选码率、所述客户端的接收码率以及下一个画面组的时长计算第六待发送时长；
将所述第四待发送时长和所述第五待发送时长中的最大值与所述第六待发送时长的和确定为第三待发送数据对应的第三待发送时长。
11.根据权利要求9所述的方法，其特征在于，当所述服务端的剩余可发送数据中已包含下一个画面组中的当前码率档位对应的数据时，所述根据判断结果采用相应的确定方式根据所述客户端的接收码率确定第三待发送数据对应的第三待发送时长，包括：
根据所述客户端的接收码率计算所述当前画面组中的当前码率档位对应的未发送数据的第四待发送时长；
将第一预估切换延迟时长与第一时长的差确定为第七待发送时长，其中，所述第一时长为所述服务端的剩余可发送数据对应的发送时长与所述第四待发送时长的差；
根据候选码率、所述客户端的接收码率以及下一个画面组的时长计算第六待发送时长；
将所述第四待发送时长和所述第七待发送时长中的最大值与所述第六待发送时长的和确定为第三待发送数据对应的第三待发送时长。
12.根据权利要求1-11任一所述的方法，其特征在于，所述根据所述播放情况信息、所述客户端的接收码率和所述发送情况信息确定音视频数据传输的码率控制方式，包括：
当所述发送情况信息满足预设升档探测条件时，开始发送探测冗余包并逐渐增加探测冗余包在发送数据中的占比；
在发送探测冗余包的过程中，若确定所述播放情况信息和所述客户端的接收码率满足预设升档条件，则停止发送探测冗余包，并提升音视频数据传输的码率档位。
13.根据权利要求12所述的方法，其特征在于，所述发送情况信息满足预设升档探测条件，包括：
所述发送情况信息中包含的所述服务端的剩余可发送数据小于或等于第三预设阈值，且发送窗口计算的最小带宽大于预设系数与最大发送速率的乘积。
14.根据权利要求12所述的方法，其特征在于，所述确定所述播放情况信息和所述客户端的接收码率满足预设升档条件，包括：
所述播放情况信息中最新的剩余可播放时长与第一预估切换延迟时长的差大于或等于第一预设阈值，且所述客户端的接收码率大于备选码率，其中，所述备选码率的档位高于当前码率档位。
15.根据权利要求13所述的方法，其特征在于，在所述开始发送探测冗余包并逐渐增加探测冗余包在发送数据中的占比之后，还包括：
当所述发送情况信息中包含的所述服务端的剩余可发送数据大于第三预设阈值时，停止发送探测冗余包。
16.根据权利要求12所述的方法，其特征在于，所述开始发送探测冗余包并逐渐增加探测冗余包在发送数据中的占比，包括：
从重传队列中获取重传包作为探测冗余包进行发送；
经过第二时长后，获取新接收的视频包作为探测冗余包进行发送，并在发送过程中逐渐增加探测冗余包在发送数据中的占比，直到所述占比达到冗余率上限。
17.一种音视频传输的码率控制装置，其特征在于，配置于音视频传输***中的服务端，所述装置包括：
播放情况信息接收模块，用于接收客户端反馈的播放情况信息，其中，所述播放情况信息包括剩余可播时长以及最后播放帧的时间戳，所述剩余可播时长包括所述客户端已接收且未播放的音视频数据对应的待播放时长；
接收码率估算模块，用于根据所述播放情况信息估算所述客户端的接收码率；
发送情况信息确定模块，用于确定音视频数据的发送情况信息；
码率控制模块，用于根据所述播放情况信息、所述客户端的接收码率和所述发送情况信息确定音视频数据传输的码率控制方式。
18.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1-16任一项所述的方法。
19.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-16中任一所述的方法。
CN202011643196.8A 2020-12-30 2020-12-30 音视频传输的码率控制方法、装置、设备及存储介质 Active CN112822521B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011643196.8A CN112822521B (zh) 2020-12-30 2020-12-30 音视频传输的码率控制方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011643196.8A CN112822521B (zh) 2020-12-30 2020-12-30 音视频传输的码率控制方法、装置、设备及存储介质

Publications (2)

Publication Number Publication Date
CN112822521A true CN112822521A (zh) 2021-05-18
CN112822521B CN112822521B (zh) 2023-04-25

Family

ID=75858271

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011643196.8A Active CN112822521B (zh) 2020-12-30 2020-12-30 音视频传输的码率控制方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN112822521B (zh)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113784216A (zh) * 2021-08-24 2021-12-10 咪咕音乐有限公司 视频卡顿识别方法、装置、终端设备以及存储介质
CN114390320A (zh) * 2022-02-18 2022-04-22 百果园技术(新加坡)有限公司 数据编码码率自适应调节方法、装置、设备和存储介质
CN115103234A (zh) * 2022-06-07 2022-09-23 慧之安信息技术股份有限公司 基于rtp的图像远程传输方法
CN115174538A (zh) * 2022-06-30 2022-10-11 Oppo广东移动通信有限公司 数据传输方法、装置、电子设备及计算机可读介质
CN115361574A (zh) * 2022-08-15 2022-11-18 广州市奥威亚电子科技有限公司 接收端视频处理方法、装置、设备及存储介质
CN115514684A (zh) * 2021-06-07 2022-12-23 ***通信集团北京有限公司 音频卡顿评估的方法及装置
WO2023051350A1 (zh) * 2021-09-29 2023-04-06 百果园技术(新加坡)有限公司 视频播放档位确定方法、视频播放方法及相关装置
CN116033235A (zh) * 2022-12-13 2023-04-28 北京百度网讯科技有限公司 数据传输方法、数字人生产设备以及数字人显示设备
WO2024051426A1 (zh) * 2022-09-07 2024-03-14 腾讯科技（深圳）有限公司 视频流码率调整方法、装置、计算机设备和存储介质
WO2024141075A1 (zh) * 2022-12-30 2024-07-04 汉熵通信有限公司 视频流码率自适应方法、装置、计算机设备及存储介质

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160286267A1 (en) * 2013-10-30 2016-09-29 Le Shi Zhi Xin Electronic Technology (Tianjin) Lim Ited Code rate switching method and device for smart television
WO2017031692A1 (zh) * 2015-08-25 2017-03-02 华为技术有限公司 视频下载方法、装置及***
CN106791860A (zh) * 2016-12-28 2017-05-31 重庆邮电大学 一种自适应视频编码控制***及方法
CN109714631A (zh) * 2019-02-26 2019-05-03 华南理工大学 一种基于http视频流动态自适应码率选择方法
CN109862403A (zh) * 2019-02-19 2019-06-07 未来电视有限公司 自适应码率切换方法、装置、电子设备及存储介质
CN110198495A (zh) * 2019-06-28 2019-09-03 广州市百果园信息技术有限公司 一种视频下载和播放的方法、装置、设备和存储介质
CN110248247A (zh) * 2019-06-12 2019-09-17 深圳市大数据研究院 基于网络吞吐量的嵌入式动态视频播放控制方法及装置
CN110290402A (zh) * 2019-07-31 2019-09-27 腾讯科技（深圳）有限公司 一种视频码率调整方法、装置、服务器及存储介质
CN110460853A (zh) * 2018-05-07 2019-11-15 上海富瀚微电子股份有限公司 一种高效视频编码码率估计装置及方法
CN111314772A (zh) * 2019-11-29 2020-06-19 广州市百果园信息技术有限公司 一种视频下载码率的确定方法、装置、终端和存储介质
CN112019916A (zh) * 2020-08-26 2020-12-01 广州市百果园信息技术有限公司 一种视频下载的方法、装置、服务器和存储介质

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160286267A1 (en) * 2013-10-30 2016-09-29 Le Shi Zhi Xin Electronic Technology (Tianjin) Lim Ited Code rate switching method and device for smart television
WO2017031692A1 (zh) * 2015-08-25 2017-03-02 华为技术有限公司 视频下载方法、装置及***
CN106791860A (zh) * 2016-12-28 2017-05-31 重庆邮电大学 一种自适应视频编码控制***及方法
CN110460853A (zh) * 2018-05-07 2019-11-15 上海富瀚微电子股份有限公司 一种高效视频编码码率估计装置及方法
CN109862403A (zh) * 2019-02-19 2019-06-07 未来电视有限公司 自适应码率切换方法、装置、电子设备及存储介质
CN109714631A (zh) * 2019-02-26 2019-05-03 华南理工大学 一种基于http视频流动态自适应码率选择方法
CN110248247A (zh) * 2019-06-12 2019-09-17 深圳市大数据研究院 基于网络吞吐量的嵌入式动态视频播放控制方法及装置
CN110198495A (zh) * 2019-06-28 2019-09-03 广州市百果园信息技术有限公司 一种视频下载和播放的方法、装置、设备和存储介质
CN110290402A (zh) * 2019-07-31 2019-09-27 腾讯科技（深圳）有限公司 一种视频码率调整方法、装置、服务器及存储介质
CN111314772A (zh) * 2019-11-29 2020-06-19 广州市百果园信息技术有限公司 一种视频下载码率的确定方法、装置、终端和存储介质
CN112019916A (zh) * 2020-08-26 2020-12-01 广州市百果园信息技术有限公司 一种视频下载的方法、装置、服务器和存储介质

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115514684A (zh) * 2021-06-07 2022-12-23 ***通信集团北京有限公司 音频卡顿评估的方法及装置
CN115514684B (zh) * 2021-06-07 2023-11-10 ***通信集团北京有限公司 音频卡顿评估的方法及装置
CN113784216B (zh) * 2021-08-24 2024-05-31 咪咕音乐有限公司 视频卡顿识别方法、装置、终端设备以及存储介质
CN113784216A (zh) * 2021-08-24 2021-12-10 咪咕音乐有限公司 视频卡顿识别方法、装置、终端设备以及存储介质
WO2023051350A1 (zh) * 2021-09-29 2023-04-06 百果园技术(新加坡)有限公司 视频播放档位确定方法、视频播放方法及相关装置
CN114390320B (zh) * 2022-02-18 2024-02-13 百果园技术(新加坡)有限公司 数据编码码率自适应调节方法、装置、设备和存储介质
CN114390320A (zh) * 2022-02-18 2022-04-22 百果园技术(新加坡)有限公司 数据编码码率自适应调节方法、装置、设备和存储介质
CN115103234A (zh) * 2022-06-07 2022-09-23 慧之安信息技术股份有限公司 基于rtp的图像远程传输方法
CN115174538A (zh) * 2022-06-30 2022-10-11 Oppo广东移动通信有限公司 数据传输方法、装置、电子设备及计算机可读介质
CN115361574A (zh) * 2022-08-15 2022-11-18 广州市奥威亚电子科技有限公司 接收端视频处理方法、装置、设备及存储介质
CN115361574B (zh) * 2022-08-15 2023-09-15 广州市奥威亚电子科技有限公司 接收端视频处理方法、装置、设备及存储介质
WO2024051426A1 (zh) * 2022-09-07 2024-03-14 腾讯科技（深圳）有限公司 视频流码率调整方法、装置、计算机设备和存储介质
CN116033235A (zh) * 2022-12-13 2023-04-28 北京百度网讯科技有限公司 数据传输方法、数字人生产设备以及数字人显示设备
CN116033235B (zh) * 2022-12-13 2024-03-19 北京百度网讯科技有限公司 数据传输方法、数字人生产设备以及数字人显示设备
WO2024141075A1 (zh) * 2022-12-30 2024-07-04 汉熵通信有限公司 视频流码率自适应方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
CN112822521B (zh) 2023-04-25

Similar Documents

Publication Publication Date Title
CN112822521B (zh) 音视频传输的码率控制方法、装置、设备及存储介质
US11489781B2 (en) Bandwidth management
CN101156388B (zh) 用于控制可变位速率数据的数据包传输的产品和方法
AU2014223523B2 (en) Adaptive streaming techniques
EP2974207B1 (en) Playback stall avoidance in adaptive media streaming
JP4838273B2 (ja) メディア内同期化のための適応型メディア再生方法および装置
CN113301392B (zh) 码率确定方法、装置、设备及存储介质
CN101919214B (zh) 适应网络拥塞的***和方法
US20140156863A1 (en) Dash client and receiver with a download rate estimator
US20140136653A1 (en) Dash client and receiver with download rate acceleration
CN103004190B (zh) 视频流传送
CN113891155B (zh) 视频播放档位确定方法、视频播放方法及相关装置
US11916798B2 (en) Estimating network bandwidth using probe packets
JP2009278188A (ja) データ送信装置、データ送信方法、及びプログラム
CN114339269A (zh) 视频传输方法、组播管理平台、终端以及存储介质
CN104581340B (zh) 客户端、流媒体数据接收方法和流媒体数据传输***
JP2007318470A (ja) サーバ装置、送信順序決定方法およびコンテンツ配信システム
CN109218809B (zh) 一种流媒体的播放方法和装置
CN114143271A (zh) 一种基于拥塞检测的带宽估算方法及装置
CN114827681A (zh) 视频同步方法、装置、电子设备、终端设备及存储介质
JP2011244097A (ja) 動画再生端末，動画再生方法及びプログラム
CN115037701B (zh) 视频处理方法、装置、服务器及介质
US7301955B1 (en) Method for smoothing the transmission of a time-sensitive file
US11997366B2 (en) Method and apparatus for processing adaptive multi-view streaming
CN106713316B (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