基于live555实现流媒体代理服务器（7）-终结篇

前面已经讲了基于live555实现rtsp流媒体代理服务器的完整的流程，以及高性能改造；核心的内容已经讲完了，这篇文章就做一个总结。看看这样做出来的服务器是否还有一些缺陷或者可能的问题。

总体上来说，按照前面的方法你已经可以实现了一个高性能的rtsp流媒体代理服务器了，或者叫rtsp协议媒体网关了；那么他还可能存在哪些问题呢？

1、live555递归问题：函数递归调用比较费cpu，而且不是一个推荐的处理方式，很多公司甚至直接禁止在代码中出现递归调用，不过live555中无法避免；我们怎么办呢？

  1.1、对于信令处理来说，通常只有在异步通信出错的时候，才可能需要等待较长时间，导致递归调用不能及时返回；所以我们需要一台服务器（例如VMS）管理被代理前向设备状态，例如IPC相机；在设备下线后，不提供播放代理即可，这样即可避免大量的查询URL错误，或者播放失败，触发递归等待；

  1.2、如果我们在live555代理服务器中，记录前向代理失败的会话，并进行一段时间的会话冻结，可以通过streamId来识别，这样也就很容易避免多线程并发时候，出现代理失败，而反复递归等待的问题了；

  1.3、通过上述优化我们能够避免了95%以上，因为异步通信阻塞导致递归调用可能出现的性能损耗的情况，很大程度保证了系统cpu占用率的稳定性；

  1.4、对于媒体处理来说，live555里面也有一些地方通过递归分析媒体流属性参数的情况；通常都是在流通道建立的时候，所以我们可以通过适当控制呼叫caps来减轻递归压力；这并不影响总体媒体流的吞吐量的，至少在安防应用场景下是不会有任何问题的。

2、媒体转发性能问题：live555对于转发大数据帧时，会出现一些丢包的问题，无论udp还是tcp都一样；通常情况，对于25fps流，我们可以控制1帧数据在40ms内发完即可，而不是前1ms发完，后面39ms没事干。这个逻辑live555实际已经实现了，只不过有些问题，稍稍优化控制一下就可以了。其他也有几个小地方可以优化，不过无伤大雅。目前我们转发数据，以10倍速转发录像数据，问题都不大，再高的话，才可能有丢包。

总体上，live555没有让人失望，达到了我们对流媒体服务器性能设计的需求；在华为提供的48虚拟核服务器上（还部署了其他服务），200路1080P@25fps，H264/H265媒体流转发，2-4Mbitps，输入输出总带宽在交换机上统计到的范围在600mbitps-1200mbitps之间。cpu使用率在200%-1200%之间，也就是相当于跑满2-6个cpu虚拟核心，大多数时间cpu在200%-400%之间；在早期施工阶段，片区IPC断网，导致流媒体服务器出现瞬时大量取流失败，会引起并发大量的live555递归调用，出现超时等待出错等处理，cpu使用上升到1200%左右。后续施工结束了，就很少出现了。特别是，现在加上了上面描述的caps控制等策略，基本就不会出现cpu飙升了。live555配置了1主+24从线程。