weixin_29405665的博客

存在问题：1.bandwidth_sampler里面收到ack消息时计算出来的ack_rate忽高忽低，从打印信息来看，有两种情况会导致ack_rate严重下降。a.发生丢包时，也就是packet_number不连续，时间差不变，但是这个时间段内acked的数据减小，那么就会导致ack_rate严重下降。b. 时间差变大，但这个时间段内acked的数据没有变多。通道接收端这时候忙，导致ack消息不能及时发出？ 通过分析打印输出，确定是数据收到端发出的ack消息没有及时发出。2.通过分析c

前言pjsip是一个基于sip协议的跨平台音视频通信开源库，对于sip协议的特性支持得非常完善，接口简单使用起来也很方便，连视频数据的渲染都封装都不需要上层关心（通过sdl来实现）。然而其最大的不足便是对传输丢包的重传支持不完善，没有拥塞控制不能动态调整视频码率。之所以说pjsip2.10对丢包重传支持的不完美，是因为其仅实现了下行丢包的请求重传（而且还是有bug的），上行丢包的重传并没有实现。在这种情况下，一遇到网络丢包，pjsip的视频图像就表现的非常差，到处都是马赛克。在webrtc已成...

创建 producer:async createFFmpegProducer() { if(initFFmpegTransport) return; initFFmpegTransport = true; const audioTransport = await router.createPlainTransport( { listenIp : '0.0.0.0', rtcpMux : false, comedia :true } );

1.客户端通过websocket发送消息，服务器端处理处理websocket消息函数位于 Peer.js 209行。2.node.js向workder发送的消息，将会在worker里面的src/RTC/Router.cpp的HandleRequest函数被处理。3.服务器的IceCandidate由worker进程产生，对应消息WORKER_CREATE_ROUTER。先创建router，router下面再创建WebRtcTransport。多个终端进入同一个房间，共用一个router，一个终.

简述proxy.h

启动线程方式：1. modules/utility/srouce/ProcessThreadImpl::Start() ->rtc_base/PlatformThread::Start()2.rtc_base/TaskQueueWinFactory::CreateTaskQueue ()->rtc_base/TaskQueueWin::TaskQueueWin ()->rtc_base/PlatformThread::Start()3.rtc_base/..

测试

1.在rtp_send_controller线程，源码call/rtp_transport_controller.send.cc的UpdateControllerWithTimeInterval函数，会定时更新bitrate，调用栈如下：->call/rtp_transport_controller_send.cc UpdateControllerWithTimeInterval ->PostUpdate ->UpdateControlState-> call/call.cc

1.在ModuleProcessThread线程里面会周期性的进行音视频同步处理。ModuleProcessThread线程内部维护了一个modules_变量，此变量保存了多个需要周期处理的模块，用于同步的RtpStreamsSynchronizer是其中之一，对应源码位于video/rtp_streams_synchronizer.cc，处理函数Process。2.计算出的目标延迟，将会被设置到VideoReceiveStream类的timing_变量里面，而timing_变量同时也被frame_bu

要点：1.创建PeerConnection后调用CreateDataChannel创建数据通道。2.使用数据通道后，sdp消息中会多出一个m字段：m=application 9 UDP/DTLS/SCTP webrtc-datachannel3.传输DataChannel的数据和传输音视频数据使用同一个udp端口。4.使用SCTP协议来保证DataChannel数据的可靠传输，使用了第三方的库usrsctplib5.收到对端DataChannel消息的处理函数，sctp_transpor

webrtc是一个优秀的跨平台实时音视频通信技术，是一个peer to peer的通信模式。在网络通信中，p2p通信必然会涉及到nat的穿透问题，webrt通过ICE技术来提供NAT穿透功能。ICE(Interactive Connectivity Establishment)，它定义了一个技术，这个技术使用了stun/turn协议，它可以使得客户端能够发现自己的候选通信地址，这些候选地址包括本地地址、本机对应的公网地址、中继服务器的地址，两个客户端通过信令服务器来交换这些候选地址，就可以实现点对点的通信/

本文中的录像，是指在视频通话过程中，对远端视频流的录像。在多媒体开发中，对视频进行录像是一个很常见的需求，因此在使用webrtc进行开发时，也希望可以实现录像的功能。webrtc中的js examples有录像的例子，但是通过调试chromium发现，录像功能的实现并不在webrtc的源码领域，而是由chromium源码中的src\media\muxers\webm_muxer.cc模块来实现，而且webm_muxer模块只能生成webm格式的视频文件，无法生成mp4/flv格式的视频。考虑将webm_

在某些应用场景下，需要将本机的电脑桌面或者指定的某个窗口共享给通话的对端，这个时候webrtc提供的desktop_capture模块就派上用场了。dekstop_capture可以用来捕获整个桌面，或者捕获特定的一个窗口，在捕获到数据后，再传给编码器进行编码，就可以像摄像头数据一样进行发送了。话不多说，先上一张效果图吧，下图是电脑上的webrtc终端和手机的imsdroid进行通话时，imsdroid看到的webrtc终端共享的桌面的视频截图：实现桌面共享，主要有以下两个步骤：DesktopF

webrtc中采用了两种手段来对抗网络丢包，一种是重传，另一种是fec。本文针对视频rtp包的重传实现进行分析，不涉及音频rtp包（猜测应与视频rtp包类似）。与rtp传输相关的模块源码位于webrtc目录下的src\modules\rtp_rtcprtp包的打包。RtpPacketToSend类用来封装待发送的rtp包，可以通过set_allow_retransmission来设置此rtp包是否允许重传。 rtp包的发送。RtpSenderEgress是rtp包的出口类，主要负责将rtp包发送到网络

使用webrtc建立视频通话离不开PeerConnection类,而PeerConnection继承自PeerConnectionInterface。某些场景下，我们希望能够禁用自己的mic，以此来避免对方听到自己在某一时间段内的发话，很可惜PeerConnectionInterface接口类并没有提供禁用mic的功能，这时候就需要自己修改webrtc源码来增加所需要的功能了。通过分析webrtc的源码，得到如下的类图：从类图的依赖关系可以看出，AudioDeviceModule类里面有实现静音

网上搜索webrtc + freeswitch得到结果基本都是基于网页的，利用 javascript +jsSip实现与freeswitch对接，而讲解如何直接利用webrtc的native模块来实现与freeswitch对接的文章几乎没有。众所周知，webrtc的底层实现都是c++代码，对于一个不擅长javascript的c++码农，能够直接利用webrtc模块来搭建一个具备音视频通信功能的客户端无疑是让人兴奋的。本文简要记录一下对接过程，包括对接过程遇到的一些问题以及解决方案，在博客写出来也希望能给