最近接触一个监控视频服务器的代码，觉得代码的实现思路和之前考虑的监控拉流转发的思路有一些差异，整理一下

推出的音视频服务的产品，其可用性、易用性和用户体验如何，对于复杂网络场景下的处理如何，这是相当考验技术的一个行业，投入的资源和技术积累的程度，核心算法的设计、开发能力，都是尤其重要的，所以通过互联网开源项目堆出的产品，只能处在demo环节，离真正的产品化还有好远好远的距离；通信网络技术：TCP和UDP的选择；搞不定丢包就选TCP，比方POC语音对讲相对小数据量的应用，就适合选用TCP;比方实时性要

尽管一对一语言/视频通话的能力可以通过会议模式实现，但一对一模式还是较为特殊的应用场景（比方一对一打电话的时候，P2P网络会有优于服务器转发的情况），所以这里同时分析一对一和会议模式下SFU级联场景下的媒体包多路径转发问题，如下只提供一个思路，并非考虑实现； Jitsi针对跨区域出现的星星拓扑问题，给出的解决方案是SFU级联的方式，详细可以参考：https://webrtc.org.cn

CSDN旧文搬迁！在Android采集视频过程中增加水印，并且水印包含一个变化的时间戳，这里考虑方案实现的时候，就想到了ffmpeg，ffmpeg包含很多filter能实现水印添加的功能。基本实现方案是，Camera预览 -> 得到预览帧的bitmap -> 给bitmap通过ffmpeg 添加水印  -> ffmpeg把bitmap使用h264编码 -> 写文件

CSDN搬家的旧文！使用librtmp库将拉取监控的rtsp流推送给srs服务器，发现一个异常，在长时间大概1个月后发现系统内存被srs吃满，也不知道是什么原因产生的这个现象，并且通过top去查看srs的内存在持续增长，通过ffmpeg推流没有这个现象，感觉还是librtmp使用的问题，暂时也没有很好的思路分析；通过查看srs的git库，发现srs提供了一个srs-librtmp的源码库，能完成推

​原来面对这些问题，除了网络层的优化外，协议层的优化也很重要，WebRTC中涉及相关的算法和标准的应用，理解和优化这些算法能力是很重要的！

给ZLMediaKit添加一个录制MP4文件自动转HLS的功能，最近一个需求是自动接收监控视频并录制为MP4，并支持HLS点播，使用ZLMediaKit较快的实现了这个功能，分享出来！

"构成我们学习最大障碍的是已知的东西，不是未知的东西" ------现代医学奠基人贝尔纳WebRTC 交互的流程大致如下：图片来源网络：https://www.jianshu.com/p/a7e7cb4d6d641、进入房间；2、获取媒体，交换SDP；3、通过turnserver手机本机地址，交换candidate；4、ICE进行候选地址进行连接，连通了，则可以进行音视频通话；

今天看到一篇“一个视频自动加字幕的小工具，如何做到月入2W”的博文（突字幕），考虑这个小工具如何实现，以及可能的关键难点，感觉有点意思；在当前人工智能、机器学习的热潮下，在依托成熟三方服务或者开源实现，实现一个类似的应用还是不难的，而核心的技术难点也显而易见，主要在语音识别，以及机器翻译的准确性上！关键功能点，给视频自动添加多语种字幕，大概的实现流程：1、视频中音频部分提取，含时间戳！2、语音识别，音频部分

在考虑实现一个P2P的公网监控点播方案，监控端通过局域网组网，局域网放一台服务器（双网卡，可上外网），作为局域网内所有监控的控制出口，该服务器上运行ZLMediaKit Server程序，集成tinyfecVPN Server的能力，通过该端口维持一个端口到公网STUN服务器的心跳（并转换为公网的地址和端口），所有接入的客户端通过公网的地址和端口点播实时的监控（协议走rtmp、rtsp或者hls均