目前在网页上播放大华摄像头视频，有如下2种途径： 1）首选获取摄像头的hls协议地址，H5可直接播放 2）获取摄像头rtsp协议地址，用ffmpeg转换成hls再播放

近期做的一个项目，需要在WEB端接入大华摄像头视频。我发现，摄像视频、短信，是我们这种低技术含量应用程序永恒的主题。能够看到视频，发出一条短信，给人感觉就很好，好神奇哟的样子。网页直接播放视频，最省事就是安装摄像头厂商的插件。但这好像是IE时代的老黄历了。目前播放视频流，一般是基于rtmp协议或hls协议。

依我看，首选是hls，因为兼容性好，html5支持，并且网页直接与摄像头平台相连，节省资源，缺点是有延迟。而rtmp实时性好，但它是Adobe公司的私家货，需要flash。众所周知，flash已经逐级不被主流浏览器所支持。之前国内也有个高手写了一个flv.js，可以在网页上无须通过flash而直接播放rtmp，但有限制，只支持H.264编码的视频流，目前普遍是更高效H.265就不行了（html5播放flv）；并且需要自己提供服务器进行转码，既占带宽又消耗资源，而且这个服务器还不好弄。

但好死不死，该项目面对的大华摄像头系统已经有点年头了，没有提供hls协议地址。这意味着只能走取流-转码-播放的路线。这个rtsp协议地址，既可以直接连接设备获取，也可以通过平台访问获取。不管哪种方式，都是一个rtsp地址，都要转码，网页才能播放。

1、获取rtsp地址 这个rtsp地址分为直接连接设备和通过平台访问2种，地址格式不一样：

1）直接连接设备

主码流为0（即subtype=0），辅码流为1（即subtype=1）。默认端口是554，如果是默认端口，可以不写端口。不过实际情况下，可能设置成了别的端口。

2）通过平台访问 格式示例1（平台本级摄像头）：

端口：默认9090端口。 设备编号：平台上设备编号，例如1000004 通道号：设备下通道，从0（通道一）开始。 %40 是域标识符号@的转义符， %24 是$的转义符 码流类型：1代表主码流，2代表辅码流

仅支持大华设备、H264码流。

2、用ffmpeg拉流和转码，转成hls格式文件，输出到指定目录 以上3个步骤放在一个java程序里完成，名曰 视频流转码服务器。视频流转码服务器提供前端访问接口，当接收到前端播放请求，即调用ffmpeg拉流、转码、输出。每个rtsp设置一个计数器，当一个rtsp地址无人播放，即停止该地址的转码。

通常，ffmpeg的参数如下：

应当将rtsp流地址作为参数传递。按照大华官方教程，如果是通过平台访问，可以通过java的接口DPSDK_GetRealStream ，通过设置参数trackID 为 501 获取ps 码流，然后通过ffmpeg等工具将码流转成rtmp等可以在浏览器播放的格式。但从字眼看，DPSDK_GetRealStream返回的已经是视频流（而不是一个RTSP地址），那么它如何传给ffmpeg？这点没有仔细看，暂时不得而知。

3、nginx配置该目录为web虚拟目录

4、网页前端播放该虚拟目录下的hls文件

ffmpeg是一个第三方的工具，需要预先装在服务器上，然后自己写的java后台程序去调用。ffmpeg在运行过程中，万一崩溃，如何检测并重启？

第二个问题是，我们这个java后台程序，根据每个摄像头地址的请求来转码。没有人请求，则停止对该摄像头视频流的转码。然则每个摄像头都维持了一个计数器，如果因为一些未知的原因，前端已经退出了，但服务器这里不知道，继续转码，造成资源浪费。

应该还有别的许多问题。如果没有投入相当的精力资源，那么本解决方案只是一个玩具。

2021.09.14 实际上，看上去不会出现前端断线，或意外退出，而后台浑然不觉，仍然在卖力转码的情况。经测试，不管是网页正常关闭，还是中止浏览器进程而崩溃，服务器端会很快指导。究其原因，可能是因为网页前端采用了WebSocket与服务器端连接的缘故。WebSocket是长连接，连接一旦建立，就会长久保持。如果前端断开，后端自然就知道了。

参考文章： 光电视频流在html5中展示

