WebRTC开发者社区为开发者提供最新最全的WebRTC资料
目录
  • 首页
  • WebRTC概念与基础
  • WebRTC项目与应用
  • WebRTC教程资料
  • WebRTC开发资源
  • WebRTC源码分析
  • WebRTC服务端开发
  • WebRTC网络与通信
  • WebRTC编码与解码
  • WebRTC问题与缺陷
  • WebRTC-Androd端开发
  • WebRTC-RFC文档
  • WebRTC音频处理
  • WebRTC-Mediasoup
  • FFMpeg音视频处理
  • H264编解码基础
  • openCV相关

WebRTC之带宽控制部分学习(1) ------基本demo的介绍

2021-07-03 16:40:04

 

转自:http://blog.csdn.net/u013160228/article/details/46392037

 

WebRTC的代码真是非常之大啊,下载以及编译了我好几天才搞完。。。。。

可以看到WebRTCd代码分成了4个部分,目前为止只看了talk里的一些东西。

      1、 talk中的项目文件大多数都是以libjingle开头的,可以看出libjingle是WebRTC中非常核心的一个东西啦。

       libjingle中开辟了两个通道,分别为会话通道和数据通道,一个用来会话建立管理等,一个用来传输数据。

       libjingle_media是用来渲染获取视频,libjingle_p2p和libjingle_peerconnection是不同的会话方式用到的库吧,现在还没有细看

       peerconnection_client和peerconnection_server则是可以直接运行的demo,设为启动项目就可以测试了,先运行server。

     2、由于项目研究的是关于带宽估计的东西,所以我们看的文件主要有两个,一个是上行带宽的估计和控制,一个是下行带宽的估计和控制

          上行带宽的文件在webrtc/modules/bitrate_controller,下行带宽的文件是remote_bitrate_estimator

         下面讲一讲Goolge的WebRTC中自带的码率控制:

                  

 

发送端发送RTP包,同时接收来自于接收端的RTCP反馈报告,整个拥塞控制算法分成了接收端和发送端两个部分。接收端的控制算法是基于时延的算法,其目的是减小时延;发送端的控制算法是基于丢包率的算法,其目的是减少丢包。接收端的算法计算出一个速率Ar,然后将这个码率反馈给发送端,用来限制发送端基于丢包率算法计算出来的发送速率。

 

 

发送端基于丢包率的控制方法在每一个tk时刻或者tr时刻启动。tk表示第k个RTCP反馈报告的到达时间,tr表示第r个REMB信息到达发送端的时间,其中REMB信息中包含接收端反馈的Ar信息。RTCP包内包含丢包率fl(tk),发送端根据丢包率计算接下来的发送速率,具体计算方式图公式1所示:

 

 

 

 

 

  接收端速率控制:

   

                接收端算法的目的就是计算出能保证低时延情况下的接收速率Ar,Ar的计算过程如图2所示:

 

      

 下面介绍接收端也就是remote_bitrate_estimator中的几个模块算法

       

1) The arrival-time filter

该模块的目的是为了计算排队时延m(ti),单向时延(one way delay variation)计算方式如下:dm(ti)= ti–ti-1–(Ti –Ti-1 )                                (3)

       式中,Ti表示第i帧视频发送的时间戳,ti 表示第i个视频帧接收到的时间戳。单向时延是三个部分的总和,包括传输时间、排队时延m(ti)、网络抖动n(ti)。GCC算法中提出了下面这个公式:

  

式中,∆L(ti) = L(ti) −L(ti−1),L(ti)是第i个视频帧的长度,C(ti)是瓶颈链路容量估计,n(ti)是网络抖动(高斯噪声模型)。为了将dm(ti) − d(ti)的差值缩小到趋于零,用卡尔曼滤波器提取出状态向量,具体工作方式如图3所示:

 

 

 

The over-use detector

       每帧视频收到的时刻,即ti时刻,该模块都会产生一个s信号以驱动下一个码率控制模块。当m(ti)大于阀值γ,信号为overuse;当m(ti)小于阀值γ,信号为underuse。

 

 

Remote rate controller

       该模块的目的是为了估算数接收速率Ar,其算法流程如图2所示,由信号s决定码率的调整,η ∈[1.005,1.3],α ∈[0.8,0.95]分别为增性系数和碱性系数。

上调:Ar(ti)= ηAr(ti−1)

下调:Ar(ti)= αR(ti),其中R(ti)是最近500ms内的平均接收速率。

 

 

 

REMB Processing

       该模块的功能是将上一个模块计算出的速率Ar通过REMB信息发给客户端。REMB信息发送间隔为1s,但当Ar下降了3%,即Ar(ti) < 0.97Ar(ti−1)时,则立即发送REMB信息以调整码率。

By:rasp | WebRTC网络与通信 |

  • 分类目录

    • WebRTC概念与基础 (252)
    • WebRTC项目与应用 (33)
    • WebRTC教程资料 (38)
    • WebRTC开发资源 (13)
    • WebRTC源码分析 (19)
    • WebRTC服务端开发 (27)
    • WebRTC网络与通信 (43)
    • WebRTC编码与解码 (15)
    • WebRTC问题与缺陷 (2)
    • WebRTC-Androd端开发 (2)
    • WebRTC-RFC文档 (1)
    • WebRTC音频处理 (6)
    • WebRTC-Mediasoup (2)
    • FFMpeg音视频处理 (3)
    • H264编解码基础 (10)
    • openCV相关 (1)
  • 最新文章

    • TensorFlow 中的通信机制 ——Rendezvous(二)gRPC 传输
    • 详解|SRT编码器中Rendezvous模式详解
    • 完整SIP/SDP媒体协商概论-ICE初始offer发送详解
    • 完整SIP/SDP媒体协商概论-ICE初始offer发送详解
    • WebRTC - ICE 过程简述
    • Webrtc delay-base-bwe代码分析(2): InterArrival模块
    • 从janus中学习webrtc的ice简单交换过程
    • WebRTC PeerConnection 建立连接过程介绍
    • P2P技术详解(三):P2P技术之STUN、TURN、ICE详解(转载)
    • WebRTC ICE 状态与提名处理
    • licode服务端总结
    • libnice调用流程分析
    • libnice调用流程分析
    • licode 学习总结
    • Licode—基于webrtc的SFU/MCU实现
    • ncnn_example
    • opencv-rtsp运动检测
    • WebRTC 基于GCC的拥塞控制(上)
    • WebRTC 基于GCC的拥塞控制(下)
    • LearningWebRTC: 拥塞控制LearningWebRTC: 拥塞控制
    • WebRTC入门(三)---- 目录结构
    • WebRTC之带宽控制部分学习(1) ------基本demo的介绍
    • webrtc视频流程
    • webrtc nack实现原理
    • webrtc QOS方法一(NACK实现)
    • webrtc源码之nack&&rtx详解
    • webrtc的rtp重传代码分析
    • webrtc QOS方法一(NACK实现)
    • WebRTC基于TransportCC和Trendline Filter的发送端码率估计(Sendside-BWE)
    • WebRTC中丢包重传NACK实现分析
  • 链接

    • WebRTC官网
    • xSky 实验室
    • 树莓派技术圈
    • 声网 Agora
    • WebRTC中文网
    • web性能权威指南
    • WebRTC官网
    • webrtc在线源码
    • webrtc在线源码
    • webrtc
    • webrtc示例
    • LiveVideoStack
    • 雷霄骅(leixiaohua1020)的专栏
  • 开源项目


Powered By xblog Copyright 0xsky.com All Rights Reserved.

Copyright WebRTC.ren All Rights Reserved.