CN110035251B - 基于视频会议服务端实现码率控制处理的方法 - Google Patents

基于视频会议服务端实现码率控制处理的方法 Download PDF

Info

Publication number
CN110035251B
CN110035251B CN201910314101.9A CN201910314101A CN110035251B CN 110035251 B CN110035251 B CN 110035251B CN 201910314101 A CN201910314101 A CN 201910314101A CN 110035251 B CN110035251 B CN 110035251B
Authority
CN
China
Prior art keywords
video
packet loss
uplink
bandwidth
downlink
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
CN201910314101.9A
Other languages
English (en)
Other versions
CN110035251A (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.)
Diankeyun (Beijing) Technology Co.,Ltd.
Original Assignee
Diankeyun Beijing 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 Diankeyun Beijing Technology Co ltd filed Critical Diankeyun Beijing Technology Co ltd
Priority to CN201910314101.9A priority Critical patent/CN110035251B/zh
Publication of CN110035251A publication Critical patent/CN110035251A/zh
Application granted granted Critical
Publication of CN110035251B publication Critical patent/CN110035251B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明涉及一种基于视频会议服务端实现码率控制处理的方法，包括以下步骤：(1)分别计算上下行的带宽；(2)判断是否存在转码器，如果是，则设置为转码器的目标码率，并返回至客户端；否则，继续步骤(3)；(3)将结果返回至上行，利用带宽调整策略来调整带宽。采用了本发明的基于视频会议服务端实现码率控制处理的方法，在网络带宽不足的情况下，能够迅速降低视频的质量或者取消视频，仅保留音频；在网络带宽仅足够音频传输时，不会反复尝试启动视频。在算法层面保证音频包的竞争性，音频丢包不会和视频丢包做同等处理。

Description