RTSP（Real Time Streaming Protocol），实时流传输协议 是由Real Network和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，RTSP的作用相当于流媒体服务器的远程控制。服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。 RTMP（Routing Table Maintenance Protocol）路由选择表维护协议 该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。RTMP与HTTP一样，都属于TCP/IP四层模型的应用层。

HLS（HTTP Live Streaming）HTTP实时流媒体 是Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u(8)的索引文件，TS媒体分片文件和key加密串文件。常用的流媒体协议主要有 HTTP 渐进下载和基于 RTSP/RTP 的实时流媒体协议，这二种基本是完全不同的东西，目前比较方便又好用的是用 HTTP 渐进下载方法。HLS 是这方面的代表。但由于因为客户端播放的是最新切割的ts文件，它的延迟取决于切片的大小，所以有延迟。

国标协议GB28181 GB28181协议指的是国家标准GB/T 28181—2016《公共安全视频监控联网系统信息传输、交换、控制技术要求》，该标准规定了公共安全视频监控联网系统的互联结构， 传输、交换、控制的基本要求和安全性要求， 以及控制、传输流程和协议接口等技术要求，是视频监控领域的国家标准。

GB28181是在国际通用标准的基础之上进行了私有化定制以满足视频监控联网系统互联传输的标准化需求。

在GB28181协议中，联网系统在进行视音频传输及控制时应建立两个传输通道: 会话通道和媒体流通道。会话通道用于在设备之间建立会话并传输系统控制命令; 媒体流通道用于传输视音频数据， 经过压缩编码的视音频流采用流媒体协议RTP/RTCP传输。如图所示 参考文章： 技术解码 | GB28181协议简介及实践

RTP 实时传输协议（Real-time Transport Protocol或简写RTP）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。 … RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。

RTP代表了一种新型协议，它遵循Application level framing 和 Integrated layer processing。即RTP可以比较容易的拓展以传递某些特定需要的内容，而且可以比较容易地集成进某个应用，而不是作为一个独立的补充层。RTP协议被故意地设计成不完整的协议框架。

GB28181国标协议规定了流的输出格式为 RTP + PS 。GB28181协议中规定了两种方式传输媒体流，一种是将音视频数据打包成MPEG2-PS流然后再通过RTP协议传输，另外一种是直接使用RTP传输裸的音视频流，在实际应用中主要以第一种方式为主。

流媒体传输协议之RTP

PS ps全名MPEG-PS

据传输媒体的质量不同，MPEG-2中定义了两种复合信息流：传送流（TS：TransportStream）和节目流（PS：ProgramStream） TS流与PS流的区别在于TS流的包结构是固定长度的，而PS流的包结构是可变长度的。

PS包与TS包在结构上的这种差异，导致了它们对传输误码具有不同的抵抗能力，因而应用的环境也有所不同。TS码流由于采用了固定长度的包结构，当传输误码破坏了某一TS包的同步信息时，接收机可在固定的位置检测它后面包中的同步信息，从而恢复同步，避免了信息丢失。而PS包由于长度是变化的，一旦某一PS包的同步信息丢失，接收机无法确定下一包的同步位置，就会造成失步，导致严重的信息丢失。因此，在信道环境较为恶劣，传输误码较高时，一般采用TS码流；而在信道环境较好，传输误码较低时，一般采用PS码流。由于TS码流具有较强的抵抗传输误码的能力，因此目前在传输媒体中进行传输的MPEG-2码流基本上都采用了TS码流的包格式。

MPEG2-PS主要应用于存储的具有固定时长的节目，如DVD电影，而MPEG-TS则主要应用于实时传送的节目，比如实时广播的电视节目。这两种格式的主要区别是什么呢？你将DVD上的VOB文件的前面一截剪掉（或者干脆就是数据损坏），那么就会导致整个文件无法解码，而电视节目是你任何时候打开电视机都能解码（收看）的，所以，MPEG2-TS格式的特点就是要求从视频流的任一片段开始都是可以独立解码的。PS主要用于播放或编辑系统， TS主要用于数据传输。

(既然如此，为啥GB28181还要使用PS？)

参考文章： MPEG-PS封装格式

2023.05.12 近期接触了一下视频国标以及一个应用了视频国标的媒体平台，里面实现了使用了web对摄像头的接入和播放。视频国标GB28181及一个相关平台的应用