​知识和技能是有关联，有重叠，知识能学到，而技能只能习得，所以你最先开始识别你学习的是一种知识，还是一种技能，并采用不同的方法来应对；比方编程是在理解计算机程序知识的基础之上，在计算机上进行的一种体力劳动，那么编程有一半可以理解为知识，而另一半则理解为技能，所以培训的活动既要有学习知识的记忆，消化，也有技能学习的不断地刻意练习，实战，两种都要扎实，两种都不可偏废！

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

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

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

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

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

主要需要实现如下几个核心能力：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 进行客户端测