基于视频会议服务端实现码率控制处理的方法
技术领域
本发明涉及音视频编解码领域，尤其涉及码率控制领域，具体是指一种基于视频会议服务端实现码率控制处理的方法。
背景技术
随着Webrtc的发展，越来越多的公司开始利用Webrtc搭建视频会议系统。但是Webrtc是提供点到点的视频会议，本身不支持多人，所以在Webrtc之上，视频会议系统需要构建自己的媒体控制单元(MCU)或者单路转发单元(SFU)。服务端同时要接受和分发多路音视频码流，由于网络上下行带宽的不匹配，以及网络本身的波动。MCU端一个重要的功能就是对音视频码率的控制。
码率的控制分成两个部分，一部分是对现有带宽的侦测和估计，另一部分是对音视频码率的控制。SFU是一个纯转发的服务，无法直接对码率进行控制，更多的是做带宽的侦测。MCU作为一个比较复杂，功能比较完善的服务端，具备转码混流的功能，可以对下行的码率做比较方便的控制。
现有的音视频编码器都会提供码率控制的接口，可以在内部通过各种手段对输出码率进行有效的控制。对于MCU来说，最重要的事情是对现有的带宽做比较精确的估计，同时，由于网络总是存在不可预测的波动，所以，MCU也需要对网络波动做出一定程度的预判，这样可以有效减少码率的波动。
Webrtc在56版本以前，利用一种叫GCC的算法来做带宽的估计，在56版本之后，利用一种叫Trendline的算法来做带宽估计。GCC对于带宽的估计太过延迟，实际带宽的波动可能很大，但是GCC不够灵敏，经常会出现远高于或者远低于实际带宽的情况。Trendline又过于灵敏，特别是针对带宽从高到低，可以迅速捕捉到带宽的下降，但是对于带宽的上升，计算出的带宽回复过慢。带来的效果是，用户往往带宽足够，但是一直徘徊在低质量的视频流之中。
视频会议不止提供视频流，更重要的是提供音频流数据。当带宽不能够同时支持音视频流的时候，我们需要把视频流停掉，尽量保持音频流的数据。所以，对真实带宽的估计显得尤为重要。GCC和trendline都是基于视频流做带宽估计和检测，对于音频数据，是不考虑的。这使得这个算法的缺陷非常明显。当视频流数据和音频流数据在同时竞争带宽时，GCC和Trendline忽视了音频流数据的带宽，而实际上，对用户体验来说，音频数据是显而易见更重要的。
发明内容
本发明的目的是克服了上述现有技术的缺点，提供了一种满足低延时、灵敏度高、准确性高的基于视频会议服务端实现码率控制处理的方法。
为了实现上述目的，本发明的基于视频会议服务端实现码率控制处理的方法如下：
该基于视频会议服务端实现码率控制处理的方法，其主要特点是，所述的方法包括以下步骤：
(1)分别计算上下行的带宽；
(2)判断是否存在转码器，如果是，则设置为转码器的目标码率，并返回至客户端；否则，继续步骤(3)；
(3)将结果返回至上行，利用带宽调整策略来调整带宽。
较佳地，所述的步骤(1)具体包括以下步骤：
(1.1)根据RTCP的报文分别获取上下行的音频丢包率和视频丢包率；
(1.2)分别计算上下行的丢包权重，并获取过去一段时间内中出现的最大实际发送码率；
(1.3)分别计算上下行的网络状态；
(1.4)分别计算上下行的估计带宽。
较佳地，所述的步骤(1.2)中计算丢包权重，具体为：
根据以下公式计算丢包权重：
fweight＝(1-faudio)*(1-fvideo)；
其中，faudio为音频丢包率，fvideo为视频丢包率。
较佳地，所述的步骤(1.3)中计算网络状态，具体为：
根据以下公式计算网络状态：
Figure BDA0002032506100000021
其中，fweight为丢包权重，Snet_state为网络状态，1表示网络状态上升，0表示网络状态不变，-1表示网络状态下降。
较佳地，所述的步骤(1.4)中计算估计带宽，具体为：
根据以下公式计算估计带宽Bestimate：
Figure BDA0002032506100000031
其中，Breal_bitrate_max为最大实际发送码率，fweight为丢包权重，Bestimate为估计带宽，S为网络状态。
较佳地，所述的步骤(3)具体包括以下步骤：
(3.1)对上下行分别计数，判断是否估计带宽高于阈值且音频丢包率低于高阈值，如果是，则计数值减少；否则，计数值增加；
(3.2)判断计数值是否变化至预设数值，如果是，则通知客户端停止发送上行的视频，并在MCU层面停止发送下行的视频，继续步骤(3.3)；否则，继续步骤(3.1)；
(3.3)继续计数音频丢包率，判断是否在预设时间内音频丢包率小于预设值，如果是，重新发送视频，继续步骤(3.1)，直至视频会议结束；否则，继续步骤(3.3)。
较佳地，所述的步骤(3.3)具体包括以下步骤：
(3.3.1)继续计数音频丢包率，判断是否在预设时间内音频丢包率小于预设值，如果是，重新发送视频，继续步骤(3.3.2)；否则，继续步骤(3.3)；
(3.3.2)判断重新发送视频的次数是否大于1，如果是，则继续步骤(3.3.3)；否则，继续步骤(3.1)；
(3.3.3)判断是否重新发送视频导致音频丢包率上升，如果是，则根据计算的启动视频的时间间隔增加发送的时间间隔，继续步骤(3.1)，直至视频会议结束；否则，继续步骤(3.1)，直至视频会议结束。
较佳地，所述的步骤(1.3)中计算启动视频的时间间隔，具体为：
根据以下公式计算启动视频的时间间隔：
Tinterval＝Ttime_slice*Cdisable_times。
通常，Ttime_slice为固定的常量，通常取10秒，Cdisable_times为视频被取消的次数。
采用了本发明的基于视频会议服务端实现码率控制处理的方法，在网络带宽不足的情况下，能够迅速降低视频的质量或者取消视频，仅保留音频；在网络带宽仅足够音频传输时，不会反复尝试启动视频。在算法层面保证音频包的竞争性，音频丢包不会和视频丢包做同等处理。
附图说明
图1为本发明的基于视频会议服务端实现码率控制处理的方法的流程图。
具体实施方式
为了能够更清楚地描述本发明的技术内容，下面结合具体实施例来进行进一步的描述。
本发明的该基于视频会议服务端实现码率控制处理的方法，其中包括以下步骤：
(1)分别计算上下行的带宽；
(1.1)根据RTCP的报文分别获取上下行的音频丢包率和视频丢包率；
(1.2)分别计算上下行的丢包权重，并获取过去一段时间内中出现的最大实际发送码率；
(1.3)分别计算上下行的网络状态；
(1.4)分别计算上下行的估计带宽；
(2)判断是否存在转码器，如果是，则设置为转码器的目标码率，并返回至客户端；否则，继续步骤(3)；
(3)将结果返回至上行，利用带宽调整策略来调整带宽；
(3.1)对上下行分别计数，判断是否估计带宽高于阈值且音频丢包率低于高阈值，如果是，则计数值减少；否则，计数值增加；
(3.2)判断计数值是否变化至预设数值，如果是，则通知客户端停止发送上行的视频，并在MCU层面停止发送下行的视频，继续步骤(3.3)；否则，继续步骤(3.1)；
(3.3)继续计数音频丢包率，判断是否在预设时间内音频丢包率小于预设值，如果是，重新发送视频，继续步骤(3.1)，直至视频会议结束；否则，继续步骤(3.3)；
(3.3.1)继续计数音频丢包率，判断是否在预设时间内音频丢包率小于预设值，如果是，重新发送视频，继续步骤(3.3.2)；否则，继续步骤(3.3)；
(3.3.2)判断重新发送视频的次数是否大于1，如果是，则继续步骤(3.3.3)；否则，继续步骤(3.1)；
(3.3.3)判断是否重新发送视频导致音频丢包率上升，如果是，则根据计算的启动视频的时间间隔增加发送的时间间隔，继续步骤(3.1)，直至视频会议结束；否则，继续步骤(3.1)，直至视频会议结束。
作为本发明的优选实施方式，所述的步骤(1.2)中计算丢包权重，具体为：
根据以下公式计算丢包权重：
fweight＝(1-faudio)*(1-fvideo)；
其中，faudio为音频丢包率，fvideo为视频丢包率。
作为本发明的优选实施方式，所述的步骤(1.3)中计算网络状态，具体为：
根据以下公式计算网络状态：
Figure BDA0002032506100000051
其中，fweight为丢包权重，1表示网络状态上升，0表示网络状态不变，-1表示网络状态下降。
作为本发明的优选实施方式，所述的步骤(1.4)中计算估计带宽，具体为：
根据以下公式计算估计带宽：
Figure BDA0002032506100000052
其中，Breal_bitrate_max为最大实际发送码率，fweight为丢包权重，Bestimate为估计带宽，S为网络状态。
作为本发明的优选实施方式，所述的步骤(1.3)中计算启动视频的时间间隔，具体为：
根据以下公式计算启动视频的时间间隔：
Tinterval＝Ttime_slice*Cdisable_times。
通常，Ttime_slice为固定的常量，通常取10秒，Cdisable_times为视频被取消的次数。
本发明的具体实施方式中，使用GCC或者Trendline的带宽估计算法无法满足服务端的需求。针对服务端，开发了新方法，综合音视频对带宽做出估计，并且利用估计的带宽来控制码率。本发明在mcu中实现相关算法，并利用Webrtc实现视频会议的客户端，和MCU相连。
利用以下几种方式对带宽分别做估计
1、根据丢包率估计下行带宽
根据RTCP的报文获取下行音频丢包率faudio_downlink和下行的视频丢包率fvideo_downlink，计算丢包权重fweight＝(1-faudio_downlink)*(1-fvideo_downlink).获取过去一段时间内中出现的最大实际发送码率Breal_bitrate_max。
计算网络状态：
Figure BDA0002032506100000061
1表示网络状态上升，0表示网络状态不变，-1表示网络状态下降。
计算估计带宽公式如下：
Figure BDA0002032506100000062
计算得出的带宽和来自REMB中的估计带宽做比较，取小值，设置到解码器中，或者设置到上行链路，做进一步对比。
2、计算上行带宽，采取同样的算法，计算出上行的带宽，并且和下行的带宽做比较，如果存在转码器，则通过REMB把计算得出的上行带宽返回给客户端，如果不存在解码器，则和下行带宽做比较，返回小值
3、对video的处理：
对上下行分别计数，估计带宽低于阈值的时候，或者音频丢包率高于高阈值的时候，计数增加，带宽增加到设定的高阈值之上，并且音频丢包率低于低阈值的时候，计数减少。当计数增加到一定程度，对于上行，通知客户端停止video发送，下行则在MCU层面停止video发送。上下行是互相独立的。停止video发送之后，会给停止计数加一
Video停止之后，对于audio的丢包率继续计数。如果连续一段时间audio的丢包率都很小，则尝试重新发送视频，尝试的间隔根据统计结果增加。
启动视频时间间隔计算公式如下：
Tinterval＝Ttime_slice*Cdisable_times
如果每次尝试都会导致音频丢包率上升，则尝试的间隔会越来越长，防止出现反复启动video导致体验下降。
整体的流程如图1所示，上下行分别计算带宽，计算的结果，如果存在转码器，则设置到转码器中作为目标码率，否则返回给上行，让上行利用webrtc的带宽调整策略来调整带宽。
本发明所声明的方法，是一种适用于服务端的，并且和现在主流的Webrtc相兼容的码率控制算法。对于网络带宽的估计，目前主流的算法分成两类，第一，基于延迟来估算带宽；第二，基于丢包来估算带宽。实际中经常把两类方法综合起来做带宽估计，区别在于，不论是基于延迟还是基于丢包，所采用的模型和公式不同。
本发明采用的是基于丢包的带宽估计算法，并且提出了自有的丢包模型和估算公式，同时，本发明是考虑音频优先的原则，对视频和音频的丢包统一处理，并赋予不同的权重。本发明并未采用延迟估计算法，但对音视频的丢包做统一处理，得出的结果不会挤占音频带宽。本方法是用在基于webrtc的音视频服务中，服务端无法主动侦测带宽，因此通过数学模型来预测网络状态。
采用了本发明的基于视频会议服务端实现码率控制处理的方法，在网络带宽不足的情况下，能够迅速降低视频的质量或者取消视频，仅保留音频；在网络带宽仅足够音频传输时，不会反复尝试启动视频。在算法层面保证音频包的竞争性，音频丢包不会和视频丢包做同等处理。
在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。

