CN111193673B - 数据传输速率控制方法、系统和用户设备 - Google Patents

数据传输速率控制方法、系统和用户设备 Download PDF

Info

Publication number
CN111193673B
CN111193673B CN202010278035.7A CN202010278035A CN111193673B CN 111193673 B CN111193673 B CN 111193673B CN 202010278035 A CN202010278035 A CN 202010278035A CN 111193673 B CN111193673 B CN 111193673B
Authority
CN
China
Prior art keywords
code rate
updating
data packet
rate adjustment
state
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.)
Active
Application number
CN202010278035.7A
Other languages
English (en)
Other versions
CN111193673A (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.)
Liangfengtai Shanghai Information Technology Co ltd
Original Assignee
Liangfengtai Shanghai Information 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 Liangfengtai Shanghai Information Technology Co ltd filed Critical Liangfengtai Shanghai Information Technology Co ltd
Priority to CN202010278035.7A priority Critical patent/CN111193673B/zh
Publication of CN111193673A publication Critical patent/CN111193673A/zh
Application granted granted Critical
Publication of CN111193673B publication Critical patent/CN111193673B/zh
Priority to EP21784834.0A priority patent/EP4135262A4/en
Priority to PCT/CN2021/076003 priority patent/WO2021203829A1/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894Packet rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/11Identifying congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/22Traffic shaping
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/25Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0829Packet loss
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/10Active monitoring, e.g. heartbeat, ping or trace-route

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种数据传输速率控制方法、系统和用户设备。方法包括:S1、接收外部端发送至本地端的数据包并存储;S2、分别读取最近一次码率调整前后的预设时间内所述本地端中接收到的数据包,并记录读出的数据包的相应数量;S3、判断当前码率调整状态,根据第一判断结果进入增加/减少码率处理流程;其中,所述增加/减少码率处理流程包括根据读出的数据包和相应数量进行码率调整状态更新。本申请外部端和本地端之间传输的统计信息数据少,能准确、迅速的计算出当前带宽,并及时调整码率,很好的实现拥塞控制。

Description

