今天看到一篇写UDP 丢包场景的文章，其中提到如果UDP 缓冲区填满导致丢包的问题，写了个小程序验证了下，确实之前没有细究过，如何解决，以libevent测试程序为例，在接收到缓冲区有数据的事件后，首先通过如下的方法，或者libevent封装的方法，获取到系统缓冲区中可读数据的大小，然后申请到对应大小的buffer去调用recvfrom方法，否则会出现如上UDP可读缓冲区小余可读数据的情况，导致出现UDP数据读不全的问题！

Jitsi是一个基于WebRTC的开源会议服务系统，主要提供高质量、安全、可扩展性强的视频会议能力；使用网上的安装过程，大都第一次能正常的安装，并打开一个人的会议，但未必能调通多人的会议功能，从github的Issure中，包括很多类似的问题“Jitsi-videobridge2 Failed to select initial bridge for participantRegion=null”，而且还很多，将修复的过程做了记录

zulip号称是特性强大的企业版即时聊天应用，开源并且有超过500家企业部署使用，出于好奇，所以安装了一个版本体验体验，国内鲜有安装过程记录，有一个通过docker-compose安装的脚本，但zulip的容器启动总是报错，所以单独安装了一遍，记录安装过程中的错误。

这是两年前刚接触WebRTC时整理的PPT，分享出来！从WebRTC技术概览、WebRTC客户端技术、WebRTC服务端技术三个方面来梳理！

FEC(Forward Error/Erasure Correction）称为前向纠错技术，通常结合Reed-Solomon算法（RS算法），由发送方进行FEC编码后，引入冗余包，接收方进行FEC解码并恢复丢失的数据包，以解决由于UDP的丢包引起通话双方的卡顿，花屏等QOS问题；根据互联网成熟的案例，增加冗余包是对抗丢包常用且有效方法，在合适的冗余比下，能显著提升UDP传输的丢包、乱序抵抗力，为上

主要需要实现如下几个核心能力：1、支持GB28181的SIP协议栈；2、网络框架，处理UDP、TCP等Socket；3、H264/H265/AAC/OPUS/等编码和解码库；4、解码播放显示框架；主要三方框架：1、网络框架使用ZLMediaKit中的zltoolkit ;2、sip协议栈使用sip_sofia ;3、codec包括ffmpeg/x264/openh264, ilbc,faac,fa

medooze的mcu源码还是比较好理解的，Modooze 异步 I/O 事件处理机制是依靠 poll 来驱动的，目录清晰，代码结构也不复杂​，适合用来做mcu框架的参考！

做转码服务的原型时，看了看MCU的实现，考虑到如果不做转码，可以将多路rtp流直接合成为一路rtmp流输出，这样对于多人连麦，然后转发直播的实现就很方便了，所以做了这个功能的实现！同转码服务的类图设计：基础库是ZLMediaKit，确实很方便！直接上代码：TranscoderTaskManager.h可以使用linux的nc 127.0.0.1 3500 进行客户端测

今天考虑一个mcu混合的实现，也就是接收多路过来的rtp流，然后转发出去一路的rtmp流，使用ffmpeg测试做的记录，刚开始一直通过ffmpeg推送的文件流不能满足要求，还是对参数配置不熟悉；

一篇旧日志，搬过来！Licode是基于WebRTC技术之上的开源项目，通过更便捷（easy，fast and scalable）的接口你可以快速搭建出基于WebRTC技术的网络视频会议系统，或者与此类似的系统。你可以通过Try it!对Licode有个更为直观的认识。其中，Intel基于Licode的开源项目构建了一套WebRTC的开发SDK，也侧面说明Licode项目的价值，值得学习和借鉴；