昨晚公开课程的课题:【HTML5开发流媒体视频在线直播系统】
而这项技术现在应用的也很广泛,比如现在一些证券公司流行的在线开户验证系统,还有现在很火的直播平台,而在以后随着HTML5的应用比重慢慢增大,这些最新潮的技术也会随之火热,当然学会这些技术对于找工作来说的帮助还是很大的。
需要昨晚的HTML5开发流媒体视频在线直播系统视频的请点击关注查看置顶文章哦!
在线直播效果图
Content 】
第一篇章 流媒体原理
1.1 流媒体概念
1.2 流式传输特点
1.3 流媒体系统构成
1.4 流媒体涉及技术
1.5 流媒体应用
1.6 国内外大型流媒体系统
1.7 总结
流媒体相关术语
第二篇章 流媒体系统
2.1 编码工具
2.2 流媒体服务器
2.3 CDN分发网络
2.4 网络协议
2.5 播放器
总结:从一个直播APP看流媒体系统的应用
一套大规模的流媒体系统,由编码工具负责对音视频文件编码压缩(h.264/h.265/VP9/AAC等);由流媒体服务器负责对数据包进行容器封装(flv/ts等)以及负责网络协议打包(RTMP/HTTP等);由CDN网络进行全网分发;由播放层负责对图像进行解码显示(FLASH/VLS/VIDEO JS等)。流媒体系统所需的核心组件包括:
(1)编码工具:用于流媒体文件生成的编码工具
(2)流媒体服务器:用于控制、传送流媒体数据的流媒体服务器
(3)CDN网络:用于支撑流媒体的全网分发网络
(4)网络协议:用于支持特定的流式传输的网络协议
(5)播放器:各操作平台用于显示流式数据的播放器
本篇内容将对上述5个环节做一个整体性论述,由于本系列分享着重讨论流媒体传输分发,所以在后续文章不会再讲编码和播放两个端上的环节。本篇对编码和播放将稍微展开讨论,其它3个环节只简单提及,后续将分章详细讨论。本篇最后将给出一个实例,让大家能直观的看出一个完整的流媒体系统各环节是如何运用到直播系统中。
2.2 流媒体服务器
流媒体服务器简单来说就是直接向客户端响应流式连接(如RTMP/RTSP等),返回流媒体数据(打包在RTMP等流式协议中的flv/ts等数据)的服务器程序。流媒体服务器直接承担流媒体数据的输出,是整个流媒体系统的核心,它的功能、性能、运行支撑能力直接决定了一个大型流媒体系统的健壮程度。
和编码器一样,一套工业级的流媒体服务器所包含的内容是相当复杂的,不过当下市面上也有不少优秀的商用或开源的流媒体Server。我们在搭建流媒体平台时大可以直接按需选择其中一款即可。这俩面需要了解的,一是流媒体服务器是干什么的,二是目前市面流媒体服务器有哪些,三是选择一款流媒体服务器需要衡量哪些方面。
(1)流媒体服务器原理
通俗一点来讲,流媒体服务器就是能够传输RTMP/RTSP等实时流式协议的服务端程序,流媒体服务器接收媒体数据后,对媒体数据进行容器封装(flv/ts等)和流式协议打包(RTMP/HTTP等),然后直接将这些流式数据返回给客户端。
下图给出了用户在请求流媒体数据的过程:
1)观看者通过交互界面先请求web server;
2)webserver将这些RTMP等流式连接转到流媒体服务器;
3)流媒体服务将对应的实时媒体数据通过RTMP等协议传送给观看者的Player。
下图以RTSP流式协议为例给出了流媒体服务器最简单的功能原理:
我们从图中可以看出,RTMP/RTSP等实时流式协议都是基于TCP协议,所以流媒体服务器本质上来说就是个TCP服务器,跟所有的TCP服务器都有类似的逻辑结构。上图中:RTP协议主要用来实际承载实时传送的流媒体数据,包括音视频数据,以及所携带负载的时间戳,顺序号等。
RTCP主要完成接收者收到某个多媒体流的服务质量信息Qos,用于对服务器端的反馈。
RTSP(Real Time Streaming Protocol)是一种控制协议,完成对RTP中的流媒体数据进行各种状态的控制。主要包括如播放、暂停、快进、录制、结束播放等控制功能,也就是RTSP对多媒体服务器实施网络远程控制。
下图以RTMP流式协议给出了流媒体服务器与Flash Player之间完整的交互过程:
通过以上6步,流媒体服务器就将媒体数据实时的源源不断的传送给Player,知道Player点击停止按钮为止。
以上就是流媒体服务器最基本的流式数据传输功能和原理,但事实上,一套实际直播平台或者直播CDN分发系统中的流媒体服务器所承担的功能远比这个复杂。以观止云BMS为例,下图是BMS的架构图,从图中我们可以看出BMS在强大的输入输出支持以外,还有大量计费、监控、调度等涉及运营的BASIC接口,另外还有动态配置、实时截图、安全特性、大数据等大量伴生进程和子系统。
(2)主流流媒体服务器对比一览
目前市面上商用和开源的流媒体服务器比较多,此处只给出比较常用和主流的流媒体服务器列表,表格后面的维基百科链接中有20多款产品的全方位总结。
常用的商用流媒体服务器:
常用的开源流媒体服务器:
流媒体服务器对比一览,涵盖了基本信息、操作平台、协议、格式等方面的详细比较,Comparison of streaming media systems :https://en.wikipedia.org/wiki/Comparison_of_streaming_media_systems
(3)衡量一款流媒体服务器的指标
由于当下流媒体应用尤其互联网直播要求极高,如何从数十款流媒体服务器中选择出适合自身流媒体平台,或者自主研发需要注意哪些点。小编认为一款优秀的流媒体服务器需要具备:
功能支持:包括支持的协议、封装格式、直播/点播/延播/截图等应用功能等,倒不是说功能越多越好,每款服务器有自身定位,我们需要的是在特定场景下功能表现的优秀;
性能支持:主要看承载能力和稳定性,针对目前直播量级越来越大,单机承载量当然是越大越好。上述众多的流媒体服务器中,就单进程来说大致的性能表现是BMS > SRS > Nginx-rtmp > Crtmpd > Wowza > fms > RED5;
配置运维:尤其是网络直播是经常出问题的应用,流媒体服务器对运维工作的友好型也是大型直播平台或CDN中非常重要的。比如节点扩容,程序更新,日常业务配置等等。服务器配置方式越简单,运维越轻松越不容易出错;
服务器日志:日志是定位故障分析问题的唯一途径,所以优秀的、运营级的流媒体服务器需要日志的可读性和友好性。
观止云以往文章中详细分析了主流流媒体服务器之间在协议支持、体系架构、核心功能支持、配置运维、性能、服务器日志、大数据这七大维度的横向对比。
2.3 CDN分发网络
CDN(Content Delivery Network),即内容分发网络。简单来说CDN网络是在各地建设边缘节点,将源站的内容分发到距离用户最近的网络边缘节点上,使得用户可以就近获取所需内容,以此来解决 Internet用网高峰期拥挤的状况和跨网络运营商响应慢的问题,整体上提升了用户访问网站的响应速度。典型的CDN架构如下:
CDN最初是建立在文件(图文、文件)静态内容的基础上的,所以其核心的技术点在于WEB Cache缓存技术、集群技术、负载均衡/DNS调度等技术。随着互联网的发展,CDN后来出现了动态内容加速、流媒体加速、应用协议加速等类型,还补充了安全、数据分析等等增值服务,最新的动向可能是白山云提出的API加速了。
流媒体CDN加速网络,点播应用中,国内大部分视频网站均走文件分发方式,依然跑在Nginx设备上面,所以我们可以说和流媒体关系还不那么大。直播分发系统中,最主要的区别是它需要靠专门的流媒体服务器来分发,而且流媒体服务器的能力直接影响了CDN加速效果,另外,直播CDN一般不Cache内容,也无法预加载内容。但是,直播CDN的组网和调度基本思路还是大同小异,用户访问的流程也基本相同:
1)主播推送流媒体数据到流媒体服务器(源站) ,目前的直播应用一般还有上行加速过程,即主播先推送到最近的节点,节点再转推到源站;
2)源站进行流媒体数据的分发;
3)观众点开播放器播放某直播流,经过域名解析后向CDN请求流媒体数据;
4)CDN经过调度将该请求分配给离该观众最近的边缘节点,若节点上没有该直播流存在,则节点向源站继续请求流媒体数据;若节点上已有了该直播流,则直接响应流数据;
5)源站响应节点的请求,将流数据分发给该边缘节点;
6)边缘节点将流媒体数据传送给该观众的播放器。
2.4 网络协议
网络协议指的是为了让互联网中客户端与服务端之间,客户端与客户端之间进行数据交换而建立的一系列规则、标准等的集合,我们天天上网打交道的就是TCP/IP协议了,它是当下Internet上的“通用语言”,就好比我们中国人交流的普通话一样。
流媒体是在互联网上传输的特殊数据,需要有特定的规则和标准和承载,这就是我们要着重说的流媒体网络协议,形式上,它好比是暗号,虽然也是用普通话表述,但不是提前知道暗号的人,就不会明白它在说什么。
流媒体协议也是流媒体系统中非常重要的组成部分,后续文章会对主要的流媒体协议进行一一详述,此节仅进行流媒体协议的概述。
目前网络直播应用的三大主要网络协议是RTMP、HTTP-FLV、HLS,其它还有类似HLS的HDS/DASH、监控领域的RTSP,目前比较活跃的WebRTC、以及很多基于UDP的平台内的私有协议。WebRTC和UDP私有协议第三方CDN都不容易支持,所以不作过多讨论。
上述协议中,每个协议都有其自身特点和针对性,我们需要视自身业务特点进行选取。总结起来,对协议可以进行如下选择:
编码工具最好都输出RTMP
流媒体服务器接入使用RTMP
流媒体系统内部全部使用RTMP
PC+直播+实时性要求高:使用RTMP,播放器使用Flash
PC+点播:使用HTTP文件分发或者HLS
IOS/ Andorid+直播+实时性要求高:都使用HTTP-FLV,播放器自己搞定
IOS/ Andorid+直播+实时性要求低:都使用HLS
和流媒体协议相关的还有一个概念是媒体封装格式,就是我们天天所说的FLV/MP4/AVI/3GP等等音视频文件格式,一般后缀在文件名尾部,RTMP这些流协议打包的数据就是已经封装成FLV/TS这样的封装数据。以下维基百科词条给出了数十种封装格式的详细对比,各自的音视频编码参数等等。
Comparison of video container formats:https://en.wikipedia.org/wiki/Comparison_of_video_container_formats
2.5 播放器
流媒体播放器实现的功能和流程与之前讲的编码工具刚好相反,历经解协议,解封装,解码视音频,视音频同步几个主干环节。
上述每一个步骤的具体作用跟编码端是一样的,不再赘述。在播放端中,PC端用Flash就足够了,移动端可以基于ijkplayer这样的开源跨平台播放器去开发,关键点在于对移动端不同型号、网络切换、播放中来电话、应用转入后台运行等等事件下进行针对性处理以及CPU解码和GPU解码之间的平衡。另外,首屏加载时间和延迟优化在播放端也大有文章可做,比如通过缓存最近一个GOP减少播放器数据下载量快速启动解码以提升首屏时间,合理的缓冲策略、追帧播放等来提升延时等。
除了尽可能优化播放体验之外,由于播放端直接面向用户,所以运营方面所可能涉及到的如广告投放、观看行为搜集等,都需要在播放端考虑。
针对HLS协议,video.js 和hls.js是两个基于JavaScript的开源库,能在HTML5 中播放HLS,Safari、IE11以上、Firefox、chrome等支持H5的浏览器均可直接调用video.js实现HLS的播放。
flv.js 是一款由B站开源的,原生JavaScript开发的,能在HTML5 中直接播放FLV格式的h.264/aac流媒体,兼容Safari、IE11以上、Firefox、chrome等。
以下维基百科词条给出了几十种播放器(商用的、开源的),数十项功能与性能的详细对比:
Comparison of video player software:
https://en.wikipedia.org/wiki/Comparison_of_video_player_software
更多精彩内容,持续推送中,敬请关注!
本篇内容由观止云原创,未经许可,禁止转载。
更多干货,尽在“观止云”微信订阅号(微信号bravovcloud)
我们将了解以下流协议,以便:
RTMP 流媒体协议是 Macromedia 开发的一种基于 TCP 的技术,用于在 Flash 播放器和服务器之间通过互联网进行音频、视频和数据的流媒体传输。Macromedia 于2005年12月3日被竞争对手 Adobe 收购,但随着 Flash 在2020年逐步淘汰,它的使用越来越少地与面向观众的内容交付有关,而更多地是通过支持 RTMP 的编码器将实时流摄入到平台中。
RTSP 建立并控制单个或多个时间同步的连续媒体流,如音频和视频。RTSP 本身通常不提供连续的流,尽管可以将连续的媒体流与控制流交织在一起。换句话说,RTSP 充当多媒体服务器的“网络远程控制”。
由于大多数 IP 摄像头仍然支持 RTSP,它仍然是监控和闭路电视系统中使用的标准。
WebRTC 代表 Web 实时通信,它是一个非常令人兴奋的、强大的、具有高度破坏性的尖端技术和流协议。
它与 HTML5兼容,你可以使用它直接在浏览器和设备之间添加实时媒体通信。另外,你可以做到这一点,而不需要在浏览器中安装任何必备的插件。它正逐渐得到所有主要的现代浏览器供应商的支持,包括 Safari、 Google Chrome、 Firefox、 Opera 和其他浏览器。
感谢 WebRTC 视频流技术,您可以直接将实时视频嵌入到基于浏览器的解决方案中,为您的受众创建一个迷人的互动流体验,而不用担心延迟。
HLS 是一种基于 HTTP 的自适应协议,用于将视频和音频数据/内容从媒体服务器传输到终端用户的设备。
合肥光源于2009年由苹果公司创建。苹果发布 HLS 的时间与传奇设备 iPhone3差不多。早期的 iPhone3有直播播放问题,苹果希望通过 HLS 解决这个问题。
SRT 是一种开源技术,用于在不可预测的公共网络上进行可靠且低延迟的流媒体传输。它直接与 RTMP 和 RTSP 竞争,作为第一英里的解决方案,但仍被采用作为编码器,解码器和播放器添加支持。SRT 在2020年的一个互动用例被证明是第一个虚拟 NFL 草案ーー确保高质量的流媒体和在任何有互联网连接的地方的操作灵活性。
CMAF 是一种简化基于 HTTP 的流媒体交付的新格式。它是一个新兴的标准,有助于降低成本和复杂性,并提供大约3-5秒的延迟流。CMAF 可用于 DASH 或 HLS。
由于 RTMP 的地位不断下降,其他基于 HTTP (超文本传输协议)的自适性串流技术也应运而生。但是,不同的流标准需要不同的文件容器。例如,当 MPEG-DASH 使用。MP4集装箱,HLS 流交付在。其格式。
因此,每个想要接触更多观众的广播公司都必须对同一个视频文件进行两次编码和存储,因为加密创建了完全不同的文件组。
这两个版本的同一个视频流应提前或立即进行。这两个过程都需要额外的存储和处理成本。
苹果和微软建议移动图片专家组创建一个新的统一标准,称为通用媒体应用格式(CMAF) ,以降低在线视频传输的复杂性。
*请认真填写需求信息,我们会在24小时内与您取得联系。