数据传输速率控制方法、系统和用户设备
技术领域
本申请涉及通信技术领域,尤其涉及一种数据传输速率控制方法、系统和用户设备。
背景技术
网络拥塞是基于IP协议的数据包交换网络中常见的一种网络传输问题,它对网络传输的质量有严重的影响,网络拥塞是导致网络吞吐降低,网络丢包等问题的主要原因之一,这些问题使得上层应用无法有效的利用网络带宽获得高质量的网络传输效果。特别是在通信领域,网络拥塞导致的丢包,延迟,抖动等问题,严重影响了通信质量,如果不能很好的解决这些问题,一个通信产品就无法在现实环境中正常使用。
网络拥塞是一个常见的现象,特别是在wifi环境中,网络拥塞会发生的更加频繁。在音视频通话中,网络拥塞能引起网络质量和用户感知的显著下降,主要表现为:电话打入和打出的成功率低,需要多次拨打才成功;通话容易掉线;声音和视频产生卡顿等。
目前比较流行的拥塞控制算法有:
1)Tail Drop算法,如果输出端缓存产生溢出,则新到的数据包被丢弃,该算法不需要选择丢弃的包,只是没有缓存空间时,就会丢弃包。
2)RED算法,该算法基本思想是:通过监控路由器输出端口队列的平均长度来探测拥塞,一旦发现拥塞逼近,就随机地选择连接来通知拥塞,使它们在队列溢出导致丢包之前减小拥塞窗口,降低发送数据速度,从而缓解网络用塞。由于RED是基于FIFO队列调度策略的,并且只是丢弃正进入路由器的数据包,因此其实施起来也较为简单。
3)BLUE算法,使用丢包时间和链路空闲事件来管理网络拥塞,该算法一个丢包概率p,由于队列溢出导致连续丢包时候,算法就会增加p,相反,如果由于链路空闲而出现空队列时,算法就会减少p,所以,BLUE算法能有效的控制发送拥塞通知信息的速度。
4)SFB算法,这是一个FIFO队列算法,和BLUE有点相似,但能识别非响应流的限制器速率。
5)WebRTC中GCC算法,该算法分为两部分,发送端基于丢包率控制码率,接收端基于延迟的码率控制,发送端依靠RTCP RR报文进行工作。WebRTC在发送端收到来自接收端的RTCP RR报文,根据其Report Block中携带的丢包率信息,动态调整发送端码率As。基于延迟的码率控制运行在接收端,WebRTC根据数据包到达的时间延迟,通过到达时间滤波器,估算出网络延迟m(t),然后经过过载检测器判断当前网络的拥塞状况,最后在码率控制器根据规则计算出远端估计最大码率Ar。得到Ar之后,通过RTCP REMB报文返回发送端。发送端综合As、Ar和预配置的上下限,计算出最终的目标码率A,该码率会作用到Encoder、RTP和PacedSender等模块,控制发送端的码率。
6)谷歌在2016年公布的拥塞控制BBR算法,摒弃了复杂的数学模型和理论推理,而是采用实时统计接收包的策略计算发送端的即时上行带宽。它不仅适合在TCP传输模式下使用,也可以在UDP传输模式下使用。该算法极大的提高了TCP的吞吐量(throughput),并且已经集成到Linux 4.9内核。
以上罗列了6种常用的网络拥塞控制算法,虽然各有优点,但都存在不足,这是因为网络拥塞算法主要面临3个难点。
1、网络拥塞的发生是一个变化过程,在这个过程中,网络的实时带宽是随机波动的,而且无规律的,所以快速准确的计算出网络实时带宽是很困难的。
2、视频编码器的码率调整是延后的,不能立即生效,一般要延后1、2秒之后才能产生特定大小的码流。
3、不同的网络发生网络拥塞所表现的现象是不同的,有的数据包丢掉,并且伴随RTT增大,有的RTT没有显著改变,只发生数据包丢包的现象。总之,不同的网络表现出来的现象是千差万别的。这个就给抗网络拥塞算法增加了很大难度。
具体的,Tail Driop、RED、BLUE、SFB算法是针对普通的数据传输,不适用流媒体通话。WebRTC的GCC算法是流媒体的拥塞控制的典型算法,但是其对上述三个问题的处理也不是很全面,它是一种基于延迟预估和丢包的拥塞控制算法,算法分为在接收端进行卡尔曼算法预估后返回发送端进行码率调整两部分。Transport CC算法是基于发送端线性预测的拥塞控制算法,与GCC算法一样主体都是基于时延的拥塞控制判断。这两种算法存在不同程度上的缺陷,在实现算法的过程中过于学术,比如GCC算法中有一个丢包率2%/10%的阈值,但其实拥塞发生并不一定会产生丢包,而且丢包也不一定意味着发生拥塞,这种情况对于GCC算法是失效的。GCC算法基于时延估算的主体在现阶段来看与带宽的记忆丢包没有争抢率,斯坦福大学提出的Salsify算法是基于视频帧之间的时延去估算整个编码器的编码速度,但它一定要在编码器的基础上执行,无法满足将视频传到server上进行分发的要求,如果只做分段拥塞控制就需要在server上进行重解码和重编码,因此无法满足目前实时视频领域的应用。谷歌发布的BBR算法可以用在TCP、UDP协议模式下,但是需要接收端在接收到每个数据包时候,要返回给发送端一个回执,这就大大降低了UDP传输的优越性。另外,BBR算法有4个状态(STARTUP,DRAIN,PROBE_BW,PROBE_RTT),每种状态之间的切换,所以BBR算法不能及时的响应网络拥塞。
发明内容
本申请的目的在于,针对现有技术存在的问题,提供一种数据传输速率控制方法、系统和用户设备,外部端和本地端之间传输的统计信息数据少,能准确、迅速的计算出当前带宽,并及时调整本地端向外部端发送数据的码率。
为实现上述目的,本申请提供了一种数据传输速率控制方法,所述方法包括如下步骤:S1、接收外部端发送至本地端的数据包并存储;S2、分别读取最近一次码率调整前后的预设时间内所述本地端中接收到的数据包,并记录读出的数据包的相应数量;以及S3、判断当前码率调整状态,根据第一判断结果进入增加/减少码率处理流程;其中,所述增加/减少码率处理流程包括根据读出的数据包和相应数量进行码率调整状态更新。
为实现上述目的,本申请还提供了一种数据传输速率控制系统,所述系统包括:接收存储模块,用于接收外部端发送至本地端的数据包并存储;读取记录模块,用于分别读取最近一次码率调整前后的预设时间内所述接收存储模块接收到的数据包,并记录读出的数据包的相应数量;码率调整控制模块,用于判断当前码率调整状态,根据第一判断结果调用增加/减少码率处理模块;所述增加/减少码率处理模块,用于进行增加/减少码率处理;其中,所述增加/减少码率处理包括根据所述读取记录模块读取的数据包和相应数量进行码率调整状态更新。
为实现上述目的,本申请还提供了一种用于数据传输速率控制的用户设备,所述用户设备包括:处理器;以及存储器,用于存储一个或多个计算机可执行指令;其中,当所述可执行指令在被所述处理器执行时,使得本申请所述方法被执行。
为实现上述目的,本申请还提供了一种计算机可读介质,所述计算机可读存储介质存储有计算机可执行指令,当所述计算机可执行指令被执行时,使得本申请所述方法被执行。
本申请的优点在于:外部端和本地端之间传输的统计信息数据少,能准确、迅速的计算出当前带宽,并及时调整本地端向外部端发送数据的码率,很好的实现拥塞控制。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1A为本申请数据传输速率控制方法的架构流程图;
图1B为本申请数据传输速率控制方法的实施流程图;
图2为本申请增加码率处理流程一实施例的流程图;
图3为本申请减少码率处理流程一实施例的流程图,
图4为本申请数据传输速率控制系统的架构示意图;
图5为本申请用于数据传输速率控制的用户设备的架构示意图。
具体实施方式
下面详细描述本申请的实施方式,所述实施方式的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参阅附图描述的实施方式是示例性的,仅用于解释本申请,而不能理解为对本申请的限制。
在本申请的描述中,需要说明的是,除非另有明确的规定和限定,术语“安装”、“相连”、“连接”应做广义理解,例如,可以是固定连接,也可以是可拆卸连接,或一体地连接;可以是机械连接,也可以是电连接或可以相互通讯;可以是直接相连,也可以通过中间媒介间接相连,可以是两个元件内部的连通或两个元件的相互作用关系。对于本领域的普通技术人员而言,可以根据具体情况理解上述术语在本申请中的具体含义。
下文的公开提供了许多不同的实施方式或例子用来实现本申请的不同结构。为了简化本申请的公开,下文中对特定例子的部件和设置进行描述。当然,它们仅仅为示例,并且目的不在于限制本申请。此外,本申请可以在不同例子中重复参考数字和/或参考字母,这种重复是为了简化和清楚的目的,其本身不指示所讨论各种实施方式和/或设置之间的关系。此外,本申请提供了的各种特定的工艺和材料的例子,但是本领域普通技术人员可以意识到其他工艺的应用和/或其他材料的使用。而且,描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
本申请以本地端为当前的客户端,外部端为外部的服务器进行说明。本申请所述数据传输速率控制方法所采用的网络拥塞控制算法位于客户端上。需要说明的是,其中外部端也可以为其他客户端。
当客户端发送数据(例如,音视频数据)给服务器后,服务器会根据接收的数据发送相关数据包给客户端。客户端将接收到的数据包进行存储,例如存储在客户端上的数据池中,数据池代表客户端上的一个接收存储模块,其中,数据包的存储位置不进行限定,除数据池外,也可以存储在客户端的其它存储模块上,以下以存储在数据池中进行说明。本申请一实施例的具体处理流程为:数据池不断接收到数据包,执行本申请网络拥塞控制算法:读取数据池中符合预设条件的数据包信息,然后判断当前码率调整状态以执行增加/减少码率处理流程,处理流程得到的对当前码率的调整结果就是下一次客户端向服务器发送数据的目标码率。其中,在增加/减少码率处理流程中,进一步判断所述增加/减少码率处理流程的循环状态;若循环状态为继续循环,则返回重新判断当前码率调整状态以执行增加/减少码率处理流程;若循环状态为停止循环,则满足预设条件后,重新执行本申请网络控制算法(读取数据池中符合预设条件的数据包信息,然后判断状态以执行增加/减少码率处理流程)。
本申请网络拥塞控制算法是一个独立的线程,由客户端按预设条件(例如预设时间,如每隔1秒)调用,并利用数据池中的数据包进行计算。例如,大概1秒左右线程会执行当前算法一次,算法的计算结果就是改变客户端向服务器发送数据的目标码率。同时,服务器也会在预设时间(例如1秒)间隔后,发送相关的数据包过来,这些数据包就放在数据池中。
为了便于说明,对本申请网络拥塞控制算法的增加/减少码率处理流程中涉及的变量做如下定义:
rtt:该算法中的心跳值
avg_rtt:平均心跳值;avg_rtt=(rtt0 + …+rttn)/(n+1)
time_ms:距离上一次服务器发送数据包的时间间隔,单位毫秒
avg_time_ms:平均时间间隔;avg_time_ms=(time_ms0 + … +time_msn)/(n+1)
sent_size:在time_ms的间隔内,服务器接收到客户端发送的数据的数据字节数,单位字节
avg_sent_size:平均数据字节数;avg_sent_size=(sent_size0 + … +sent_sizen)/(n+1)
lost:客户端发送到服务器的数据的丢包率
avg_lost:平均丢包率;avg_lost=(lost0 + … +lostn)/(n+1)
received_ts:数据池每次把服务器发送的数据包存储时,打印的时间戳
change_ts:该算法最近一次调整码率的时间戳,单位毫秒
pre_num:读出的最近一次码率调整前的数据包的数量
last_num:读出的最近一次码率调整后的数据包的数量
time_out:表示最近一次改变码率之后超过预设时间(例如4秒钟),但是数据池没有接收到服务器发送过来的任何数据,说明网络现在严重拥塞;这个变量在增加/减少码率处理流程中会更新
loop:循环标志位,它在增加/减少码率处理流程中会更新;loop=true,表示继续循环,此时立即执行判断当前码率调整状态,重新进入增加/减少码率处理流程;loop=false,表示停止循环,等到符合预设条件后下一次调用算法,再重新读取数据,然后重新执行判断当前码率调整状态,并进入增加/减少码率处理流程。
increase_tab: 增加码率表;例如设定如下码率增加值的增加码率表{50K,50K,50K,50K,100K,200K,200K,800K}
cur_index:增加码率表的当前索引;例如针对设有8个码率增加值的增加码率表,设定索引范围为[0:7],初始化为0
cur_bitrate:当前码率
target_bitrate:目标码率;算法每次运行之初,设置target_bitrate=cur_bitrate
status:该算法的当前码率调整状态,总共有五种状态,分别是:
kIncreasing:码率增加之中
kIncreased:码率增加之后
kDecreasingWithServer:根据服务器发送的数据包减少码率
kDecreasingNotWithServer:不根据服务器发送的数据包减少码率
kDecreased:码率减少之后。
请一并参阅图1A-图1B,其中,图1A为本申请数据传输速率控制方法的架构流程图,图1B为本申请数据传输速率控制方法的实施流程图。
如图1A所示所述数据传输速率控制方法包括如下步骤:S1、接收外部端发送至本地端的数据包并存储;S2、分别读取最近一次码率调整前后的预设时间内所述本地端中接收到的数据包,并记录读出的数据包的相应数量;S3、判断当前码率调整状态,根据第一判断结果进入增加/减少码率处理流程;其中,所述增加/减少码率处理流程包括根据读出的数据包和相应数量进行码率调整状态更新。以下给出详细说明。
关于步骤S1、接收外部端发送至本地端的数据包并存储。
本地端发送数据到外部端后,外部端会根据接收的数据每隔预设时间(例如1秒)发送相关数据包给本地端。以本地端为当前的客户端,外部端为外部的服务器进行说明。需要说明的是,其中外部端也可以为其他客户端。客户端将接收到的数据包进行存储,例如存储在客户端上的数据池中,数据池代表客户端上的一个接收存储模块,其中,数据包的存储位置不进行限定,除数据池外,也可以存储在客户端的其它存储模块上,以下以存储在数据池中进行说明。
进一步的实施例中,所述数据包包括以下至少其中之一:距离上一次所述外部端向所述本地端发送数据包的时间间隔time_ms;在所述时间间隔内,所述外部端接收到所述本地端发送的数据的数据字节数sent_size;在所述时间间隔内,总共发生的丢包率lost。数据池在接收并缓存服务器发送来的数据包的时候,进一步给数据包打印添加一个时间戳received_ts,供后续使用。
关于步骤S2、分别读取最近一次码率调整前后的预设时间内所述本地端中接收到的数据包,并记录读出的数据包的相应数量。
进一步的实施例中,如图1B所示,所述步骤S2进一步包括:S21、读取最近一次码率调整之前预设时间内所述本地端接收的数据包,并记录读出的数据包的第一数量;S22、读取最近一次码率调整之后预设时间内所述本地端接收的数据包,并记录读出的数据包的第二数量;以及S23、根据接收数据包时打印的时间戳对应的心跳值,为所述步骤S21、步骤S22读取的每一数据包添加对应的心跳值。
具体的,第一步:找到change_ts-5000< received_ts <=change_ts的数据包,读出来的数据包个数记为第一数量pre_num;即读取比最近一次调整码率的时间戳change_ts小(预设时间内)的数据池对应接收到的数据包,读取到一个数据包、pre_num值增加一。在一些实施例中,pre_num最多不超过8个。第二步:找到change_ts+2000 <=received_ts的数据包,读出来的数据包个数记为第二数量last_num;即读取比change_ts大(预设时间内)的数据池对应接收到的数据包,读取到一个数据包、last_num值增加一。在一些实施例中,last_num最多不超过8个。第三步:找到打印时间戳received_ts时候的心跳值rtt,然后给第一、二步找出来的数据包添加上它们当时对应的心跳值rtt。需要说明的是,第一数量和第二数量不超过8个的设置可以根据调整精度、调整速率等实际要求作出改变,本申请对此不作限定。另外,上述预设时间仅为举例,也可以根据实际情况灵活改变,例如,第一步找到的是change_ts-3000< received_ts <=change_ts的数据包,第二步找到的是change_ts+3000 <=received_ts的数据包,本申请对此不作限定。
S3、判断当前码率调整状态,根据第一判断结果进入增加/减少码率处理流程;其中,所述增加/减少码率处理流程包括根据读出的数据包和相应数量进行码率调整状态更新。
在一些实施例中,根据当前码率调整状态,进入增加码率处理流程,或者进入减少码率处理流程。进一步的实施例中,如图1B所示,所述步骤S3进一步包括:S31、判断当前码率调整状态,获取第一判断结果;若第一判断结果为增加,则进入增加码率处理流程(S32),若第一判断结果为减少则进入减少码率处理流程(S33),其中,所述增加码率处理流程与减少码率处理流程均包括根据读出的数据包和相应数量进行码率调整状态更新;以及S34、判断所述增加/减少码率处理流程的循环状态,获取第二判断结果;若第二判断结果为继续循环,则继续重新进入执行步骤S3,以执行判断当前码率调整状态操作,若第二判断结果为停止循环,则停止执行所述增加/减少码率处理流程。优选的,在停止执行所述增加/减少码率处理流程后,当满足预设条件后,重新调用本算法,即返回依次执行步骤S2数据包读取和步骤S3判断当前码率调整状态操作。
进一步的实施例中,若当前码率调整状态为码率增加之中或码率增加之后时,进入增加码率处理流程,否则进入减少码率处理流程。即,具体是进入增加码率处理流程,还是进入减少码率处理流程主要是判断status变量。而在status变量判断时,执行status==kIncreasing || status==kIncreased的判断。其中,“|| ”表示逻辑运算符“或”,逻辑或的运算规则是一个为真即为真,后续不再计算,直接进入增加码率处理流程;左边的表达式为假再计算右边的表达式,左右均为假时进入减少码率处理流程。
进一步的实施例中,预设所述码率调整状态的初始状态为码率增加之中kIncreasing。即客户端第一次调用算法时,对应的码率调整状态为码率增加之中kIncreasing,然后进入增加码率处理流程,在增加码率处理流程中进行码率调整状态更新;后续再调用算法时,当前码率调整状态是上一次的码率调整状态的结果。
进一步的实施例中,所述增加码率处理流程包括如下步骤:
S311、判断所述码率调整状态是否为码率增加之中,若是则直接增加码率、更新所述码率调整状态为码率增加之后、更新循环状态为停止循环,停止执行增加码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3,否则执行步骤S312。在一些实施例中,所述返回依次执行步骤S2和步骤S3,即,重新调用算法,先读取最近一次码率调整前后的预设时间内所述数据池中的数据包,然后判断当前码率调整状态。由于当前码率调整状态为码率增加之后,所以后续进入增加码率处理流程。其中,所述预设条件可以是预设时间,例如满足等待1秒后再启动/调用这个算法依次执行步骤S2和S3。需要说明的是,所述预设时间为1秒仅为举例,可以根据实际的网络情况作出改变,本申请不作限定;
S312、判断所述第二数量是否大于0,若是则执行步骤S313,否则执行步骤S314;
S313、判断所述第二数量是否大于一预设数量阈值,若是则根据读出的数据包以及相应数量进行码率调整状态更新,否则更新循环状态为停止循环,停止执行增加码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3。在一些实施例中,所述返回依次执行步骤S2和步骤S3,即,重新调用算法,先读取最近一次码率调整前后的预设时间内所述数据池中的数据包,然后判断当前码率调整状态,由于当前码率调整状态仍为码率增加之后,所以后续进入增加码率处理流程;
S314、判断当前时间距离最近一次码率调整的时间是否大于预设时间阈值,若是则更新所述码率调整状态为不根据外部端发送的数据包减少码率,并更新循环状态为继续循环,继续重新进入执行步骤S3,否则,更新循环状态为停止循环,停止执行增加码率处理流程并满足预设条件后返回依次执行步骤S2和S3。在一些实施例中,所述继续重新进入执行步骤S3,即,继续重新判断当前码率调整状态,而不需要等待满足预设条件后才调用该算法。由于当前码率调整状态为不根据外部端发送的数据包减少码率,所以后续直接进入减少码率处理流程。
进一步的实施例中,为了优化算法的执行效果,在所述步骤S312中判定所述第二数量大于0之后进一步执行以下步骤:判断读取的最近一次码率调整之后预设时间内所述数据池接收的数据包,是否有突发的变化(checksmooth),若没有突发的变化(smooth)则执行步骤S313,若有突发的变化,则更新所述码率调整状态为根据外部端发送的数据包减少码率,并更新循环状态为继续循环,继续重新进入执行步骤S3。在一些实施例中,所述继续重新进入执行步骤S3,即,继续重新判断当前码率调整状态,而不需要等待满足预设条件后才调用该算法。由于当前码率调整状态为根据外部端发送的数据包减少码率,所以后续直接进入减少码率处理流程。
具体判断是否有突发的变化的判断机制为:根据读取的最近一次码率调整之后预设时间内所述数据池接收的数据包中每一数据包中的丢包率、心跳值,以及读取的数据包的总数量last_num,计算平均丢包率、平均心跳值,若所述平均丢包率小于预设丢包阈值(例如15,不同的网络情况阈值设置也可不同)以及所述平均心跳值小于预设心跳阈值(例如200,不同的网络情况阈值设置也可不同),则判定没有突发的变化,否则判定有突发的变化。需要说明的是,平均丢包率、平均心跳值的判断也可以择一执行,即,可以仅计算平均丢包率、并判断所述平均丢包率是否小于预设丢包阈值,若平均丢包率小于预设丢包阈值,则判定没有突发的变化,否则判定有突发的变化。或仅计算平均心跳值、并判断所述平均心跳值是否小于预设心跳阈值,若平均心跳值小于预设心跳阈值,则判定没有突发的变化,否则判定有突发的变化。
请参阅图2,本申请增加码率处理流程一实施例的流程图,以下给出详细说明。
S201、进入增加码率处理流程后,先判断所述码率调整状态是否为码率增加之中(status==kIncreasing),对应步骤S311。
S202、若status==kIncreasing则直接增加码率、更新所述码率调整状态为码率增加之后(status=kIncreased)、并置loop=false,对应步骤S311。即当status处于kIncreasing状态时,增加码率;之后status变为kIncreased;同时增加码率处理流程应该结束,所以对应的loop=false,表示退出此次算法,等待符合预设条件(例如,等待1秒)后下一次再启动/调用这个算法;下次启动算法后,依次执行步骤S2数据包读取和步骤S3判断当前码率调整状态操作;在步骤S3中,由于status==kIncreased,所以仍进入增加码率处理流程。
进一步的实施例中,所述的直接增加码率的操作为:将目标码率调整为当前码率与当前索引对应的增加码率表中的码率之和,之后所述当前索引自增。即target_bitrate=cur_bitrate + increase_tab[cur_index++];其中,cur_index++是先执行表达式后再自增,执行表达式时使用的是cur_index的原值。优选的,对所述当前索引自增后做边界判断,若所述当前索引自增后超过预设索引的最大值边界,则设定所述当前索引为所述最大值;即对于索引范围为[0:7],如果cur_index++超过7,则cur_index设为7。另外,整个算法共用一个cur_index。需要说明的是,上述increase_tab和cur_index的取值仅为举例,可以根据实际的网络情况作出改变,本申请对此不作限定。
S203、若status不为kIncreasing,则status==kIncreased,进一步判断读取的最近一次码率调整之后预设时间内所述数据池接收的数据包的数量last_num是否大于0,对应步骤S312。
S204、如果last_num>0,说明码率增加之后数据池接收到了服务器发送的数据包,此时要检测该数据包是不是有突发变化(checksmooth)。
checksoomth是判断输入的参数里面丢包率、心跳值是不是有突发的变化。主要是以读取的最近一次码率调整之后预设时间内所述数据池接收的数据包及对应的数量last_num为参数,来判断码率调整后的情况。具体的:计算last_num个数据包中的avg_rtt和avg_lost,如果avg_lost小于15,并且avg_rtt小于200,则认为是没有突发变化(即为soomth的)。可选地,avg_rtt、avg_lost的判断也可以择一执行。
S205、如果数据包有突发变化,则status变为KDecreasingWithServer(根据服务器发送的数据包减少码率),对应的loop=true。即表示继续循环、重新进入执行步骤S3,即立即判断status,由于status==KDecreasingWithServer,则直接进入减少码率处理流程,此时不用暂停等待符合预设条件(例如,等待1秒)后下一次再启动/调用这个算法。
S206、如果数据包没有突发变化,进一步判断last_num是否大于一预设数量阈值(例如3),对应步骤S313。
S207、如果last_num>预设数量阈值,则根据读出的最近一次码率调整前后的数据包以及相应数量进行码率调整状态更新,对应步骤S313。
S208、如果last_num<=0,说明码率增加之后数据池没有接收到服务器发送的数据包,进一步判断时间是否足够(time_out),对应步骤S314。
S209、如果时间足够了(time_out==true),则表示网络堵塞,此时应该降低码率,所以status变为KDecreasingNotWithServer(不根据服务器发送的数据减少码率(例如直接降码率降到目前码率的一半)),对应的loop=true,对应步骤S314。即表示继续循环、重新进入执行步骤S3,即立即判断status,由于status==KDecreasingNotWithServer,则直接进入减少码率处理流程,此时不用暂停等待符合预设条件(例如,等待1秒)后下一次再启动/调用这个算法。
S210、如果last_num<=预设数量阈值,或如果时间并未足够(time_out==false),则置loop=false(分别对应步骤S313、步骤S314)。即表示退出此次算法,等待符合预设条件(例如,等待1秒)后下一次再启动/调用这个算法依次执行步骤S2和步骤S3。
需要说明的是,上述last_num的预设数量阈值和time_out的取值仅为举例,可以根据实际的网络情况作出改变,例如,time_out可以取值为1-10之间数值等其它值,预设数量阈值也可以为2或4等其它值,本申请对此不作限定。
由图2所示流程图可以看出增加码率处理流程的处理过程为:
a)如果目前status处于kIncreasing,则直接增加码率。
b)如果上次改变码率后(对应status=kIncreased),数据池没有接收到服务器发送的数据包,这个时候,就要判断服务器为什么没有发送数据过来。有两种原因:一是现在距离上次调整码率时间足够了(time_out==true),则说明当前网络严重拥塞,则算法应不按照服务器发送过来的数据降低码率;二是现在距离上次调整码率时间还不够长(time_out==false),则继续等待服务器发送足够多的数据包再来分析。
c)如果距离上次调整码率之后(对应status==kIncreased),数据池接收到足够多的数据包,可选地,同时这些数据包不存在突发的变化,就可以凭借这些数据包来分析上次调整码率的效果,即根据读出的最近一次码率调整前后的数据包以及相应数量进行码率调整状态更新。
进一步的实施例中,根据读出的最近一次码率调整前后的数据包以及相应数量进行码率调整状态更新的操作具体为:1)根据读取的最近一次码率调整之前预设时间内所述数据池接收的数据包,以及记录的读出的数据包的第一数量,计算最近一次码率调整之前的第一网络分数;即分析调整码率之前的网络状况,用分数来评判。2)根据读取的最近一次码率调整之后预设时间内所述数据池接收的数据包,以及记录的读出的数据包的第二数量,计算最近一次码率调整之后的第二网络分数;即分析调整码率之后的网络状况,用分数来判断。3)根据所述第一网络分数与所述第二网络分数,更新所述码率调整状态;即根据得到的调整码率前后的分数,更新码率调整状态。
进一步的实施例中,所述第一网络分数的计算方法为:根据读取的最近一次码率调整之前预设时间内所述数据池接收的数据包中,每一数据包中的丢包率和心跳值,以及所述第一数量,计算平均丢包率和平均心跳值,根据计算结果获取所述第一网络分数;所述第二网络分数的计算方法为:根据读取的最近一次码率调整之后预设时间内所述数据池接收的数据包中,每一数据包中的丢包率和心跳值,以及所述第二数量,计算平均丢包率和平均心跳值,根据计算结果获取所述第二网络分数。
以下结合实施例进行说明。以读取的最近一次码率调整之前预设时间内所述数据池接收的数据包中,每一数据包中的丢包率lost和心跳值rtt,以及第一数量pre_num为例。先计算pre_num个数据包的avg_rtt、avg_lost,然后按照下面的伪代码来计算第一网络分数:
if ((avg_lost<=VIDEO_LOST_BEST_VAL) && (avg_rtt<=VIDEO_RTT_BEST_VAL))
score=VIDEO_NET_BEST_SCORE;
else if ((avg_lost<=VIDEO_LOST_BETTER_VAL) && (avg_rtt<=VIDEO_RTT_BETTER_VAL))
score=VIDEO_NET_BETTER_SCORE;
else if ((avg_lost<=VIDEO_LOST_NORMAL_VAL) && (avg_rtt<=VIDEO_RTT_NORMAL_VAL))
score=VIDEO_NET_NORMAL_SCORE;
else
score=VIDEO_NET_BAD_SCORE;
其中,“&&”表示逻辑运算符“与”;逻辑与,先运算&&左边的表达式,一旦为假,后续不管多少表达式,均不再计算,左边的表达式为真,再计算右边的表达式,左右两个表达式均为真才为真。
理论上,avg_rtt和avg_lost越小越好,根据这个规则去设定上面的一些变量的阈值,举例如下:
VIDEO_LOST_BEST_VAL: 0
VIDEO_RTT_BEST_VAL: 20
VIDEO_LOST_BETTER_VAL: 7
VIDEO_RTT_BETTER_VAL: 100
VIDEO_LOST_NORMAL_VAL: 15
VIDEO_ RTT _NORMAL_SCORE: 200
VIDEO_NET_BEST_SCORE: 100
VIDEO_NET_BETTER_SCORE: 75
VIDEO_NET_NORMAL_SCORE: 60
VIDEO_NET_ BAD _SCORE: 30。
同样地,针对读取的最近一次码率调整之后预设时间内所述数据池接收的数据包中,每一数据包中的丢包率lost和心跳值rtt,以及第二数量last_num,先计算last_num个数据包的avg_rtt、avg_lost,按照上面的伪代码来计算第二网络分数,上述变量阈值的设置可以相同或不同。需要说明的是,上述变量阈值仅为举例,可以灵活作出改变,本申请对此不作限定。
进一步的实施例中,根据所述第一网络分数与所述第二网络分数,更新所述码率调整状态的步骤进一步包括:对所述第一网络分数与所述第二网络分数进行运算,获取运算结果执行以下步骤的至少其中之一:
1)增加码率表的当前索引自增,更新所述码率调整状态为码率增加之中,并更新循环状态为继续循环,继续重新进入执行步骤S3。在一些实施例中,所述继续重新进入执行步骤S3,即,继续重新判断当前码率调整状态,而不需要等待满足预设条件后才调用该算法。由于当前码率调整状态为码率增加之中,所以后续直接进入增加码率处理流程;
2)增加码率表的当前索引置0,更新所述码率调整状态为码率增加之中,并更新循环状态为继续循环,继续重新进入执行步骤S3;
3)降低当前码率后将增加码率表的当前索引置0,更新所述码率调整状态为码率增加之中,并更新循环状态为继续循环,继续重新进入执行步骤S3;
4)更新所述码率调整状态为码率增加之后,并更新循环状态为停止循环,停止执行增加/减少码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3。在一些实施例中,所述返回依次执行步骤S2和步骤S3,即,重新调用算法,先读取最近一次码率调整前后的预设时间内所述数据池中的数据包,然后判断当前码率调整状态;由于当前码率调整状态为码率增加之后,所以后续进入增加码率处理流程。其中,所述预设条件可以是预设时间,例如满足等待1秒后再启动/调用这个算法依次执行步骤S2和步骤S3;
5)更新所述码率调整状态为根据外部端发送的数据包减少码率、并更新循环状态为继续循环,继续重新进入执行步骤S3。在一些实施例中,所述继续重新进入执行步骤S3,即,继续重新判断当前码率调整状态,而不需要等待满足预设条件后才调用该算法。由于当前码率调整状态为根据外部端发送的数据包减少码率,所以后续直接进入减少码率处理流程;
6)报错或退出。在一些实施例中,根据运算结果可以输出报错信息或者退出此次算法。
以下结合实施例进行说明。pre_score代表码率调整前的第一网络分数,last_score表示码率调整后的第二网络分数。先执行如下表达式:
score=(pre_score << 16) |last_score
其中,“<<”表示左移运算符,将二进制位往左移若干位,右边补0;“|”表示按位或,按位或的计算方式是转换二进制再计算,运算规则是一个为真即为真,例如1|0=1,1|1=1,0|0=0,0|1=1。
a)如果上述表达式运算所得score等于下面数组T1中的任意一个值,则cur_index++,并且对cur_index边界做判断[0:7],status=kIncreasing, loop=true(loop=true表示继续重新进入执行步骤S3,立即判断当前status状态,由于status==kIncreasing,所以后续直接进入码率增加处理流程,不用等到满足预设条件(例如,等待1秒)后下一次再调用算法);
T1={(VIDEO_NET_BEST_SCORE<<16) | VIDEO_NET_BEST_SCORE,
(VIDEO_NET_BETTER_SCORE << 16) | VIDEO_NET_BEST_SCORE,
(VIDEO_NET_NORMAL_SCORE<< 16) | VIDEO_NET_BEST_SCORE,
(VIDEO_NET_BAD_SCORE << 16) | VIDEO_NET_BEST_SCORE,
(VIDEO_NET_NORMAL_SCORE<<16)|VIDEO_NET_BETTER_SCORE,
(VIDEO_NET_BAD_SCORE << 16) | VIDEO_NET_BETTER_SCORE }
需要说明的是,上述T1中的值仅为举例,主要表达码率调整之后网络状况比较好的含义,因此也可以是其它能够表达上述含义的值,本申请对此不作限定。
b)如果上述表达式运算所得score等于下面数组T2中任意一个值,则cur_index=0,status=kIncreasing,loop=true;
T2={(VIDEO_NET_BEST_SCORE<<16)| VIDEO_NET_BETTER_SCORE,(VIDEO_NET_BETTER_SCORE<<16)| VIDEO_NET_BETTER_SCORE}
需要说明的是,上述T2中的值仅为举例,主要表达码率调整前后网络状况都好的含义,因此也可以是其它能够表达上述含义的值,本申请对此不作限定。
c) 如果上述表达式运算所得score等于下面数组T3中任意一个值,则target_bitrate=cur_bitrate - increase_tab[cur_index],cur_index=0,status=kIncreasing,loop=true;
T3={(VIDEO_NET_BEST_SCORE<<16)| VIDEO_NET_NORMAL_SCORE, (VIDEO_NET_BETTER_SCORE<<16)|VIDEO_NET_NORMAL_SCORE}
需要说明的是,上述T3中的值仅为举例,主要表达码率调节前网络状况好,码率调整之后网络状况一般的含义,因此也可以是其它能够表达上述含义的值,本申请对此不作限定。
d)如果上述表达式运算所得score等于下面数组T4中任意一个值,则status=kIncreased,loop=false;
T4={(VIDEO_NET_NORMAL_SCORE<<16)| VIDEO_NET_NORMAL_SCORE,(VIDEO_NET_BAD_SCORE << 16) | VIDEO_NET_NORMAL_SCORE}
需要说明的是,上述T4中的值仅为举例,主要表达码率调整前网络状态差/一般,码率调整后网络状况一般的含义,因此也可以是其它能够表达上述含义的值,本申请对此不作限定。
e)如果上述表达式运算所得score等于下面数组T5中任意一个值,则status=kDecreasingWithServer,loop=true;
T5={(VIDEO_NET_BEST_SCORE<<16) | VIDEO_NET_BAD_SCORE, (VIDEO_NET_BETTER_SCORE<<16)|VIDEO_NET_BAD_SCORE,(VIDEO_NET_NORMAL_SCORE<<16)|VIDEO_NET_BAD_SCORE,(VIDEO_NET_BAD_SCORE << 16) | VIDEO_NET_BAD_SCORE}
需要说明的是,上述T5中的值仅为举例,主要表达码率调整之后网络状况差的含义,因此也可以是其它能够表达上述含义的值,本申请对此不作限定。
f) 报错或退出算法。
进一步的实施例中,所述减少码率处理流程包括如下步骤:
S321、判断所述码率调整状态是否为根据外部端发送的数据包减少码率,若是则根据外部端发送的数据包计算目标码率、更新所述码率调整状态为码率减少之后、更新循环状态为停止循环,停止执行减少码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3,否则执行步骤S322。在一些实施例中,所述返回依次执行步骤S2和步骤S3,即,重新调用算法,先读取最近一次码率调整前后的预设时间内所述数据池中的数据包,然后判断当前码率调整状态。由于当前码率调整状态为码率减少之后,所以后续进入减少码率处理流程。其中,所述预设条件可以是预设时间,例如满足等待1秒后再启动/调用这个算法并依次执行步骤S2和步骤S3;
S322、判断所述码率调整状态是否为不根据外部端发送的数据包减少码率,若是则将减少当前码率、更新所述码率调整状态为码率减少之后、更新循环状态为停止循环,停止执行减少码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3,否则执行步骤S323;
S323、判断所述第二数量是否大于0,若是则执行步骤S324,否则执行步骤S325;
S324、判断所述第二数量是否大于一预设数量阈值,若是则根据读出的数据包以及相应数量进行码率调整状态更新,否则更新循环状态为停止循环,停止执行减少码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3;
S325、判断当前距离最近一次码率调整的时间是否大于预设时间阈值,若是则更新所述码率调整状态为不根据外部端发送的数据包减少码率,并更新循环状态为继续循环,继续重新进入执行步骤S3,否则更新循环状态为停止循环,停止执行减少码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3。在一些实施例中,所述继续重新进入执行步骤S3,即,继续重新判断当前码率调整状态,而不需要等待满足预设条件后才调用该算法。由于当前码率调整状态为不根据外部端发送的数据包减少码率,所以后续直接进入减少码率处理流程。
进一步的实施例中,为了优化算法的执行效果,在所述步骤S323中判定所述第二数量大于0之后进一步执行以下步骤:判断读取的最近一次码率调整之后预设时间内所述数据池接收的数据包,是否有突发的变化,若没有突发的变化则执行步骤S324,若有突发的变化,则更新所述码率调整状态为根据外部端发送的数据包减少码率,并更新循环状态为继续循环,继续重新进入执行步骤S3。在一些实施例中,所述继续重新进入执行步骤S3,即,继续重新判断当前码率调整状态,而不需要等待满足预设条件后才调用该算法。由于当前码率调整状态为根据外部端发送的数据包减少码率,所以后续直接进入减少码率处理流程。具体判断是否有突发的变化的判断机制与上述增加码率处理流程中的判断是否有突发的变化的判断机制相同,此处不再赘述。
请参阅图3,本申请减少码率处理流程一实施例的流程图,以下给出详细说明。
S301、进入减少码率处理流程后,先判断所述码率调整状态是否为根据服务器发送的数据包减少码率(status==kDecreasingWithServer),对应步骤S321。
S302、若status==kDecreasingWithServer,执行减少码率1(根据服务器发送的数据包计算目标码率),更新所述码率调整状态为码率减少之后(status=kDecreased)、并置loop=false,对应步骤S321。即当status处于KDecreasingWithServer时,减少码率;之后status变为kDecreased;同时减少码率处理流程应该结束,所以对应的loop=false,表示退出此次算法,等待满足预设条件(例如,等待1秒)后下一次再启动/调用这个算法;下次启动算法后,依次执行步骤S2和步骤S3;在步骤S3中,由于status==kDecreased,所以仍进入减少码率处理流程。
进一步的实施例中,所述的根据服务器发送的数据包计算目标码率的操作为:根据读取的最近一次码率调整之后预设时间内所述数据池接收的数据包中,每一数据包中的数据字节数sent_size、时间间隔time_ms,以及所述第二数量last_num,计算平均数据字节数avg_sent_size以及平均时间间隔avg_time_ms;根据所述平均数据字节数avg_sent_size以及所述平均时间间隔avg_time_ms计算获取目标码率target_bitrate。
目标码率target_bitrate的表达式可以为:
target_bitrate=(avg_sent_size * K1 / avg_time_ms) * K2;
其中,K1为单位换算系数;例如target_bitrate的单位是bps;avg_sent_size的单位是字节(Byte),1Byte=8 bit;avg_time_ms 的单位是毫秒,1秒=1000毫秒;所以这里单位换算系数K1取8000。K2为预设调整系数,例如0.65。需要说明的是,此处K1、K2取值仅为举例,K1可以根据不同的单位进行调整,K2也可以根据实际的网络情况作出改变,本申请对此不作限定。
S303、若status不为kDecreasingWithServer,则进一步判断码率调整状态是否为不根据服务器发送的数据包减少码率(status==kDecreasingNotWithServer),对应步骤S322。
S304、若status==kDecreasingNotWithServer,则执行减少码率2(直接减少当前码率),更新所述码率调整状态为码率减少之后(status=kDecreased)、并置loop=false,对应步骤S322。即当status处于KDecreasingNotWithServer时,减少码率;之后status变为kDecreased;同时减少码率处理流程应该结束,所以对应的loop=false,表示退出此次算法,等待满足预设条件(例如,等待1秒)后下一次再启动/调用这个算法;下次启动算法后,依次执行步骤S2和步骤S3;在步骤S3中,由于status==kDecreased,所以仍进入减少码率处理流程。其中,所述直接减少当前码率操作,例如,可以将目标码率降到当前码率的一半。需要说明的是,此处直接减少当前码率一半仅为举例,此处表示不根据服务器发送的数据减少码率,例如还可将目标码率降到当前码率的三分之一等,可以根据实际的网络情况作出改变,本申请对此不作限定。
S305、若status不为kDecreasingNotWithServer,则进一步判断读取的最近一次码率调节调整之后预设时间内所述数据池接收的数据包的数量last_num是否大于0,对应步骤S323。
S306、如果last_num>0,说明码率减少之后数据池接收到了服务器发送的数据包,此时要检测该数据包是不是有突发变化(checksmooth),参照增加码率处理流程中的checksoomth,此处不再赘述。
S307、如果数据包有突发变化,则status变为KDecreasingWithServer(根据服务器发送的数据包减少码率),对应的loop=true。即表示继续循环、重新进入执行步骤S3,即立即判断status,由于status==KDecreasingWithServer,则直接进入减少码率处理流程,此时不用暂停等待满足预设条件(例如,等待1秒)后下一次再启动/调用这个算法。
S308、如果数据包没有突发变化,进一步判断last_num是否大于一预设数量阈值(例如3),对应步骤S324。
S309、如果last_num>预设数量阈值,则根据读出的最近一次码率调整前后的数据包以及相应数量进行码率调整状态更新,对应步骤S324。其中,根据读出的最近一次码率调整前后的数据包以及相应数量进行码率调整状态更新,可参考上述增加码率处理流程中的操作方式,此处不再赘述。
S310、如果last_num<=0,说明码率减少之后数据池没有接收到服务器发送的数据包,进一步判断时间是否足够(time_out),对应步骤S325。
S391、如果时间足够了(time_out==true),则表示网络堵塞,此时应该进一步降低码率,所以status变为KDecreasingNotWithServer(不根据服务器发送的数据减少码率(例如直接降码率降到目前码率的一半)),对应的loop=true,对应步骤S325。loop=true表示继续循环、重新进入执行步骤S3,即立即判断status,由于status==KDecreasingNotWithServer,则直接进入减少码率处理流程,此时不用暂停等待满足预设条件(例如,等待1秒)后下一次再启动/调用这个算法。
S392、如果last_num<=预设数量阈值,或如果时间并未足够(time_out==false),则置loop=false(分别对应步骤S324、步骤S325)。即表示退出此次算法,等待满足预设条件(例如,等待1秒)后下一次再启动/调用这个算法依次执行步骤S2和步骤S3。
需要说明的是,上述last_num的预设数量阈值和time_out的取值仅为举例,可以根据实际的网络情况作出改变,本申请对此不作限定。
本申请所述数据传输速率控制方法,服务器和客户端之间传输的统计信息数据少,能准确、迅速的计算出当前带宽,并及时调整客户端向服务器端发送数据的码率,很好的实现拥塞控制。
基于同一发明构思,本申请还提供了一种数据传输速率控制系统。
请参阅图4,本申请数据传输速率控制系统的架构示意图。本申请数据传输速率控制系统包括:接收存储模块41、读取记录模块42、码率调整控制模块43、增加码率处理模块44以及减少码率处理模块45。
所述接收存储模块41,用于接收外部端49发送至本地端40的数据包并存储。所述数据包包括以下至少其中之一:距离上一次所述外部端向所述本地端发送数据的时间间隔time_ms;在所述时间间隔内,所述外部端接收到所述本地端发送的数据的数据字节数sent_size;在所述时间间隔内,总共发生的丢包率lost。所述接收存储模块41在接收并缓存服务器发送来的数据包的时候,进一步给数据包打印添加一个时间戳received_ts,供后续使用。
所述读取记录模块42,用于分别读取最近一次码率调整前后的预设时间内所述接收存储模块接收到的数据包,并记录读出的数据包的相应数量。具体读取、记录方式参考上述数据传输速率控制方法中步骤S2的描述,此处不再赘述。
所述码率调整控制模块43,用于判断当前码率调整状态,根据第一判断结果调用所述增加码率处理模块44,或调用所述减少码率处理模块45。
所述增加码率处理模块44,用于进行增加码率处理;其中,所述增加码率处理包括根据读出的数据包和相应数量进行码率调整状态更新。具体增加码率处理方式参考上述数据传输速率控制方法中步骤S3的描述,此处不再赘述。
所述减少码率处理模块45,用于进行减少码率处理;其中,所述减少码率处理包括根据读出的数据包和相应数量进行码率调整状态更新。具体减少码率处理方式参考上述数据传输速率控制方法中步骤S3的描述,此处不再赘述。
进一步的实施例中,所述增加/减少码率处理中进一步包括判断所述增加/减少码率处理的循环状态,根据第二判断结果继续重新调用所述码率调整控制模块43,或停止执行所述增加/减少码率处理,并满足预设条件后依次重新调用所述读取记录模块42以及所述码率调整控制模块43。
进一步的实施例中,所述接收存储模块41、读取记录模块42、码率调整控制模块43、增加码率处理模块44以及减少码率处理模块45均设置于本地端40。
本申请所述数据传输速率控制系统,结构简单,服务器和客户端之间传输的统计信息数据少,能准确、迅速的计算出当前带宽,并及时调整客户端向服务器端发送数据的码率,很好的实现拥塞控制。
基于同一发明构思,本申请还提供了一种用于数据传输速率控制的用户设备。
请参阅图5,本申请用于数据传输速率控制的用户设备的架构示意图。所述用户设备50包括:处理器51;存储器52,用于存储一个或多个计算机可执行指令;当所述一个或多个计算机可执行指令被所述处理器51执行时,使得如本申请前述的方法被执行。
基于同一发明构思,本申请还提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机可执行指令,当所述计算机可执行指令被执行时,使得如本申请前述的方法被执行。
本申请实施例所述的方法,可以使用相关领域中的技术人员所知的计算机系统或架构来实现。计算机系统,例如PDA、智能手机,掌上型电脑、服务器、客户端或任何其他类型的专用或通用计算设备,因可以适用或者适合于特定应用或者环境而可以被使用。计算机系统可以包括一个或多个处理器,其可以使用诸如微处理器、微控制器或其他控制处理模块的通用或专用处理引擎来实现的。
计算机系统还可以包括用于存储要由处理器执行的信息和指令的主存储器,例如随机存取存储器(random access memory,简称RAM)或其他动态存储器。这种主存储器也可以用于存储由处理器待执行的指令执行期间的暂时变量或其他中间信息。计算机系统同样可以包括用于处理器的存储静态信息和处理器指令的只读存储器(read only memory,简称ROM)或其他静态存储设备。
计算机系统还可以包括信息存储系统,例如,其可以包括介质驱动器和可移动存储接口。介质驱动器可以包括驱动器或其他机制以支持固定或可移动存储介质,诸如硬盘驱动器、软盘驱动器、磁带驱动器、光盘驱动器、光盘(compact disc,简称CD)、数字视频驱动器(digital video drive,简称DVD)、读或写驱动器(read or write drive,简称R或RW)或其他可移动或固定介质驱动器。例如,存储介质可以包括例如硬盘、软盘、磁带、光盘、CD或DVD或由介质驱动器读和写的其他固定或可移动介质。存储介质可以包括具有存储在其中的特定计算机软件或数据的计算机可读存储介质。
在可选实施例中,信息存储系统可以包括用于允许将计算机可执行指令或其他指令或数据加载到计算机系统中的其他类似组件。例如,这些组件可以包括可移动存储单元与接口,例如,程序卡盒与卡盒接口、可移动存储器(例如,闪存或者其他可移动存储器模块)与存储器插槽、以及允许软件和数据自可移动存储单元传输到计算机系统的其他可移动存储单元与接口。
所述计算机系统也可以包括通信接口。这样的通信接口可以被使用以允许软件和数据在计算机系统和外部设备之间传输。本实施例中,通信接口可以包括调制解调器、网络接口(例如,以太网或其它NIC卡)、通信端口(例如,通用串行总线(universal serial bus,简称USB)端口)、 PCMCIA槽与卡等。通过通信接口传输的软件和数据是以信号的形式进行传输,可以是电子的,电磁的,光学的或其他能够被通信接口介质接收的信号。
在本文中,术语“计算机可执行指令”、“计算机可读介质”等可以通常用于指的有形介质,例如,存储器、存储设备或存储单元。这些形式和其他形式的计算机可读介质可以存储一个或多个指令,以由包括计算机系统的处理器使用,以使处理器执行指定操作。这些指令,通常称为“计算机程序代码”(其可以以计算机程序的形式或其他组合来组合),在被执行时,使得计算机系统执行本申请实施例的功能。注意的是,该代码可以直接使得处理器执行特定操作,被编译成这样做,和/或与其他软件、硬件和/或固件(例如,执行标准功能的库)组合以这样做。
所述非暂时性计算机可读介质可以包括由硬盘,紧凑型光盘只读储存器(CD-ROM),光存储设备,磁存储设备,只读存储器(Read Only Memory,简称ROM),可编程只读存储器(Programmable Read Only Memory,简称PROM),可擦除可编程只读存储器(ErasableProgrammable Read Only Memory,简称EPROM),电可擦除可编程只读存储器(Electrically Erasable Programmable Read Only Memory,简称EEPROM)和闪存组成的组中的至少一个。
在使用软件实现元素的实施例中,使用例如可移动存储驱动器,软件可以被存储在计算机可读介质中,以及被加载到计算机系统中。当由计算机系统中的处理器执行时,控制模块(在本示例中,为软件指令或可执行计算机程序代码)使得处理器执行如本文所述的本申请的功能。
此外,本申请构思可以应用于用于执行网络元件内的信号处理功能的任何电路。进一步设想,例如,半导体制造商可以在独立设备的设计中使用本申请的构思,例如数字信号处理器(digital signal processor,简称DSP)或专用集成电路(application-specificintegrated circuit,简称ASIC)的微控制器和/或任何其他子系统元件。
可以理解的是,为了清楚的目的,上面已经参照单个处理逻辑描述了本申请的实施例。然而,本申请构思同样可以通过多个不同的功能单元和处理器来实现,以提供信号处理功能。因此,对特定功能单元的引用仅被视为对用于提供所描述功能的合适手段的引用,而不是指示严格的逻辑或物理结构或组织。
本申请的各方面可以以包括硬件,软件,固件及其任何组合的任何适当形式来实现。可选地,本申请可以至少部分地作为在一个或多个数据处理器和/或数字信号处理器或诸如FPGA器件的可配置模块组件上运行的计算机软件来实现。因此,本申请的实施例的元件和组件可以以任何合适的方式在物理上,功能上和逻辑上实现。实际上,功能可以以单个单元,多个单元或作为其他功能单元的一部分来实现。
尽管已经示出和描述了本申请的实施例,本领域的普通技术人员可以理解:在不脱离本申请的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型,本申请的范围由权利要求及其等同物限定。

