Hi3516cv610的安防摄像头实操

简介

本文基于 HI3516CV610 + i.MX6ULL + 阿里云 MediaMTX 搭建一套安防摄像头视频转发方案。整体思路是：HI3516CV610 负责本地图像采集和 H.264 编码，i.MX6ULL 作为边缘网关从局域网拉取 RTSP 视频流，并通过 GStreamer 主动推送到阿里云服务器，最后由 MediaMTX 将视频流发布成公网可访问的 RTSP 地址。

本文将从 架构层面、边缘网关层面、云服务器层面 三个角度，介绍该安防摄像头方案的设计思路、数据链路以及各模块之间的分工。

一、架构层面

在本方案中，HI3516CV610 作为摄像头主控芯片，主要负责图像采集、视频编码，并在局域网内提供 RTSP 视频流，例如：

rtsp://192.168.1.88:554/test.264

普通安防摄像头一般部署在局域网中，只拥有 192.168.x.x 这类私网 IP，不会直接暴露到公网。如果直接把摄像头的 RTSP 端口映射到公网，虽然可以远程访问，但会带来较大的安全风险，例如端口扫描、弱密码攻击和非法访问等。

因此，本方案引入 i.MX6ULL 作为边缘网关。i.MX6ULL 与 HI3516 摄像头处于同一局域网内，可以拉取摄像头的 RTSP 视频流；同时，i.MX6ULL 又可以通过以太网、WiFi 或 4G 连接公网服务器，并主动将视频流推送到阿里云。这样设计的好处是：

1. HI3516 摄像头不需要直接暴露公网；
2. 摄像头只负责采集和编码，系统结构更清晰；
3. i.MX6ULL 负责公网转发，便于统一管理；
4. 阿里云服务器作为公网入口，方便 PC/VLC 访问；
5. 后续可以在云端扩展鉴权、日志、转发、多路视频管理等功能。

因此，整个方案的核心思路是：HI3516CV610 负责本地视频采集与编码，i.MX6ULL 负责从局域网摄像头拉流并主动推送到公网，阿里云服务器负责接收视频流并对外发布 RTSP 服务。整体架构可以理解为：

HI3516CV610 摄像头
|
| 局域网 RTSP
v
i.MX6ULL 边缘网关
|
| GStreamer RTP/UDP 推流
v
阿里云 ECS + Docker + MediaMTX
|
| RTSP over TCP
v
PC / VLC 播放

二、边缘网关层面

在本方案中，i.MX6ULL 承担边缘网关的角色。它一方面通过有线网口连接 HI3516 摄像头所在的局域网，另一方面通过 WiFi、4G 或以太网连接阿里云公网服务器。因此，首先要保证 i.MX6ULL 能够访问 HI3516 的局域网 RTSP 地址。假设 HI3516 的 IP 为：192.168.1.88。那么 i.MX6ULL 的 eth0 可以配置为同一网段地址：

ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up

此时两块板子的网络关系为：

HI3516 eth0 192.168.1.88/24
i.MX6ULL eth0 192.168.1.100/24

两者可以通过网线直连，也可以接入同一个交换机或路由器。配置完成后，在 i.MX6ULL 上测试：ping 192.168.1.88。如果能够 ping 通，说明 i.MX6ULL 已经可以访问 HI3516，后续就可以通过 GStreamer 拉取摄像头的 RTSP 视频流：rtsp://192.168.1.88:554/test.264。

如果 ping 不通，需要先从网口硬件、驱动、IP 和路由几个层面排查。i.MX6ULL 的以太网由内部 FEC MAC 和外部 PHY 芯片组成，其中 MAC 负责以太网帧收发，PHY 负责网线电信号、链路检测和速率协商。两者关系可以理解为：

Linux 网络协议栈
└─ eth0 / eth1
└─ FEC MAC
└─ RMII
└─ PHY
└─ 网线

在设备树中，网口一般这样描述：

&fec1
├─ phy-mode = "rmii" // MAC 和 PHY 之间使用 RMII 接口
├─ phy-handle = <&ethphy0> // fec1 绑定到 MDIO 总线上的 ethphy0
├─ phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>
└─ status = "okay"

&fec2
├─ phy-mode = "rmii"
├─ phy-handle = <&ethphy1>
├─ phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>
├─ status = "okay"
└─ mdio
├─ ethphy0: ethernet-phy@0 // PHY 地址 0
└─ ethphy1: ethernet-phy@1 // PHY 地址 1

这里要注意：

fec1 / fec2 是 i.MX6ULL 内部 MAC
ethphy0 / ethphy1 是外部 PHY 芯片
MDIO/MDC 是 MAC 管理 PHY 的总线
RMII 是 MAC 和 PHY 之间传输网络数据的接口

PHY 是一个真实的芯片，内部有寄存器。Linux 驱动可以通过 MDIO 总线访问这些寄存器，用来读取 PHY ID、链路状态、协商结果，或者配置自动协商等参数。网口灯不亮时，通常说明物理链路没有建立。需要重点检查网线、PHY 供电、PHY reset GPIO、设备树中的 phy-handle、phy-mode、MDIO 地址以及 RMII 时钟等。网口灯亮则表示物理链路基本建立，但并不代表 IP 一定能 ping 通。