Claims (5)

1.一种基于视频会议服务端实现码率控制处理的方法，其特征在于，所述的方法包括以下步骤：
步骤(1)分别计算上下行的带宽；
步骤(2) 判断是否存在转码器 ，如果是 ，则将计算的结果设置为转码器的目标码率，并返回至客户端 ；否则，继续步骤(3) ；
(3)将上下行的带宽中的小值返回至上行，利用带宽调整策略来调整带宽；
其中，步骤（1）包括以下步骤：
(1.1)根据RTCP的报文获取上下行的音频丢包率和视频丢包率；
(1.2) 分别计算上下行的丢包权重，并获取过去一段时间内中出现的最大实际发送码率；
(1.3)基于上下行丢包权重分别计算上下行的网络状态；
(1.4)基于上下行的网络状态计算上下行的估计带宽；
所述步骤（3）包括以下步骤：
计数步骤：对上下行分别计数，判断是否估计带宽高于阈值且音频丢包率低于高阈值，如果是，则计数值减少；否则，计数值增加；
视频停止步骤：如果所述计数值增加到预设数值，通知客户端停止发送上行的视频，并在MCU层面停止发送下行的视频；
视频重新发送步骤，该步骤包括：
继续计数音频丢包率，如果在预设时间内音频丢包率小于预设值，则重新发送视频；
如果重新发送视频的次数大于1，则判断是否重新发送视频导致音频丢包率上升，如果是，则根据计算的启动视频的时间间隔增加发送的时间间隔；
重复执行计数步骤，直至视频会议结束。
2. 根据权利要求1所述的基于视频会议服务端实现码率控制处理的方法，其特征在于，所述的步骤(1 .2)中计算丢包权重，具体为：
根据以下公式计算丢包权重fweight：
fweight＝(1-faudio)*(1-fvideo) ；
其中，faudio为音频丢包率，fvideo为视频丢包率。
3. 根据权利要求1所述的基于视频会议服务端实现码率控制处理的方法，其特征在于，所述的步骤(1 .3)中计算网络状态，具体为：
根据以下公式计算网络状态：
Figure DEST_PATH_IMAGE002
其中，fweight为丢包权重，Snet_state为网络状态，1表示网络状态上升，0表示网络状态不变，-1表示网络状态下降。
4. 根据权利要求1所述的基于视频会议服务端实现码率控制处理的方法，其特征在于，所述的步骤(1 .4)中计算估计带宽，具体为：
根据以下公式计算估计带宽：
Figure DEST_PATH_IMAGE004
其中，Breal_bitrate_max为最大实际发送码率，fweight为丢包权重，Bestimate为估计带宽，S为网络状态。
5. 根据权利要求1所述的基于视频会议服务端实现码率控制处理的方法，其特征在于， 所述计算的启动视频的时间间隔是根据以下公式计算的：
Tinterval＝Ttime_slice*Cdisable_times；
其中，Ttime_slice为固定的常量，取10秒，Cdisable_times为视频被取消的次数。
CN201910314101.9A 2019-04-18 2019-04-18 基于视频会议服务端实现码率控制处理的方法 Active CN110035251B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910314101.9A CN110035251B (zh) 2019-04-18 2019-04-18 基于视频会议服务端实现码率控制处理的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910314101.9A CN110035251B (zh) 2019-04-18 2019-04-18 基于视频会议服务端实现码率控制处理的方法