Claims (20)

1.一种数据传输速率控制方法,其特征在于,所述方法包括如下步骤:
S1、接收外部端发送至本地端的数据包并存储,其中,所述数据包中包括距离上一次所述外部端向所述本地端发送数据包的时间间隔内总共发生的丢包率;
S2、分别读取最近一次码率调整前后的预设时间内所述本地端中接收到的数据包,并记录读出的数据包的相应数量以及为读取的每一数据包添加对应的心跳值,所述心跳值是与接收数据包时打印的时间戳对应的;以及
S3、判断当前码率调整状态,根据第一判断结果进入增加/减少码率处理流程;其中,所述增加/减少码率处理流程包括根据读出的每一数据包中的丢包率和/或每一数据包的心跳值,以及读出的数据包的相应数量进行码率调整状态更新。
2.根据权利要求1所述的方法,其特征在于,所述步骤S3进一步包括:判断所述增加/减少码率处理流程的循环状态,根据第二判断结果继续重新进入执行步骤S3,或停止执行所述增加/减少码率处理流程,并满足预设条件后返回依次执行步骤S2和步骤S3。
3.根据权利要求1所述的方法,其特征在于,所述数据包还包括以下至少其中之一:距离上一次所述外部端向所述本地端发送数据包的时间间隔;在所述时间间隔内,所述外部端接收到所述本地端发送的数据的数据字节数。
4.根据权利要求1所述的方法,其特征在于,所述步骤S2进一步包括:
S21、读取最近一次码率调整之前预设时间内所述本地端中接收的数据包,并记录读出的数据包的第一数量;
S22、读取最近一次码率调整之后预设时间内所述本地端中接收的数据包,并记录读出的数据包的第二数量;以及
S23、根据接收数据包时打印的时间戳对应的心跳值,为所述步骤S21、步骤S22、读取的每一数据包添加对应的心跳值。
5.根据权利要求1所述的方法,其特征在于,所述步骤S3进一步包括:预设所述码率调整状态的初始状态为码率增加之中。
6.根据权利要求1所述的方法,其特征在于,所述步骤S3进一步包括:若当前码率调整状态为码率增加之中或码率增加之后时,进入增加码率处理流程,否则进入减少码率处理流程。
7.根据权利要求4所述的方法,其特征在于,所述步骤S3中所述的增加码率处理流程的步骤包括:
S311、判断所述码率调整状态是否为码率增加之中,若是则直接增加码率、更新所述码率调整状态为码率增加之后、更新循环状态为停止循环,停止执行增加码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3,否则执行步骤S312;
S312、判断所述第二数量是否大于0,若是则执行步骤S313,否则执行步骤S314;
S313、判断所述第二数量是否大于一预设数量阈值,若是则根据读出的数据包以及相应数量进行码率调整状态更新,否则更新循环状态为停止循环,停止执行增加码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3;以及
S314、判断当前时间距离最近一次码率调整的时间是否大于预设时间阈值,若是则更新所述码率调整状态为不根据外部端发送的数据包减少码率,并更新循环状态为继续循环,继续重新进入执行步骤S3,否则更新循环状态为停止循环,停止执行增加码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3。
8.根据权利要求7所述的方法,其特征在于,所述步骤S311中所述的直接增加码率的步骤中进一步包括:将目标码率调整为当前码率与当前索引对应的增加码率表中的码率之和,之后所述当前索引自增。
9.根据权利要求8所述的方法,其特征在于,所述的当前索引自增的步骤进一步包括:对所述当前索引自增后做边界判断,若所述当前索引自增后超过预设索引的最大值边界,则设定所述当前索引为所述最大值。
10.根据权利要求7所述的方法,其特征在于,所述方法进一步包括:在所述步骤S312中判定所述第二数量大于0之后进一步执行以下步骤:判断所述步骤S22读取的数据包是否有突发的变化,若没有突发的变化则执行步骤S313,若有突发的变化,则更新所述码率调整状态为根据外部端发送的数据包减少码率,并更新循环状态为继续循环,继续重新进入执行步骤S3。
11.根据权利要求4所述的方法,其特征在于,所述步骤S3中所述的减少码率处理流程的步骤包括:
S321、判断所述码率调整状态是否为根据外部端发送的数据包减少码率,若是则根据外部端发送的数据包计算目标码率、更新所述码率调整状态为码率减少之后、更新循环状态为停止循环,停止执行减少码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3,否则执行步骤S322;
S322、判断所述码率调整状态是否为不根据外部端发送的数据包减少码率,若是则减少当前码率、更新所述码率调整状态为码率减少之后、更新循环状态为停止循环,停止执行减少码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3,否则执行步骤S323;
S323、判断所述第二数量是否大于0,若是则执行步骤S324,否则执行步骤S325;
S324、判断所述第二数量是否大于一预设数量阈值,若是则根据读出的数据包以及相应数量进行码率调整状态更新,否则更新循环状态为停止循环,停止执行减少码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3;以及
S325、判断当前距离最近一次码率调整的时间是否大于预设时间阈值,若是则更新所述码率调整状态为不根据外部端发送的数据包减少码率,并更新循环状态为继续循环,继续重新进入执行步骤S3,否则更新循环状态为停止循环,停止执行减少码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3。
12.根据权利要求11所述的方法,其特征在于,所述步骤S321中所述的根据外部端发送的数据包计算目标码率的步骤中,进一步包括:
根据所述步骤S22读取的数据包中每一数据包中的数据字节数、时间间隔,以及所述第二数量,计算平均数据字节数以及平均时间间隔;
根据所述平均数据字节数以及所述平均时间间隔计算获取目标码率。
13.根据权利要求11所述的方法,其特征在于,所述方法进一步包括:在所述步骤S323中判定所述第二数量大于0之后进一步执行以下步骤:判断所述步骤S22读取的数据包是否有突发的变化,若没有突发的变化则执行步骤S324,若有突发的变化,则更新所述码率调整状态为根据外部端发送的数据包减少码率,并更新循环状态为继续循环,继续重新进入执行步骤S3。
14.根据权利要求10或13所述的方法,其特征在于,所述的判断所述步骤S22读取的数据包是否有突发的变化的判断机制为:根据所述步骤S22读取的数据包中每一数据包中的丢包率,以及所述第二数量,计算平均丢包率,若所述平均丢包率小于预设丢包阈值则判定没有突发的变化,否则判定有突发的变化;和/或根据所述步骤S22读取的数据包中每一数据包的心跳值,以及所述第二数量,计算平均心跳值,若所述平均心跳值小于预设心跳阈值则判定没有突发的变化,否则判定有突发的变化。
15.根据权利要求4、7或11中任一项所述的方法,其特征在于,所述的根据读出的数据包以及相应数量进行码率调整状态更新的步骤进一步包括:
根据所述步骤S21读取的数据包以及记录的第一数量,计算最近一次码率调整之前的第一网络分数;
根据所述步骤S22读取的数据包以及记录的第二数量,计算最近一次码率调整之后的第二网络分数;以及
根据所述第一网络分数与所述第二网络分数,更新所述码率调整状态。
16.根据权利要求15所述的方法,其特征在于,
所述第一网络分数的计算方法为:根据所述步骤S21读取的数据包中每一数据包中的丢包率和心跳值,以及所述第一数量,计算平均丢包率和平均心跳值,根据计算结果获取所述第一网络分数;
所述第二网络分数的计算方法为:根据所述步骤S22读取的数据包中每一数据包中的丢包率和心跳值,以及所述第二数量,计算平均丢包率和平均心跳值,根据计算结果获取所述第二网络分数。
17.根据权利要求15所述的方法,其特征在于,所述的根据所述第一网络分数与所述第二网络分数,更新所述码率调整状态的步骤进一步包括:
对所述第一网络分数与所述第二网络分数进行运算,获取运算结果执行以下步骤的至少其中之一:
增加码率表的当前索引自增,更新所述码率调整状态为码率增加之中,并更新循环状态为继续循环,继续重新进入执行步骤S3;
增加码率表的当前索引置0,更新所述码率调整状态为码率增加之中,并更新循环状态为继续循环,继续重新进入执行步骤S3;
降低当前码率后将增加码率表的当前索引置0,更新所述码率调整状态为码率增加之中,并更新循环状态为继续循环,继续重新进入执行步骤S3;
更新所述码率调整状态为码率增加之后,更新循环状态为停止循环,停止执行增加/减少码率处理流程并满足预设条件后返回依次执行步骤S2和步骤S3;
更新所述码率调整状态为根据外部端发送的数据包减少码率、并更新循环状态为继续循环,继续重新进入执行步骤S3;以及
报错或退出。
18.一种数据传输速率控制系统,其特征在于,所述系统包括:
接收存储模块,用于接收外部端发送至本地端的数据包并存储,其中,所述数据包中包括距离上一次所述外部端向所述本地端发送数据包的时间间隔内总共发生的丢包率;
读取记录模块,用于分别读取最近一次码率调整前后的预设时间内所述接收存储模块接收到的数据包,并记录读出的数据包的相应数量以及为读取的每一数据包添加对应的心跳值,所述心跳值是与接收数据包时打印的时间戳对应的;
码率调整控制模块,用于判断当前码率调整状态,根据第一判断结果调用增加码率处理模块或调用减少码率处理模块;
所述增加码率处理模块用于进行增加码率处理,所述减少码率处理模块用于进行减少码率处理;其中,所述增加码率处理和所述减少码率处理包括根据所述读取记录模块读取的每一数据包中的丢包率和/或每一数据包的心跳值,以及读出的数据包的相应数量进行码率调整状态更新。
19.一种用于数据传输速率控制的用户设备,其特征在于,所述用户设备包括:
处理器;以及
存储器,用于存储一个或多个计算机可执行指令;
其中,当所述计算机可执行指令在被所述处理器执行时,使得如权利要求1至17中任一项所述方法被执行。
20.一种计算机可读介质,其特征在于,所述计算机可读介质存储有计算机可执行指令,当所述计算机可执行指令被处理器执行时,使得如权利要求1至17中任一项所述方法被执行。
CN202010278035.7A 2020-04-10 2020-04-10 数据传输速率控制方法、系统和用户设备 Active CN111193673B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202010278035.7A CN111193673B (zh) 2020-04-10 2020-04-10 数据传输速率控制方法、系统和用户设备
EP21784834.0A EP4135262A4 (en) 2020-04-10 2021-02-08 METHOD AND SYSTEM FOR CONTROLLING DATA TRANSFER RATE AND USER DEVICE
PCT/CN2021/076003 WO2021203829A1 (zh) 2020-04-10 2021-02-08 数据传输速率控制方法、系统和用户设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010278035.7A CN111193673B (zh) 2020-04-10 2020-04-10 数据传输速率控制方法、系统和用户设备

