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

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

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

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

首先是有这么个问题：现在推出的手机都主打摄像头的性能，苹果的浴霸式摄像头组，华为小米等等高端机的摄像头都千万甚至亿级像素了，拍照还需要相机吗，我想很多专业人士给出的答案都是需要。前两天在极客时间上听了几节独立摄影师小麥的《摄影入门课》，从摄影的历史，到基本的ISO、光圈、快门、曝光的基本概念、应用场景，再到相机的选购，听过了好像有那么点感觉。

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