Publications (2)

Publication Number Publication Date
CN110035251A CN110035251A (zh) 2019-07-19
CN110035251B true CN110035251B (zh) 2021-04-06

Family

ID=67239125

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910314101.9A Active CN110035251B (zh) 2019-04-18 2019-04-18 基于视频会议服务端实现码率控制处理的方法

Country Status (1)

Country Link
CN (1) CN110035251B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110958415B (zh) * 2019-11-28 2021-06-11 武汉兴图新科电子股份有限公司 基于单平台网络监测动态调整媒体传输的方法
CN113992987B (zh) * 2021-12-27 2022-07-22 北京蔚领时代科技有限公司 一种适用于云游戏场景的智能码率调节系统及方法
CN114640653B (zh) * 2022-03-04 2024-09-27 新讯数字科技(杭州)有限公司 一种视频会议中的流媒体分发系统及方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101436990A (zh) * 2008-12-23 2009-05-20 深圳华为通信技术有限公司 一种自动调整编码速率的方法、接收装置及通信系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1855793A (zh) * 2005-04-19 2006-11-01 华为技术有限公司 一种视音频编码速度的控制方法
CN101662455A (zh) * 2008-08-29 2010-03-03 深圳华为通信技术有限公司 数据传输的方法和装置
CN103260053B (zh) * 2013-04-15 2016-12-28 威盛电子股份有限公司 动态调整多媒体数据码率的系统、媒体播放装置及方法
US20140355410A1 (en) * 2013-06-04 2014-12-04 Tencent Technology (Shenzhen) Company Limited Systems and Methods for Data Transmission
CN107333091A (zh) * 2016-04-28 2017-11-07 中兴通讯股份有限公司 音视频转换方法及装置
CN107438031A (zh) * 2017-08-07 2017-12-05 成都三零凯天通信实业有限公司 多信道自适应网络带宽的音视频流传输控制方法及系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101436990A (zh) * 2008-12-23 2009-05-20 深圳华为通信技术有限公司 一种自动调整编码速率的方法、接收装置及通信系统