Publications (2)

Publication Number Publication Date
CN111193673A CN111193673A (zh) 2020-05-22
CN111193673B true CN111193673B (zh) 2020-08-25

Family

ID=70710295

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010278035.7A Active CN111193673B (zh) 2020-04-10 2020-04-10 数据传输速率控制方法、系统和用户设备

Country Status (3)

Country Link
EP (1) EP4135262A4 (zh)
CN (1) CN111193673B (zh)
WO (1) WO2021203829A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111193673B (zh) * 2020-04-10 2020-08-25 亮风台(上海)信息科技有限公司 数据传输速率控制方法、系统和用户设备
CN112311690B (zh) * 2020-09-25 2022-12-06 福建星网智慧科技有限公司 一种基于ai的拥塞控制方法、装置、设备和介质
CN113890786A (zh) * 2021-11-09 2022-01-04 华科电子股份有限公司 应用于在线检测设备现场总线管理LonWorks通信方法和系统
CN116132717A (zh) * 2021-11-12 2023-05-16 中兴通讯股份有限公司 入向码流码率获取方法、收流处理方法、电子设备、介质
CN114390320B (zh) * 2022-02-18 2024-02-13 百果园技术(新加坡)有限公司 数据编码码率自适应调节方法、装置、设备和存储介质
CN117579136B (zh) * 2024-01-17 2024-04-02 南京控维通信科技有限公司 Tdma中网控系统对反向突发的aupc及acm控制方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101035365A (zh) * 2007-04-03 2007-09-12 中国科学院计算技术研究所 多种无线网络融合环境中的多媒体会话服务质量管理方法
CN102204182A (zh) * 2010-12-29 2011-09-28 华为技术有限公司 一种数据传输的拥塞控制方法及装置
CN103004154A (zh) * 2011-06-16 2013-03-27 松下电器产业株式会社 发送装置、发送方法、集成电路及其程序
US9641578B2 (en) * 2015-04-02 2017-05-02 Arris Enterprises, Inc. Minimizing unicast bandwidth in an adaptive bit rate system
CN107438031A (zh) * 2017-08-07 2017-12-05 成都三零凯天通信实业有限公司 多信道自适应网络带宽的音视频流传输控制方法及系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4000895B2 (ja) * 2002-04-23 2007-10-31 日本電気株式会社 リアルタイム通信のためのビットレート制御方法および装置
US20140181266A1 (en) * 2011-09-29 2014-06-26 Avvasi Inc. System, streaming media optimizer and methods for use therewith
CN104618258B (zh) * 2015-02-05 2017-12-01 成都金本华科技股份有限公司 一种数据传输速率的控制方法
CN105490772B (zh) * 2015-11-25 2019-06-28 中国航空工业集团公司沈阳飞机设计研究所 一种数据传输速率控制方法
CN107342848B (zh) * 2017-08-24 2020-05-01 杭州联吉技术有限公司 一种自适应码流传输方法、装置及设备
CN111193673B (zh) * 2020-04-10 2020-08-25 亮风台(上海)信息科技有限公司 数据传输速率控制方法、系统和用户设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101035365A (zh) * 2007-04-03 2007-09-12 中国科学院计算技术研究所 多种无线网络融合环境中的多媒体会话服务质量管理方法
CN102204182A (zh) * 2010-12-29 2011-09-28 华为技术有限公司 一种数据传输的拥塞控制方法及装置
CN103004154A (zh) * 2011-06-16 2013-03-27 松下电器产业株式会社 发送装置、发送方法、集成电路及其程序
US9641578B2 (en) * 2015-04-02 2017-05-02 Arris Enterprises, Inc. Minimizing unicast bandwidth in an adaptive bit rate system
CN107438031A (zh) * 2017-08-07 2017-12-05 成都三零凯天通信实业有限公司 多信道自适应网络带宽的音视频流传输控制方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"基于状态机的视频码率自适应算法";黄胜 等;《计算机应用》;20180710;全文 *

