4、摄像头选型与接入：IPC摄像头协议（ONVIF、RTSP）、摄像头参数（分辨率、帧率、编码格式）、实战：用FFmpeg拉取RTSP流并转码

好，咱们进入正题。摄像头选型这件事，说难不难，说简单也不简单。我见过不少项目，前期选型没上心，结果到了集成阶段，发现协议不兼容、码流推不动，最后只能换硬件，白白浪费工期。所以这一节，咱们把摄像头选型和接入的底裤扒干净。

4.1 IPC摄像头协议：ONVIF 与 RTSP

先聊协议。市面上主流的IPC（网络摄像头）基本都支持两种协议：ONVIF 和 RTSP。这两者有什么区别？我简单给你捋一捋。

4.1.1 ONVIF：标准化发现与管理

ONVIF 是一个全球性的开放标准。说白了，它解决的是「不同品牌的摄像头怎么统一管理」的问题。你想想看，一个项目里可能用了海康、大华、宇视三个牌子的摄像头，如果没有ONVIF，你得分别去对接它们的私有SDK，那得多痛苦？

ONVIF 主要干三件事：

  • 设备发现：自动扫描局域网内的摄像头，拿到IP地址和设备信息。
  • 参数配置：远程修改分辨率、帧率、码率等参数。
  • 媒体流协商：获取RTSP流的地址（比如 rtsp://192.168.1.100:554/stream1）。
我的经验： 我个人习惯在项目初期先用ONVIF Device Manager这个工具扫一遍所有摄像头，确认它们都支持ONVIF标准。有些杂牌摄像头虽然标了ONVIF，但兼容性很差，扫不出来。遇到这种情况，趁早换。

4.1.2 RTSP：实时流传输协议

RTSP 是真正的「视频流管道」。ONVIF 帮你找到了摄像头，但真正把视频数据拉回来，靠的是 RTSP。它负责控制流的播放、暂停、快进，而真正的视频数据（RTP包）是在UDP或TCP上传输的。

RTSP 的 URL 格式通常长这样：

rtsp://username:password@ip:port/stream1

举个例子：

rtsp://admin:123456@192.168.1.100:554/h264/ch1/main/av_stream

这里要注意，不同厂商的RTSP路径规则不一样。海康的路径是 /h264/ch1/main/av_stream，大华可能是 /cam/realmonitor?channel=1&subtype=0。嗯，这里有个坑——我建议你直接去摄像头Web管理页面的「网络」-「RTSP」设置里看，一般会显示完整的URL。

避坑指南： 我曾经在一个项目中，RTSP流死活拉不下来，折腾了半天才发现是摄像头开启了「RTSP认证」，而FFmpeg命令里没带用户名密码。记住，如果摄像头设置了密码，RTSP URL里必须带上 username:password@。

4.2 摄像头参数：分辨率、帧率、编码格式

选摄像头，本质上是选参数。我见过有人为了省钱买了200万像素的摄像头，结果客户要求看清车牌，根本看不清。所以参数这块，咱们得掰扯清楚。

4.2.1 分辨率

分辨率决定了画面的清晰度。常见的分辨率有：

分辨率 像素 适用场景
720P (1280x720) 约92万 室内监控、小范围
1080P (1920x1080) 约200万 通用场景，性价比最高
4MP (2560x1440) 约400万 需要看清细节的场景
4K (3840x2160) 约800万 大范围、高精度识别

我个人建议，移动端实时查看，1080P 是底线。低于这个分辨率，在手机上放大看细节时全是马赛克。但也不是越高越好——4K 流对带宽和手机解码能力都是考验。

4.2.2 帧率

帧率决定了画面的流畅度。单位是fps（帧每秒）。

  • 15fps：勉强能看，画面有卡顿感。适合对实时性要求不高的场景。
  • 25fps：流畅，人眼基本感觉不到卡顿。这是监控行业的标配。
  • 30fps：非常流畅，适合高速运动场景（比如拍车流）。

你想想看，如果摄像头帧率只有15fps，你在手机上滑动画面时，会感觉一帧一帧地跳。所以我的建议是：至少选25fps。

4.2.3 编码格式

