干货！常用的视频流协议科普，一文 Get！

在我们日常生活中会经常接触到视频流，比如查看监控、出入小区或者进公司时候的人脸检测、观看影视剧和跟着各大平台的主播抢货健身等等……本期文章将为大家科普一下关于视频流的知识。

ONVIF 规范和常见视频流传输协议

ONVIF 规范

随着视频监控产业链的成熟，市面上陆陆续续出现了各式各样的网络摄像设备，这些设备都需要通讯协议才能进行数据传输。早期厂商都采用私有协议，但是现在厂商分工明确，有的负责生产制造摄像头，有的负责开发视频服务器，有的负责方案集成并销售，私有协议存在严重的兼容问题。类似于 HTTP 协议对浏览器和服务器之间通信的规范，网络摄像头的接口也出现了标准化，其中 ONVIF 支持厂商的数目、厂商的知名度和市场占有率遥遥领先。

ONVIF 规范描述了网络视频的模型、接口、数据类型以及数据交互的模式，并复用了一些现有的标准，如 WS 系列标准等，目标是实现一个网络视频框架协议，使不同厂商所生产的网络视频产品（包括摄录前端、录像设备等）完全互通。ONVIF 规范中设备管理和控制部分所定义的接口均以 Web Services 的形式提供。ONVIF 规范涵盖了完全的 XML 及 WSDL 的定义。每一个支持 ONVIF 规范的终端设备均须提供与功能相应的 Web Service。服务端与客户端的简单数据交互采用 SOAP 协议，音视频流则通过 RTP / RTSP 进行 。

视频流传输协议

HTTP-FLV / WS-FLV

HTTP 协议中有个 Content-Length 字段，代表 HTTP 的 Body 部分的长度。服务器回复 HTTP 请求的时候如果有这个字段，客户端就接收这个长度的数据然后就认为数据传输完成了，如果服务器回复 HTTP 请求中没有这个字段，客户端就一直接收数据，直到服务器跟客户端的 socket 连接断开。要流式传输 flv 文件，服务器是不可能预先知道内容大小的，这时就可以使用 Transfer-Encoding: chunked 模式来连续分块传输数据。因为HTTP-FLV 基于 HTTP / 80 端口传输，HTTP-FLV 能够穿透防火墙，避免被防火墙拦截。除此之外，它可以通过 HTTP 302 跳转灵活调度、负载均衡，同时支持使用 HTTPS 加密传输。WS-FLV 和 HTTP-FLV 类似，区别就是 HTTP-FLV 基于 HTTP ，只能单向传输数据，而 WS-FLV 基于 WS 可以双向传输数据。

RTMP

RTMP 是 Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。由 Macromedia 开发的一套视频直播协议，现在属于 Adobe。因为 RTMP 是通过互联网在 Flash 播放器与一个服务器之间传输流媒体音频、视频和数据而开发的一个专有协议，早期的网页想要直播需要 Flash 播放器，所以 RTMP 协议是最好的选择，互联网公司也在此协议上有了不少的技术积累，国内的 CDN 对 RTMP 做过优化。随着 HTML5 的普及和 Flash 的停止更新，理论上会被其他协议取代，但是由于类似 flv.js 库的出现，使得在 HTML5 网页同样可以播放 flv 格式的视频，所以 RTMP 依然是当前视频直播的主流协议。

HLS

HLS 是 HTTP Live Streaming 的首字母缩写，是由苹果公司提出基于HTTP 的流媒体网络传输协议，可实现流媒体的直播和点播，主要应用在 iOS 系统，为 iOS 设备(如 iPhone、iPad)提供音视频直播和点播方案。HLS 协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件( MPEG-TS 格式)，而客户端则不断的下载并播放这些小文件， 因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。

iOS 和 Android 都天然支持这种协议，配置简单，直接使用 video 标签即可。这是一种以点播的方式实现的直播，且分段文件的时长很短，因为客户端可以比较快速的切换码率，用于适应不同的宽带条件。但是由于这种技术特性，导致它的延迟会高于普通的流媒体直播协议。磁盘存储和处理 HLS 协议产生的大量小文件，会影响服务端的响应速度，且损耗磁盘的正常寿命。

