接上篇：单路通话，Freeswitch录制视频CPU高的原因，主要是开启media_bug通道会涉及一次H264解码、两次H264编码，所以CPU高；解决思路就是：由于录制是使用rtsp/rtmp转发流的方式，可以直接将源端发送过来的H264码流转发给rtsp/rtmp服务器，这样就减少了Freeswitch端的解码和编码过程；上篇已经减少了一次转发给b_leg时的编码，确实CPU负载就降下来了，

现象是视频通话，给FS配置录制到rtsp服务器，单路通话Freeswitch占用CPU高： PID USER      PR  NI    VIRT    RES    SHR&n

​问题：非代理模式下，视频媒体主叫如果是recvonly，主叫收不到被叫发过来的视频包！发送方的payload type和协商的不一致，freeswitch过滤了； freeswitch接收到一方的包，解码完后，并没有转发给对方；freeswitch代码逻辑还是相当复杂的，一个函数通常都是上千行的代码，所以跟踪分析问题并不是那么容易，最好是gdb结合log打印跟踪分析问题；

应用场景：SIP终端拨入后，FS将该SIP终端的视频流转发为RTSP 流，提供NVR进行录制；问题1、如何在Freeswitch配置录制？问题2、可不可以在Freeswitch做录制？建议是方案可以，但不建议用Freeswitch做录制；原因是Freeswitch擅长做媒体交换，录制会拖累软交换的性能，建议是Freeswitch转一路流出去，给专门做录制和点播的服务；

问题虽小，也好定位，但验证和修改过程，却不是那么容易，记录下来，后面碰到类似问题修改就容易了！问题：广播终端作为被叫方，接听时，只看对方的视频，本端的视频是recvonly，webrtc生成sdp时是recvonly，但是janus转到freeswitch后，freeswitch收到的sdp的video部分却成了sendrecv;

需求：Web控制台与多个SIP电话终端的建立语音会议；

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

推出的音视频服务的产品，其可用性、易用性和用户体验如何，对于复杂网络场景下的处理如何，这是相当考验技术的一个行业，投入的资源和技术积累的程度，核心算法的设计、开发能力，都是尤其重要的，所以通过互联网开源项目堆出的产品，只能处在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编码 -> 写文件