Also Published As

Publication number Publication date
CN110035251A (zh) 2019-07-19

Similar Documents

Publication Publication Date Title
CN110035251B (zh) 基于视频会议服务端实现码率控制处理的方法
US11190570B2 (en) Video encoding using starve mode
JP5792272B2 (ja) ネットワークの輻輳に適応するためのシステムと方法
US7962637B2 (en) Dynamic adjustments of video streams
JP6255342B2 (ja) 帯域幅が変化する接続における動的ビットレート適合
US9112947B2 (en) Flow-rate adaptation for a connection of time-varying capacity
US8255559B2 (en) Data streaming through time-varying transport media
CN101909060B (zh) 一种适用于移动视频实时流媒体传输的Qos控制方法
US9609040B2 (en) Efficient bitrate adaptation in video communications over IP networks
US8811167B2 (en) Shaping multimedia stream bit-rates to adapt to network conditions
US8068436B2 (en) Methods and systems for estimating network available bandwidth using packet pairs and spatial filtering
WO2008014707A1 (fr) Procédé, système et écran de réglage de qualité vidéo
CN104270649B (zh) 影像编码装置及影像编码方法
US8634300B2 (en) Reducing communication delay of video data
EP2658167A1 (en) Transmission control method of video-stream based on dual time scale
US20170142029A1 (en) Method for data rate adaption in online media services, electronic device, and non-transitory computer-readable storage medium
JP2017069849A (ja) 映像制御装置、映像配信システムおよび映像制御方法
CN113891172B (zh) 一种适于无线Mesh网络的基于RTT的自适应码率控制方法
CN107483990B (zh) 一种流媒体传输的动态码率调节方法、装置及传输系统
CN110572780B (zh) 视频组呼业务传输速率调整的方法、装置、设备及介质
CN115378832A (zh) 拥塞检测方法、装置及流媒体传输系统、电子设备和介质
CN109698928B (zh) 一种调节视频会议系统中视频流的方法及装置
CN111385648A (zh) 一种视频帧率的调控方法和系统
KR101931512B1 (ko) 변형된 퍼지 논리 기반의 dash 적응 알고리즘을 이용한 미디어 스트리밍 장치 및 방법
CN110876121A (zh) 一种B-TrunC视频组呼码率调整方法和系统

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
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20200909

Address after: 501-3, 5 / F, building 6, 54 courtyard, Shijingshan Road, Shijingshan District, Beijing 100041

Applicant after: Diankeyun (Beijing) Technology Co.,Ltd.

Address before: 230031 West Lake International A1307, 69 Wangjiangxi Road, Hefei City, Anhui Province

Applicant before: HEFEI XIETONG TECHNOLOGY Co.,Ltd.

GR01 Patent grant
GR01 Patent grant