Nack详解

看流程之前先看理论 pacer理论 数据流 1、入队列流程 1.1 入队列流程 RTPSenderVideo::LogAndSendToNetwork RTPSender::EnqueuePackets PacedSender::EnqueuePackets PacingController::SetPacingRates PacingController::EnqueuePacketIntern

1、前言本文是webrtc拥塞控制的下文，主要介绍的是从cc-controller获取码率之后，如何将码率设置到PacingController控制发送速率，同时如何将码率分配调整到各个stream，各个stream的layer, simulcast，fec中2、正文2.1 整体码率控制结构webrtc中是会同时存在多个stream，但所有的stream都会共用一个码率预估和平滑发送，这很符合逻辑

1 前言本文是webrtc中拥塞控制的上文，主要是分析webrtc中的拥塞控制的码率探测，预估和调整的部分，介绍了整体框架和原理以及相关的类；webrtc版本:M912 正文2.1 整体框架webrtc中的部分码控结构如下图所示，从socket层接收到数据后，到transport解析rtcp包处理得到feedback，通过call将feedback转发到对应sendstream上的rtcp处理模块

背景介绍若仅仅发送音频数据，不需要PACER模块：1）一帧音频数据本身不大，不会超过以太网的最大报文长度。一个RTP报文可以搞定，按照打包时长的节奏发送就可以。但视频数据不能按照音频数据的思路发送，一帧视频可能很大，远大于以太网的1500byte，需要分别封装在几个RTP报文中，若这些视频帧RTP报文一起发送到网络上，必然会导致网络瞬间拥塞。产生丢包抖动等异常。2）大多数编解码格式下，一帧音频数据

1、简述video_loopback demo演示了怎么从call这一层创建流，接下来看一下视频的采集，编码，发送流程，本文只是粗略的跟踪流程，具体细节知识点后续分析。webrtc的更新太快，模块有些调整，也加了些处理流程，所以得重复的去看流程，也是因为脑子不好使，看完接着忘。2、跟踪代码...

1.为了平滑渲染，造成延时FrameBuffer::StartWaitForNextFrameOnQueue()|FrameBuffer::FindNextFrame在FindNextFrame里面有计算渲染时间if (frame->RenderTime() == -1) {frame->SetRenderTime(timing_->RenderTimeMs(frame->

vmware15 ubuntu18.04 无法联网试过手动配置和自动获取都没法联网，这种问题也挺烦人，怀疑是电脑多个网卡导致解决办法：1、网络适配器共享设置网络连接属性，共享设置2、vmware编辑 虚拟网络编辑器vmware->编辑->虚拟网络编辑桥接到，选择自己的物理网卡。感觉应该是这里的问题，多个网卡系统默认出错了...

1 介绍video_loopback demo包含了webrtc上层网络协议的剩余部分，没有sdp协商，p2p，srtp，实现了从call实现音视频互通的例子。对于动手能力比较强的公司，适合从这层开发，搭建自己的架构模型，实现自由调度，大并发等2 分析源码2.1 demo入口启动入口：src/video/video_loopback_main.cc配置参数：src/video/video_loop

http://blog.csdn.net/yangzhiloveyou/article/details/8709188数字电视的TS包和TS流的组成和功能综合考虑几下几个因素：（1）包的长度不能过短，否则包头开销所占比例过大，导致传输效率下降（2）包的长度不能过长，否则在丢失同步的情况下恢复同步的周期过长，导致较多的信息丢失（3）其他环境