Also Published As

Publication number Publication date
EP4135262A4 (en) 2024-06-05
CN111193673A (zh) 2020-05-22
WO2021203829A1 (zh) 2021-10-14
EP4135262A1 (en) 2023-02-15

Similar Documents

Publication Publication Date Title
CN111193673B (zh) 数据传输速率控制方法、系统和用户设备
US10757033B2 (en) Traffic control method, traffic control apparatus and server
TWI543568B (zh) 用於分封交換網路的系統及其方法、在分封交換網路中用於接收資料包的交換機中的方法
CN107948103B (zh) 一种基于预测的交换机pfc控制方法及控制系统
CN106331717B (zh) 视频码率自适应调整方法及发送端设备
US20080225750A1 (en) Method of transmitting data in a communication system
CN109644162B (zh) 媒体缓冲
US20220094640A1 (en) Congestion control method and apparatus, communications network, and computer storage medium
CN113301392B (zh) 码率确定方法、装置、设备及存储介质
EP4175232A1 (en) Congestion control method and device
US11695629B2 (en) Method and apparatus for configuring a network parameter
CN111726301B (zh) 一种实时视频中保证视频质量的拥塞控制方法及系统
CN118250224B (zh) 拥塞控制方法、装置、系统、设备及介质
WO2021083160A1 (zh) 数据传输的方法和装置
US10382155B2 (en) Data processing
CN112491573A (zh) 一种网络参数配置方法及装置
CA2868712A1 (en) Communication apparatus, control apparatus, communication system, communication method, method for controlling communication apparatus, and program
CN115174478A (zh) 一种网络拥塞控制方法及相关装置
US10313276B2 (en) Managing a jitter buffer size
US7500012B2 (en) Method for controlling dataflow to a central system from distributed systems
US20240340331A1 (en) Audio playback control method, device and electronic equipment
CN113825042B (zh) 一种数据接入方法、装置、芯片和计算机存储介质
CN115776684A (zh) 一种数据传输方法、装置、设备、存储介质及程序产品
JP2015026929A (ja) 信号バッファ蓄積信号振分装置

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
CP02 Change in the address of a patent holder
CP02 Change in the address of a patent holder

Address after: 201210 7th Floor, No. 1, Lane 5005, Shenjiang Road, China (Shanghai) Pilot Free Trade Zone, Pudong New Area, Shanghai

Patentee after: HISCENE INFORMATION TECHNOLOGY Co.,Ltd.

Address before: Room 501 / 503-505, 570 shengxia Road, China (Shanghai) pilot Free Trade Zone, Pudong New Area, Shanghai, 201203

Patentee before: HISCENE INFORMATION TECHNOLOGY Co.,Ltd.