对业内人士来说流媒体平台这个词一定不陌生，圈子以外的朋友可能只知道个基本的概念，如何选择适合
自己的流媒体平台可是个很大的话题，说道细处，三天三夜都说不完。今天结合自己的经历的一些案例，从宏观
上跟大家分享下我的心得体会，希望帮助到有需要的朋友。
首先从协议上说说几种常见的流媒体类型，主流的流媒体类型有rtsp服务、rtmp服务、Hls服务还有就是
GB28181。
我了解到的以rtsp协议作为流媒体分发服务的并不多。很多摄像机标称支持rtsp协议，实际就是内置一个
rtsp服务方便用户以rtsp协议获取摄像机输出的音视频流。通过抓包可以发现很多摄像机内置的rtsp服务是通过
live555实现的。早起的live555性能很一般，如今的live555已经升级更新，性能如何不敢胡乱评论。早起live555
性能尽管很一般，作为IP Camera的服务，性能上可以满足要求。网络带宽的原因，很少人会大并发访问 IP
Camera。基本都会另建一流媒体服务作为分发服务器，流媒体服务只从IP Camera取一次流，以rtsp协议方式。
通过rtsp协议取流有哪些优点呢？首先想到的是低延时，延时对实时流媒体来说无疑是个非常重要的指标，的确
延时方便rtsp协议可以到很好，到底有多好，要区*域网跟公网，后面说道其他协议时再一起说。rtsp协议的
另一个优点是音视频数据传输在传输层有多个协议类型供选择，分别是udp，tcp,udp_multicast（组播）。udp
与tcp如何选择，这跟实际的网络环境有关，也跟需求有关。比如说需要上明确规定不能出现一点花屏，如网络
环境还算可以（偶尔出现抖动)可以选择tcp作为音视频数据传输方式，如果网络很糟糕，用tcp的结果只能是越来
越堵，不能从根本上解决问题。如果需求对延时要求非常高比如要求延时低于200ms，优先选择udp，选择udp
带来的问题是网络出现抖动时视频包丢失以后会出现花屏现象。花屏是很多客户是接受不了的，怎么来解决这个
问题，大部分情况下丢弃掉有缺失的视频帧即可。在网络抖动的情况视频画面出现瞬间卡顿大部分客户是可以接
受的。当然也有少部分的客户不希望看到视频出现瞬间的卡顿，能不能做到？这个要视情况而定，主要的影响因
素还是网络。udp_multicast(组播)传输方式并不是所有的网络环境都支持，多级交换机网络需要交换机自身支持
网络。udp_multicast传输有什么好处呢？好处便是节省带宽，接收从IP Camera 到交换机之间的带宽多用户同时
请求情况下从IP Camera 到交换机实际只取一次流。
很多直播、点播平台选择rtmp服务作为流媒体平台的核心服务。Rtmp 服务有哪些有优点呢？低延时算时一个
优点，公网下如网络流畅，rtmp可以做到1S左右延时，很多应用场合1S延时已经满足需求（如果追求最低当然rtmp
不是最佳的选择，可以选择rtsp协议，传输层选择udp协议）。另一个优点是PC端 网页播放。PC端网页播放只要嵌
入Flash即可，浏览器的兼容性很多，不要为插件的兼容性烦恼。rtmp协议传输层采用的是tcp协议相较人rtsp协议
灵活性不佳。特别是网络延时高的情况下不建议使用rtmp协议。目前开源的rtmp服务有CrtmpServer，SRS,Nginx
Rtmp等等。本人用的最多的是CrtmpServer，CrtmpServer只是简单实现rtmp服务功能 即接收前端主动推流，当有
客户端请求音视频流时将缓存的音视频流推给请求者。这个服务实际是单线程操作。一般的安防领域CrtmpServer是
性能足以满足要求。比如在window系统下CrtmpServer单台服务可以支持500路以上，Linux系统会更高（linux系统
上限未实际验证，只是从IO模型上得出的结论）。SRS,Nginx Rtmp服务由于没有在实现的环境中验证，并发量能到
多少不能确定，大量的博文显示二者的效率都很高，更人心动的是这两个服务的附加应用更多。很多刚开始接触流媒
体的朋友更钟情于SRS,NginxRtmp。我为什么选择CrtmpServer 原因之一是接触的早，原因之二是我不需要服务的附
加应用，所有的应用都可以自己的方式，按自己思路跟需求设计，在别人的模式下往往受到很多限制。CrtmpServer
我用的也只是协议部分，rtmp协议相较其他协议还是复杂很多，参考已有的且稳定运行的实现还是要省一些时间。至
于视频源的管理，以及客户请求链接的管理并不使用CrtmpServer那一套，毕竟单线程的管理模式不通用，也不好用。
Hls服务是最为简单的一种服务，我说的简单指的是协议。Hls服务本质上是Http 服务+TS流，当服务接收到用户
请求音视频时服务将本地的切片（小的TS文件）以Http的方式回发给请求者。切片文件的大小以及时间的长短可以根据
需求设定，每次发送哪个切片由一个后缀为m3u8的索引文件控制。人们经常说的m3u8格式实际就是指Hls流。Hls流天
生的缺陷是延时大，传输层只能采用tcp。从性能说相较其他的服务并没有优势，那Hls流的优势在哪里?只有缺陷没有优
势很快会被淘汰。Hls流最大的优势是移动端的兼容性。Hls流很容易实现在移动端网页播放，不管是IOS还是Android。
我一直觉得如果移动端友好支持flash，Hls流基本没什么用武之地。很多客户的需求都是IOS手机能看，Android手机能
看，而且不希望是在App中播放，大部分都希望直接在网页内打开视频。作为客户并不关心技术，只关心效果，他们要
的是简单方便。曾有一个客户提了一个需求就是”让Hls走天下“：他在国外弄了一台服务器希望我们通过流媒体技术将他
的视频节目推送到该服务器并发布一个视频流地址，他的客户可以直接在手机网页端打开我们发布的地址观看他们的节
目，另外他要求使用Hls流。一听到服务器在国外，首先想到的是延时。最简单的测试方法：长时间ping远端服务器，延
时基本在180ms左右。我们告诉客户服务器延时太大无法用Hls流实现，客户答复延时大点没有关系，能正常播放就行。
客户的理解很直白，ping延时大点，多缓冲点不就可以了吗？我们可以对客户Say No 但决不能说客户无知，毕竟术业有
专攻。退一步说客户什么都清楚还要我们干嘛呢？最后我们给客户的答复是可以将服务器放在国内，或者另选视频传输协
议。客户说服务一定要放在国外且一定要用Hls流，我们最后的答复是实现不了。Hls流协议实现方式并不高明，性能也很
一般却在业内圈了很多用户其原因归根结底是协议的制定及推广者拥有很大的客户群体。
GB28181是国内专家拟定的流媒体通信协议，协议本身算是SIP的子集。2011年发布了GB28181第一个版本，2014
年有了增补版本。开发基于GB28181的流媒体服务可以借助于开源库PJSIP或者是OSIP。迄今为止个人觉得GB28181协
议还有很多改善的空间，但这并不会影响GB28181逐渐统一国内流媒体平台市场。