WEB页面播放大华摄像头视频解决方案

今天药忘吃喽~ 2022-09-11 01:23 2093阅读 0赞

*目前在网页上播放大华摄像头视频，有如下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][html5_flv]）；并且需要自己提供服务器进行转码，既占带宽又消耗资源，而且这个服务器还不好弄。

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

## 二、具体原理 ##

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

**1）直接连接设备**

rtsp://{ $账号}:{ $密码}@{ $摄像头IP地址}:{ $端口}/cam/realmonitor?channel={ $通道}&subtype={ 流方式}

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

示例：  rtsp://admin:admin@192.168.0.108:554/cam/realmonitor?channel=5&subtype=0

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

rtsp://平台IP:端口/dss/monitor/params?cameraid=设备编号%24通道号&substream=码流类型

例：rtsp://20.2.42.185:9090/dss/monitor/params?cameraid=1000004%243&substream=1

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

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

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

通常，ffmpeg的参数如下：

ffmpeg -rtsp_transport tcp -i "rtsp://user1:password@192.168.0.98:554/cam/realmonitor?channel=1&subtype=0" -c copy -f hls -hls_time 2.0 -hls_list_size 0 -hls_wrap 15 D:/soft/nginx/html/hls3/test.m3u8

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

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

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

## 三、效果 ##

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bem55u05ouz_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bem55u05ouz_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]

## 四、难点 ##

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

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

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

--------------------

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

--------------------

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

## 五、附录 ##

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bem55u05ouz_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 2]

**RTSP（Real Time Streaming Protocol），实时流传输协议**  
是由Real Network和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，RTSP的作用相当于流媒体服务器的远程控制。服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bem55u05ouz_size_16_color_FFFFFF_t_70_g_se_x_16_pic_center]  
**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文件，它的延迟取决于切片的大小，所以有延迟。

[html5_flv]: https://blog.csdn.net/leftfist/article/details/112378447
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bem55u05ouz_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220829/ff5b509ab8fd4bf49af182cea1f11c3e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bem55u05ouz_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]: /images/20220829/f56fb4e5e6ea4878b8257e990982dd70.png
[html5]: https://blog.csdn.net/leftfist/article/details/86699371
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bem55u05ouz_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 2]: /images/20220829/bf6207b558564b48ba431c44a64e2bad.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bem55u05ouz_size_16_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220829/f2065804aaf641c7a21c0e40d32e1089.png