编码格式决定了视频的压缩效率和画质。目前主流的有三种：

  • H.264：最成熟，兼容性最好。几乎所有设备和播放器都支持。缺点是压缩率一般，同样画质下码率较高。
  • H.265 (HEVC)：压缩率比H.264高50%左右。同样画质下，码率更低，节省带宽和存储。但解码需要硬件支持，老手机可能卡顿。
  • MJPEG：每一帧都是独立的JPEG图片。画质好，但码率巨大，基本只在特殊场景用。
核心建议： 移动端实时查看，优先选 H.264。兼容性好，解码快。如果手机支持且带宽有限，可以切到H.265。但千万别用MJPEG，那玩意儿能把你的流量烧光。

4.3 实战：用FFmpeg拉取RTSP流并转码

理论说完了，咱们来点实际的。FFmpeg 是处理音视频的神器，没有之一。我几乎每天都要用它来拉流、转码、截图。

4.3.1 基础拉流命令

最简单的用法，就是把RTSP流直接保存成文件：

ffmpeg -i "rtsp://admin:123456@192.168.1.100:554/h264/ch1/main/av_stream" -c copy output.mp4

这里 -c copy 表示不重新编码，直接复制原始数据。速度最快，但文件格式可能不兼容。

4.3.2 转码为移动端兼容格式

移动端（iOS/Android）对视频格式有要求。我建议转成 H.264 + AAC 音频，封装成 MP4：

ffmpeg -i "rtsp://admin:123456@192.168.1.100:554/h264/ch1/main/av_stream" \
    -vcodec libx264 -preset ultrafast -tune zerolatency \
    -acodec aac -b:a 128k \
    -f mp4 output.mp4

参数说明：

  • -preset ultrafast：编码速度最快，适合实时场景。代价是文件稍大。
  • -tune zerolatency：降低延迟，适合直播。
  • -b:a 128k：音频码率128kbps，够用。

4.3.3 实时推流到移动端

如果你不想存文件，而是直接推流给移动端看，可以用 FFmpeg 转成 HLS 或 RTMP：

ffmpeg -i "rtsp://admin:123456@192.168.1.100:554/h264/ch1/main/av_stream" \
    -vcodec libx264 -preset ultrafast -tune zerolatency \
    -acodec aac \
    -f hls -hls_time 2 -hls_list_size 5 -hls_flags delete_segments \
    /var/www/html/live/stream.m3u8

这样就会生成一个 HLS 流，移动端直接用浏览器或播放器打开 http://your-server/live/stream.m3u8 就能看。

我的经验： 我在做远程监控项目时，发现直接用RTSP推给移动端，很多手机播放器不支持。后来统一转成HLS，兼容性就好了很多。HLS 的延迟大概在3-5秒，对于监控来说完全能接受。

4.3.4 常见问题与排查

拉流时遇到问题怎么办？我列几个我踩过的坑：

  • 「Connection refused」：摄像头没开RTSP服务，或者端口不对。默认是554。
  • 「Unauthorized」：用户名密码错误。检查URL里的账号密码。
  • 「Invalid data found when processing input」：RTSP路径不对。去摄像头Web页面确认路径。
  • 「Frame rate very low」：网络带宽不足，或者摄像头性能不够。降低分辨率或帧率试试。
避坑指南： 我曾经在拉流时发现画面花屏，排查了半天，结果是网线接触不良导致丢包。记住，RTSP对网络质量很敏感。如果画面花屏，先检查网络，再检查摄像头。

4.4 本章知识体系

为了让你更直观地理解摄像头选型与接入的完整流程，我画了一张图：

摄像头选型与接入知识体系 1. 摄像头选型 协议选择 参数配置 编码格式 ONVIF：设备发现与管理 RTSP：实时流传输 分辨率：720P~4K 帧率：15~30fps H.264 / H.265 MJPEG（不推荐） 2. 实战：FFmpeg拉流与转码 保存为MP4 推HLS流 推RTMP流

这张图把整个流程串起来了。从选型开始，到协议、参数、编码，最后用FFmpeg实战拉流转码。你照着这个思路走，基本不会出大问题。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →