本文聚焦 RTMP 协议的最精华的内容，接进行实际操作 Buffer 的练习和协议的学习。
RTMP 全称即是 Real-Time Messaging Protocol。顾名思义就是用来作为实时通信的一种协议。该协议是 Adobe 搞出来的。主要是用来传递音视频流的。它通过一种自定义的协议，来完成对指定直播流的播放和相关的操作。和现行的直播流相比，RTMP 主要的特点就是高效，这里，我就不多费口舌了。我们先来了解一下 RTMP 是如何进行握手的。
RTMP 是基于 TCP 三次握手之后的，所以，RTMP 不是和 TCP 一个 level 的。它本身是基于 TCP 的可靠性连接。RTMP 握手的方式如图：
它主要是通过两端的字段内容协商，来完成可信度认证的。基本过程如下：
整个过程如上图所述，但实际上有些细节需要注意。
此时，客户端处于等待状态。客户端有两个限制：
客户端在未接受到 S1 之前不能发送 C2 包
客户端在未接收到 S2 之前不能发送任何实际数据包
【2】 服务端在接受到 C0，发送 S0，S1 包。也可以等到接受到 C1 之后再一起发送，C1 包的等待不是必须的。
此时，服务端处于等待状态。服务端有两个限制：
服务端在未接受到 C1 之前不能发送 "},
connect 包发送的位置，主要是在 RTMP 握手结束之后。如下：
NetStream 里面的 Msg 有很多，但在直播流中，比较重要的只有 play 包。所以，这里我们着重介绍一下 play 包。
play 包主要是用来告诉 Server 正式播放音视频流。而且，由于 RTMP 天然是做多流分发的。如果遇到网络出现相应的波动，客户端可以根据网络条件多次调用 play 命令，来切换不同模式的流。
Stream Name[String]: 用来指定播放的视频流文件。因为，RTMP 天生是支持 FLV 的，所以针对 FLV 文件来说，并不需要加额外的标识，只需要写明文件名即可。比如:
不过，如果想要支持其它的文件，那么则需要额外的表示。当然，音频和视频需要不同的支持：
如果是播放音频文件，比如 mp3，那么则需要额外的前缀标识符-mp3。例如：mp3:f9。
如果涉及到视频文件的话，不仅需要前缀，还需要后缀。比如播放的是 MP4 文件，则标识为：mp4:f9.mp4。
-2: 如果是该标识符，服务端会首先寻找是否有对应的 liveStream。没有的话，就找 record_stream。如果还没有的，这次请求会暂时挂起，直到获取到下一次 live_stream。
=0: 相当于就是 seek video。它会直接找到 record_stream，并且根据该字段的值来确定播放开始时间。如果没有的话，则播放 list 中的下一个 video。
reset[Boolean]: 该字段没啥用，一般可以忽略。用来表示否是抛弃掉前面的 playlist。
整个 play 包内容就已经介绍完了。我们可以看看实际的 play 抓包结果：
那 play 包是在那个环节发送，发送完之后需不需要对应的 _result 包呢？
转载自 H5 直播流技术解析
想要阅读更多技术干货文章，欢迎关注网易云信博客。
了解网易云信，来自网易核心架构的通信与视频云服务。
网易云信（NeteaseYunXin）是集网易18年IM以及音视频技术打造的PaaS服务产品，来自网易核心技术架构的通信与视频云服务，稳定易用且功能全面，致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API，即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。
通常，摄像机H265视频编码在传输快、存储小、画质高等方面的优势使得其备受企业青睐，但是由于主流浏览器不能够支持这种格式，因此在浏览器下播放和解析视频都受到一定的约束。那么，如何实现 Web 视频播放的通用就成为了我们必须研究的课题。本期技术的真相将带你了解旷视盘古系统是如何解决 Web 视频播放通用方案这一难题的。
在视频智能分析领域，绝大部分摄像机视频码流均支持 H264 和 H265 两种编码格式，H265 视频编码相比 H264 有着诸多优点：视频数据传输带宽减半、存储减半、画质提升等。因此，在大部分智慧安全管理项目中， H265 视频编码使用较为广泛，能够直接减少用户项目成本。
但当下主流浏览器对 H265 视频编码格式仍然未能够支持，主要还是支持 H264 视频编码格式，随着 Flash 插件退出市场后，在 Chrome 浏览器下支持视频播放难度雪上加霜，所以大部分智慧安全管理厂家依然是在 IE 浏览器插件机制下支持着摄像机视频播放。
旷视在浏览器端视频播放也有诸多实践，旷视的盘古系统深耕智慧园区领域，在业内各项指标均遥遥领先，系统功能繁多，其中视频播放就是其必不可少的一部分，面向 ToB 市场，盘古平台系统自然需要适配用户各种使用场景，能够在不同浏览器中进行视频播放是基本要求。因此，在视频播放方面，我们需要研究一套通用的 Web
视频播放解决方案，来适配不同使用场景：高性能多路视频播放、强实时性视频播放等，并能够兼容不同的浏览器（IE / 360 / Chrome）。
盘古系统中视频数据来源
如上图所示，盘古系统中，视频数据来源各异、数据内容各异、甚至视频编码也各不相同，怎么样实现 PC 端跨浏览器进行 Web 视频播放，当前也有诸多方案，下面简易介绍下各个方案的实现关键点。
Web 前端收取到视频流后，进行 FMP4 封包，并使用 MSE 扩展 video 标签进行视频播放，对于智能帧（ Intelligence Frame 即结构化信息）采取透传方式，前端 Canvas 绘制。
即可实现浏览器视频播放，当前主流浏览器支持情况：
当前浏览器对MSE支持情况
WebAssembly 是一种新的编码方式，可以在现代的网络浏览器中运行，它是一种低级的类汇编语言，具有紧凑的二进制格式，并为其他语言提供一个编译目标，以便它们可以在 Web 上运行。它也被设计为可以与 JavaScript 共存，允许两者一起工作。近几年已经被各主流浏览器所广泛支持，支持情况：
前两方案基本是依靠 Web 前端实现视频播放，压力基本都在前端，播放路数受限，而此方案是需要部署一台服务器，进行视频码流的解码、编码、封装等动作，前端 Web 拿到 FMP4 视频数据后，依靠 MSE 扩展 video 标签的方式进行视频播放。
上述方案各有优缺点，如下：
那么我们依然面对以下问题：
-
如何面对服务器端资源紧张的情况下播放多路视频？
-
如何面对跨浏览器播放各种音视频编码视频数据？
-
如何面对端到端实时性要求高的使用场景？
三、Web 视频通用解决方案
我们经过大量分析讨论及预研，发现要解决这些问题的依然可行，在没有服务端资源情况下，我们只能将视频播放资源消耗前置，但考虑到浏览器对密集型数据计算并不擅长，我们决定在视频播放端使用后台程序，来实现视频封装、解码等动作。
在这个架构基础下，我们能够支持各种音视频编码格式，如 H264、H265、MJPEG、SVAC 等，同时，我们增加了多种模式来应对不同的使用场景。
3.1 适配兼容性好，实时性优先的视频播放需求：解码成 YUV + Web 前端 WebGL 显示
-
组件获取音视频码流，CPU 软解成视频帧 YUV 、音频帧 PCM ；
-
电脑环回地址 Websocket 数据传输，不受网络带宽限制；
-
前端视频帧 WebGL 渲染，音频帧 Audio 标签音频播放，支持各种浏览器；
-
通用性较强，支持各种音视频编码格式；
3.2 适配视频码流自适应、性能优先的视频播放需求
-
组件获取音视频码流，若视频码流是 H264 ，封装成 FMP4 ，音频码流解码成 PCM ；
-
Web 前端 H5 播放显示，利用浏览器硬解码能力，性能消耗较少；
-
通过判断视频码流格式，自适应输出不同视频数据给前端，来达到综合性能消耗最低，支持路数更多的效果，支持各种浏览器。
3.3 适配高分辨率、多路数的视频播放需求
-
在 IE 引擎下，Web 前端可以加载组件中 OCX 控件，控件获取音视频码流；
-
GPU 解码显示能力较好，使端到端播放延迟能够在 200ms 以内；
总结：当然每个视频播放方案各有实际的使用场景及约束条件，在浏览器尚未支持 H265 等视频编码格式前，每个方案实现起来都有其对应的代价，怎么样实现 Web 视频播放并满足各自项目需求应该是百花齐放，各有略同。