如果网口灯亮但 ping 不通，则重点检查 IP 和路由配置。对于同网段通信，例如 192.168.1.100 访问 192.168.1.88，不需要默认网关，只需要确保两端 IP 在同一网段，并且网卡已经 up。可以通过以下命令查看路由表：route -n正常应能看到类似路由：

Destination Gateway Genmask Iface
192.168.1.0 0.0.0.0 255.255.255.0 eth0

这表示访问 192.168.1.x 网段时，数据会从 eth0 发出去。

除了访问 HI3516，i.MX6ULL 还需要能够访问阿里云服务器。如果使用 WiFi 联网，USB WiFi 驱动加载成功后，系统中通常会出现 wlan0，部分 Realtek 驱动还可能生成 wlan1。普通 STA 联网场景下，一般优先使用 wlan0。可以先扫描热点：

iwlist wlan0 scan

然后创建 WiFi 配置文件：

cat > /etc/wpa_supplicant.conf <<'EOF'
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1

network={
ssid="iQOO 13"
psk="xxx"
key_mgmt=WPA-PSK
}
EOF

启动 WiFi 认证：

wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant.conf

获取 IP：udhcpc -i wlan0。查看是否获取到 IP 和默认路由：

ifconfig wlan0
route -n

如果 wlan0 已经获取到 IP，并且默认路由走 wlan0，就可以测试阿里云公网服务器是否可达：

ping 116.62.220.8

当 i.MX6ULL 同时满足以下两个条件时，边缘网关链路就基本打通：

1. i.MX6ULL 可以 ping 通 HI3516：192.168.1.88
2. i.MX6ULL 可以 ping 通阿里云服务器：116.62.220.8

此时，i.MX6ULL 就可以运行 GStreamer，从 HI3516 拉取 RTSP 视频流，并重新封装为 RTP/UDP 推送到阿里云服务器：

HI3516 摄像头
|
| 局域网 RTSP：192.168.1.88
v
i.MX6ULL eth0：192.168.1.100
|
| GStreamer 拉流、封装、转发
v
i.MX6ULL wlan0 / 4G
|
| 公网 UDP/RTP
v
阿里云服务器：116.62.220.8:5004

因此，边缘网关层面的排查可以分成两段：

第一段：HI3516 -> i.MX6ULL
目标：i.MX6ULL 能 ping 通 192.168.1.88，并能访问 RTSP 地址。

第二段：i.MX6ULL -> 阿里云
目标：i.MX6ULL 能 ping 通 116.62.220.8，并能将 UDP/RTP 数据发送到 5004 端口。

当这两段都正常后，i.MX6ULL 就可以稳定承担边缘网关的作用：从局域网摄像头拉流，再主动推送到公网服务器。

1、 GStreamer

GStreamer 是 Linux 下常用的音视频处理框架，主要可以分为三层：应用层、核心框架层和插件层。

应用层就是使用 GStreamer 的程序，例如 gst-launch-1.0 命令，或者我们自己编写的 C/C++ 应用程序。应用层的主要作用是创建并搭建 pipeline，告诉 GStreamer 数据应该从哪里来、经过哪些处理模块、最后输出到哪里。

核心框架层是 GStreamer 的核心管理部分，负责创建和管理 pipeline、element、pad、buffer、caps 协商、状态切换、消息总线以及数据流调度等。也就是说，应用层提出处理流程后，核心框架层负责把各个 element 连接起来，并建立完整的数据通路。

插件层则是真正执行具体音视频处理工作的部分。常见的拉流、解封装、解析、解码、编码、封装、推流等功能，通常都是由插件中的 element 完成的。

因此，GStreamer 的整体工作方式可以理解为：应用层创建 pipeline，核心框架层负责管理和调度 pipeline 中的各个 element，而插件层提供具体的 element 来完成实际的数据处理。

这里我们使用 GStreamer 将 HI3516 输出的 RTSP 视频流拉取出来，然后对其中的 H.264 数据进行解析，再重新封装成 RTP 包，通过 UDP 发送到阿里云服务器 116.62.220.8 的 5004 端口。在使用之前，需要先确认系统中是否已经安装 gst-launch-1.0 工具。可以执行下面的命令进行查看：

which gst-launch-1.0

如果该命令能够输出 gst-launch-1.0 的路径，说明工具已经存在，可以正常使用。对应的 GStreamer 命令如下：

gst-launch-1.0 -v \\
rtspsrc location=rtsp://192.168.1.88:554/test.264 latency=0 protocols=tcp ! \\
rtph264depay ! \\
h264parse ! \\
rtph264pay config-interval=1 pt=96 ! \\
udpsink host=116.62.220.8 port=5004 sync=false async=false

2、逐个元件作用说明

2.1. rtspsrc

