WebRTC

不同平台处理事件有不同的API Win平台下提供了 WSAEventSelect和完全端口两种接口处理事件, 完全端口处理事件会更高效,但是webrtc选择的是WSAEventSelect. Linu

webrtc的所有其他线程都是由三大线程所创建的, 而这三大线程是在创建peer connectionfactory的时候所创建的,线程参数如果传空, 就会在内部逻辑自行创建这三个线程, 并通过Sta

ThreadManager的路径内部数据 几个重要成员 ThreadManager* Instance() : 单例对象 std::vector<Thread*> message_queues_ :

Thread中的数据以及源码路径 MessageList messages_ : thread中是包含队列的, 有需要线程处理的任务需要先入队, 线程会依次处理, 保证每一个mesaage可以得到有序

VideoBroadcaster属于vcm capture中的一个成员, 通过vcm capture 获取到采集的数据之后,再通过VideoBroadcaster分发出去. 这里主要讲解一下视频是如何

直播技术的方向 从产品上分类 : 传统直播 : 直播购物、娱乐直播、 游戏直播 实时互动直播 : 音视频会议、在线互动课堂 实时互动直播和传统直播的最大的不同点就是: 能否实现多人的实施音视频互动 不

实时通信延迟指标 最简单的测试方法就是, 让通信双方的摄像头对着同一个人数手指读秒, 精确度较低, 还可以两个摄像头都对着电脑屏幕上的秒表,观察两端发送出去的画面上秒表时差是多少. 音频服务质量评测指

线程模型一 组成:  任务队列, 队列中的每一项是包含了run方法的任务对象 线程控制器: 用于控制线程的使用 线程池: 用于线程的分配 好处: 可以控制线程的数量, 线程太多会影响效率, 每次切换效

整体架构 目录结构 运行机制 peerConnection 调用过程 从上图中可以得到以下结论: Stream中可以包含一个或多个音频或视频轨. PeerConnection内部有两个线程: work

webrtc要解决的就是两个浏览器之间如何实时音视频互动的问题,对于底层来说就是两个端点之间如何进行高效的网络传输. 为此webrtc引入了多个传输协议 NAT : Net Address Trans

STUN存在的目的就是进行NAT穿越 STUN是典型的客户端/服务端模式.客户端发送请求, 服务端进行响应. RFC STUN规范 RFC3489/STUN : Simple Traversal of

QOS : Quality Of Service, 顾名思义就是服务质量的意思. 以下内容参考自: https://blog.csdn.net/CrystalShaw/article/details/

概念 mediasoup 是完全兼容webrtc的高性能sfu服务器, 它由ts语言实现的master端和基于libuv的c++语言实现的work模块组成. 严格意义上来说，Mediasoup是单进程

三个重要的组件: signal server : 信令服务器, 用于必要信息的交换, 比如SDP信息进行媒体协商 STUN/TURN : 数据中转, 如果别再同一个局域网内 就会直连, 如果是在外网,