Table of Contents
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
1、流媒体简介
流媒体（streaming media）是指将一连串的媒体数据压缩后，经过网络分段发送数据，在网上即时传输影音以供观赏的一种技术与过程，此技术使得数据包得以像流水一样发送；如果不使用此技术，就必须在使用前下载整个媒体文件，这对于实时性要求比较高的场景而言，显然是不现实的，所以流媒体技术为此孕育而生。
传统的视频监控、IPTV，以及这几年兴起的视频直播、网络授课都属于流媒体的范畴，从广义上来讲，视频通话，视频会议也属于流媒体。
2、视频监控
2.1 传统解决方案的现状和挑战
视频监控是流媒体技术传统的应用场景，在政府、企业以及现在逐渐流行的个人消费市场有着广泛的应用。特别是近几年来，国内各大城市逐步推进平安城市项目进程，在安防、交通等领域，视频监控市场规模愈发壮大。而且随着室内家居摄像头、车载记录仪的普及，视频监控可以说在人们的生活中无处不在。
传统的视频监控解决方案主要建立在基于 LAN 的网络、服务器、录像机和摄像机的基础之上。这些高度复杂的解决方案具有很高的施工和维护成本， 因为传统基础设施价格高昂，并且需要时间来规划、实施和维护。传统的视频监控解决方案也不好扩容维护，对于用户而言，也不友好，操作使用局限在局域网中，已经难以适合新时代的发展。
2.2 发展趋势
由于一些互联网企业的入局，视频监控行业也在经历一系列的变局，譬如小米摄像头、360水滴摄像头的流行，也鞭策着传统的视频监控行业相关企业的变革(譬如海康威视推出的萤石云平台)，虽然目前这些变革多数还局限于个人消费市场，但从长远来看，视频监控上云，是未来发展的大趋势。
基于云的视频监控解决方案由于其高质量、可靠性、安全性、便捷性以及较低的部署和维护成本而越来越受到人们的青睐。
预计未来视频监控，将像目前流行的网络直播一样方便，用户安装好摄像头后，接入网络即可视频上云。使用者在浏览器或APP即可查看所有摄像头的实时监控以及历史录像，通过APP或绑定的手机号码，可以实时接收摄像头发送的事件通知(譬如入侵事件)。
2.3 技术难点
由于历史原因，传统的视频监控行业技术栈多采用私有协议SDK、onvif/rtsp等协议栈。这些协议目前对浏览器而言都不友好，在以前IE浏览器还流行的时期，可以通过ocx插件的方式来对接这些协议，但是随着IE的没落以及目前流行的chrome、火狐浏览器对原生插件的愈加不友好，通过插件的方式来实现访问监控视频的方式将愈发困难。如果要在chrome、火狐浏览器上访问监控视频，目前有以下几种方案可行：
- rtmp
目前主流的chrome和火狐浏览器都还支持flash插件，所以目前在浏览器上还可以通过rtmp方式来访问监控视频。但是由于随着html5的普及以及flash的停止更新，预计可预见的未来，rtmp技术将随着flash一起行将就木(谷歌宣布chrom浏览器2020年12月将不再支持flash player)。
- http-flv
http-flv直播的方式是一种比较新颖的方式,该技术基于html5,可以通过无插件的方式实现视频直播，而且由于rtmp负载可以平滑的转换成http-flv协议,所以正在逐渐取代rtmp成为新的直播技术标准，目前各大直播网站(譬如斗鱼直播，bilibili等)也陆续从rtmp切换成该技术。 但是由于浏览器的限制，不能同时打开过多(chrome限制6个)的同域名下的直播窗口，所以该技术也不太适合多路同时打开(譬如9宫格视频)的视频监控领域。而且由于Adobe的不作为，flv容器格式停止了更新，对H265的支持遥遥无期。
- ws-flv
ws-flv直播技术基本与http-flv一致，无非是传输介质换成了websocket协议，除了解除了http-flv不能同时打开过多同域名下的直播窗口的限制，其他技术特性、参数基本与http-flv一致。目前看，ws-flv既适合视频监控(可以同时打开多路监控视频)也适合视频直播行业，是rtmp很高的升级替代方案。
- webrtc
webrtc是谷歌主导的视频通话技术标准，目前各大主流浏览器都兼容该标准。通过该技术，用户可以在浏览器上实现无插件的视频通话，该技术也可以用于实现低延时的视频直播。目前业界也有很多基于webrtc的应用和产品，但是很多局限于视频聊天等低延时交互式场景，在视频监控领域，目前还尚未流行。而且该技术栈目前还在持续更新，技术难点太多，要与视频监控领域融合还需时日。
- hls
hls协议是苹果公司主导的技术标准，该技术标准兼容性最佳。不仅桌面浏览器，包括手机浏览器甚至是手机QQ、手机微信都支持该直播协议。 但是该协议延时比较大，不太适合视频监控等对延时要求很敏感的行业。不过最近苹果公司新推出低延时hls直播标准，预计hls标准将抢占更大的市场份额。
以上直播技术标准目前都不完全契合视频监控行业的需求，如果要达到比较好的用户体验，通常以上技术混合使用。
3、视频直播
3.1 视频直播的现状和挑战
视频直播是近几年才兴起的产业，特别是随着游戏直播、手机直播的流行，视频直播已经司空见惯，进入了每个人的视野。 随着阿里、腾讯等云平台的入局，OBS，SRS等优秀软件的开源，视频加速CDN技术的成熟，打赏、广告等商业模式的落地，目前视频直播产业链已经非常成熟，业界也诞生了斗鱼、虎牙、映客、花椒等知名直播平台。
目前而言，这些直播平台使用的技术栈基本都是rtmp,但是由于flash技术即将被淘汰，所以直播行业也将迎来一些变局以及挑战。 现在，基本上所有的直播平台，在web端，都已经或正在往http-flv方案转型。由于flv与rtmp同出一门(都是Adobe公司产品)，负载格式一致，方案升级改造平滑可靠，http-flv替代rtmp具有天然的优势，相信将来http-flv能很好的挑起rtmp的大梁。
3.2 发展趋势
视频直播目前从内容上来讲，涵盖了游戏、美女、户外、娱乐、体育等直播；从设备上来讲，涵盖了PC、手机、web、电视等客户端，市场上也诞生了斗鱼这样的头部企业。从目前来看，视频直播行业市场格局已经比较稳固，进入了平稳发展期。
从技术上来讲，直播行业也将迎来一些变革。 一是rtmp技术随着flash的一起淘汰，web端rtmp播放器将成为历史。 二是随着webrtc的强势流行，直播技术栈可能与webrtc融合。 三是苹果主导的低延时hls的推出，可能最终有大一统之势。
不过近期来看，http-flv是rtmp的最佳替代方案，但是和rtmp一样，也有不支持H265的短板，而且移动端浏览器对此支持并不完善，所以该方案在将来有大概率会被其他方案替代。
3.3 技术难点
直播行业相对视频监控行业来说，商业化程度更高，更面向于普通消费者，用户规模更大，产业链也更加成熟。但是由于利益格局的划分、巨头间标准制定的角力，目前直播的技术标准和用户体验是割裂的。
在桌面web端，之前直播技术由Adobe旗下的flash/rtmp技术主导，不过由于Adobe的不作为，以及谷歌苹果等公司的抵制，flash已经进入死亡倒计时。目前来看，http-flv已经接手rtmp的大旗，成为了新的事实上的桌面web端直播标准。但是http-flv由于其不支持H265的短板(Adobe官方可能永远也不会支持H265)，其地位也并不稳固，现在也有公司正在尝试使用webrtc进行视频直播，但是由于该技术跨界太大，其技术栈又太庞杂，整个上下游产业链也并不完善，目前在直播界，还未看见大规模采用该直播技术的方案实施。
在手机APP端，由于播放技术自己可以主导，也由于历史沿革原因，目前一般沿用rtmp技术方案(需要指出的是微信小程序也支持rtmp播放器)，用户体验比较好，延时一般3秒或以下。
在移动web端，可采用的直播方案更少，目前基本只能采用苹果公司主导的hls方案，但是由于hls的技术特性，延时非常大(一般5秒以上，最大可达10秒以上)，其观看体验跟手机APP、桌面web端是严重割裂的。
通过我们上述的分析看出，目前直播技术方案，在每种端都不一样，用户体验也差距巨大，目前并没有一种多平台支持、令人满意的通用解决方案。目前要实现一个完善的直播产品，最少要采用包括rtmp/http-flv/hls这3种技术方案，而且这三种技术方案目前也并不能让人满意(rtmp/http-flv不支持H265,hls延时高)。
4、我们的解决方案以及优势
目前我们的流媒体服务框架支持rtsp/rtmp推流客户端，rtsp/rtmp/http-flv/ws-flv/hls播放客户端，并且可以无缝把rtsp/rtmp推流转换成上述4种播放协议，同时我们也支持mp4录制存档，必要的时候也可以从mp4文件加载成直播流。
除了上述功能之外，我们还支持拉流rtsp/rtmp代理成rtsp/rtmp/http-flv/ws-flv/hls，也支持把直播rtsp/rtmp流推送到其他的服务器。
另外，我们还提供丰富的http api 以及 http hook api，通过这些api，我们可以与其他业务服务器一起，打造丰富的业务逻辑。
我们的流媒体框架支持linux、macos、ios、android、windows全平台，既可以作为商用的流媒体服务器，也可以移植到嵌入式设备中，作为基础流媒体服务组件。
代码采用C++11标准打造，避免使用裸指针，稳定可靠，采用epoll多路复用、线程池、异步网络IO模式开发，并发性能优越，已经经受住了长期的高并发验证考验。同时针对及时推流的特征，做了特别的优化，可以减少视频打开延时、提高画面打开成功率，让用户获取画面秒开，延时极低的体验。
测试文档
使用教程
- 代码依赖与版权声明
- 快速开始
- vcpkg安装zlmediakit
- 服务器的启动与关闭
- GB28181教程
- 推流播放测试
- RESTful 接口
- RESTful 接口 postman自动生成
- Web Hook 接口
- 配置文件详解
- 播放URL规则
- 按需拉流
- 按需推流
- 播放鉴权
- 推流鉴权
- 怎样创建直播流
- webrtc编译与使用
- webrtc信令交互格式
- 怎么开启https相关功能
相关文档和资源
- zlmediakit独家特性
- zlmediakit的hls高性能之旅
- 高并发实现原理
- RTSP推流流程
- 流媒体相关技术介绍
- 直播延时的本质
- rtmp对H265/opus的支持
- ssl自签名证书测试
- 视频会议相关资源