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

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

假如世界末日来了，你的亲人，朋友，都未能躲过这场浩劫，而你，刚好意外地出现在诺亚方舟上，亲眼目睹灾难发生后的世界，在绝望不断地逃生，在自救和他救中，还原出人真正的本性！这就是这样子的一部片子《绝夜逢生》，第一季，一共6集，每一集就30多分钟，短小精悍，一口气就能看完的短剧，紧张，刺激，不拖泥带水，一气呵成，看完了，还想着看续集的那种意犹未尽之感！

I/O模型主要包括：阻塞IO、非阻塞IO、I/O 多路复用、异步I/O和信号I/O;阻塞和非阻塞能应用于所有文件描述符。所谓阻塞方式的意思是指，当试图对该文件描述符进行读写时，如果当时没有东西可读，或者暂时不可写，程序就进入等待状态，直到有东西可读或者可写为止；而对于非阻塞状态，如果没有东西可读，或者不可写，读写函数马上返回，而不会等待，O_NONBLOCK 的标志打开文件/Socket/FIFO句柄，如果连续做 read 操作而没有数据可读，此时程序不会阻塞起来等待数据准备就绪返回，read 函数会返回

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

刚入职H公司一个月，开始修改的问题主要是文档日志类，这些文档包括对外输出的用户手册和产品使用说明；其中有逻辑严谨，并经过测试验证的流程描述，也有故障恢复步骤说明，并要求对应的英文文档，体会最深的是对Word使用的熟练程度，不亚于毕业论文文档格式要求，所以尽管过去8年之久，依然记忆犹新；LM抽查问题修改单，其中就有我修改的一个，这是一个文档修改的需求单，通过问题单的形式修改提交，处于已经回归完成阶段

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框架的参考！