rtspsrc 是 GStreamer 中的 RTSP 拉流源插件。主要参数说明如下：

location：指定 HI3516 摄像头的 RTSP 地址
protocols=tcp：强制使用 TCP 方式传输 RTSP 数据，降低 UDP 丢包带来的影响
latency=0：尽量降低缓冲延迟，减少端到端延时

它的作用是从 HI3516 拉取 RTSP 视频流，并输出 RTP 视频数据。

2.2. rtph264depay

rtph264depay 的作用是 RTP 解封装。

RTSP 拉到的视频数据中，H.264 码流通常被封装在 RTP 包里。rtph264depay 会去掉 RTP 包头，从 RTP 数据中提取出 H.264 码流。

可以理解为：RTP/H.264 数据包  ->  H.264 码流

2.3. h264parse

h264parse 用于解析和整理 H.264 码流。它会对 H.264 数据进行格式检查、解析和整理，保证后续重新封装 RTP 时，码流格式更加规范。可以理解为：

整理 H.264 码流，为后续重新 RTP 封装做准备

2.4. rtph264pay

rtph264pay 的作用是将 H.264 码流重新封装成 RTP 包。主要参数说明如下：

pt=96：设置 RTP Payload Type 为 96，表示动态负载类型，常用于 H.264 视频
config-interval=1：定期插入 SPS/PPS 参数集，方便接收端正确解码

它的作用是：

H.264 码流 -> RTP/H.264 数据包

这样后续就可以通过 UDP 将 RTP 包发送到云服务器。

2.5. udpsink

udpsink 是 UDP 网络发送插件。主要参数说明如下：

host=116.62.220.8：阿里云服务器公网 IP
port=5004：UDP 目标端口
sync=false：不按照时钟同步发送，降低延迟
async=false：关闭异步状态等待，避免启动时阻塞

它的作用是把前面封装好的 RTP 包，通过 UDP 协议发送到阿里云服务器的 5004 端口。

三、云服务器层面

云服务器端采用 阿里云 Ubuntu 服务器 + Docker + MediaMTX 部署。它的主要作用是：

接收开发板发送过来的 UDP-RTP 流
↓
通过 MediaMTX 转换成 RTSP 流
↓
对外提供播放地址

也就是说，开发板通过 GStreamer 把 HI3516 的 H.264 视频流封装成 RTP 包，并通过 UDP 发送到阿里云服务器的 5004 端口。服务器上的 MediaMTX 接收这路 RTP 流后，再通过 RTSP 的方式对外提供播放服务。

3.1 Docker 部署

Docker = 一个超级轻量的 “独立小虚拟机 / 软件盒子”

你可以把它理解成：

• 一个密封的软件集装箱
• 里面自带运行环境、配置、依赖
• 和你的服务器系统完全隔离
• 点开就能跑，不会污染系统，不会冲突
• 复制到任何电脑都能一模一样运行

3.2 MediaMTX 配置

MediaMTX 在本方案中的作用是：

监听 UDP 5004 端口
↓
接收 RTP-H264 流
↓
转换为 RTSP 服务
↓
通过 8554 端口对外提供播放

配置文件 mediamtx.yml 如下：

logLevel: info
logDestinations: [stdout]

rtspAddress: :8554

paths:
cam:
source: udp+rtp://0.0.0.0:5004
rtpSDP: |
v=0
o=- 0 0 IN IP4 0.0.0.0
s=H264
c=IN IP4 0.0.0.0
t=0 0
m=video 5004 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1

其中：

1、rtspAddress: :8554是表示 RTSP 服务监听 8554 端口。

2、paths:cam:表示定义一路名为 cam 的视频流，客户端访问地址为：rtsp://服务器IP:8554/cam。

source: udp+rtp://0.0.0.0:5004是表示监听本机 UDP 5004 端口，用来接收开发板推送过来的 RTP 数据。

3、rtpSDP 用来描述 RTP 流的格式。这里说明接收到的是 H.264 视频流，Payload Type 为 96，RTP 时间戳频率为 90000，需要和开发板端 rtph264pay 的参数保持一致。

3.3 启动 MediaMTX 容器

启动命令如下：

docker run -d \\
–name mediamtx \\
–restart=always \\
-p 8554:8554/tcp \\
-p 5004:5004/udp \\
-v /root/mediamtx.yml:/mediamtx.yml \\
bluenviron/mediamtx:latest

参数说明：

1、-p 8554:8554/tcp是将 RTSP 服务端口映射到宿主机，供客户端拉流。

2、-p 5004:5004/udp是将 UDP 5004 端口映射到宿主机，用来接收开发板推流。

3、-v /root/mediamtx.yml:/mediamtx.yml是将本地配置文件挂载到容器中，让 MediaMTX 按照该配置启动。最终播放地址为：rtsp://服务器IP:8554/cam。

整体流程可以理解为：

开发板 UDP 推流到 5004 端口
↓
MediaMTX 接收 RTP-H264
↓
转换成 RTSP
↓
客户端通过 rtsp://服务器IP:8554/cam 播放