RTSP

RTSP（Real Time Streaming Protocol）是由 Real Network 和 Netscape 共同提出的如何有效地在 IP 网络上传输流媒体数据的应用层协议。和基于 HTTP 协议的流媒体网络传输协议不同，RTSP 是双向通信的，客户端和服务端都可以主动发起请求。RTSP 对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，RTSP 的作用相当于流媒体服务器的远程控制。服务器端可以自行选择使用 TCP 或 UDP 来传送串流内容，它的语法和运作跟 HTTP 1.1 类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而且允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，还可以支持多方视频会议（Video Conference）。

DASH

DASH（Dynamic Adaptive Streaming over HTTP）全称为“基于 HTTP 的动态自适应流”，是一种自适应比特率流技术，使高质量流媒体可以通过传统的 HTTP 网络服务器以互联网传递。类似苹果公司的 HTTP Live Streaming（HLS）方案，DASH 会将内容分解成一系列小型的基于 HTTP 的文件片段，每个片段包含很短长度的可播放内容，而内容总长度可能长达数小时（例如电影或体育赛事直播）。内容将被制成多种比特率的备选片段，以提供多种比特率的版本供选用。当内容被客户端回放时，客户端将根据当前网络条件自动选择下载和播放哪一个备选方案。客户端将选择可及时下载的最高比特率片段进行播放，从而避免播放卡顿或重新缓冲事件。也因如此，客户端可以无缝适应不断变化的网络条件并提供高质量的播放体验，拥有更少的卡顿与重新缓冲发生率。

推流和拉流

推流：将直播的内容推送至服务器的过程，其实就是将现场的视频信号传到网络的过程。“推流”对网络要求比较高，如果网络不稳定，直播效果就会很差，观众观看直播时就会发生卡顿等现象，观看体验很是糟糕。要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有 RTSP、RTMP、HLS 等，使用 RTMP 传输的延时通常在 1–3 秒，对于手机直播这种实时性要求非常高的场景，RTMP 也成为手机直播中最常用的流传输协议。最后通过一定的 QoS 算法将音视频流数据推送到网络端，并通过 CDN 进行分发。

拉流：指服务器已有直播内容，用指定地址进行拉取的过程。即是指服务器里面有流媒体视频文件，这些视频文件根据不同的网络协议类型（如 RTMP、RTSP、HTTP 等）被读取的过程，称之为拉流，我们日常观看视频和直播就是一个拉流的过程。

EdgerOS 对流媒体的支持

在日常生活场景中，如刷脸的门禁、无人的车库和物品识别等，都会用到视频流，EdgerOS 也能开发者提供了 MediaDecoder，WebMedia 两个模块，使得在开发的过程中可以简单方便地将视频流推送给前端。MediaDecoder 负责将设备推过来的实时音视频流解码并转为指定格式（视频宽高、帧率、像素）的目标视频。同时使用 WebMedia 可以创建一个流媒体的服务，这个服务支持双传输通道，stream 通道支持 http-flv 和 ws-flv 协议，用于传输视频流；data 通道支持 WS 协议，这样客户端和服务端直接可以相互发送简单的控制指令。客户端通过 stream 通道接收视频流，使用 flv.js 等开源库在网页上实现实时直播的功能。

智能场景

人工智能逐渐进入我们的生活，同时人工智能系统的开发和应用为人类创造了巨大的经济效益，政府、公司、企业都开始在某些领域成功地应用相关技术。EdgerOS 内置了视频处理和人工智能模块，通过这些内置模块的组合，开发者能够搭建出适用于不同应用场景和计算任务的爱智应用。比如使用 FaceNN 可以处理 Mediadecoder 解码生成的目标视频流，较为准确地完成人脸侦测和人脸识别任务，其大致流程如下：

视频流处理依然是当今科研和技术研发的热门主题。更进一步地，使用人工智能处理这些视频流，让机器或设备完成以往需要人类执行的重复性任务，可以减少人为错误和降低成本。希望这篇文章能够让您对常用的视频流传输协议有一个初步的理解，并在后续的开发过程中帮助您快速构建一个视频流处理应用。