1. 项目背景与核心需求最近在RK3588开发板上折腾一个实时视频推流项目需要把USB摄像头的画面通过WebRTC传输到网页端。这个需求在智能家居、工业检测等领域很常见但实际开发时发现坑比想象中多得多。特别是当你要把OpenCV采集、FFmpeg编码和libdatachannel传输这三个模块串起来时每个环节都可能让你掉进坑里。我最初尝试用原生WebRTC库结果光是下载编译依赖就花了30GB空间编译过程更是噩梦。后来发现libdatachannel这个轻量级替代方案虽然资料少得可怜但至少能在嵌入式设备上跑起来。这个项目最核心要解决三个问题如何稳定采集摄像头画面如何实现低延迟编码怎样正确通过WebRTC发送视频帧2. 开发环境搭建2.1 硬件准备清单我用的硬件配置是RK3588开发板加两个USB摄像头模组这个板子性能足够处理1080p视频。摄像头建议选支持MJPG格式的实测YUV格式对CPU压力太大。系统用的是Ubuntu 20.04主要考虑到驱动支持比较完善。2.2 关键依赖安装安装OpenCV时有个坑要注意默认apt安装的版本可能缺少V4L2支持。我建议自己编译确保开启WITH_V4L2选项。FFmpeg需要开启x264支持这个编码器在嵌入式设备上表现最好。以下是关键命令# 安装OpenCV依赖 sudo apt-get install libgtk2.0-dev pkg-config libavcodec-dev libavformat-dev libswscale-dev # 编译x264 git clone https://code.videolan.org/videolan/x264.git cd x264 ./configure --enable-shared make -j4 sudo make install # 编译FFmpeg关键配置 ./configure --enable-gpl --enable-libx264 --enable-libx265libdatachannel的编译最麻烦需要特别注意关闭GNUTLS和NICE选项否则会引入不必要的依赖cmake -B build -DUSE_GNUTLS0 -DUSE_NICE0 -DCMAKE_BUILD_TYPERelease3. 视频采集模块实现3.1 OpenCV采集优化用OpenCV采集USB摄像头时默认参数下延迟能到200ms以上。经过反复测试发现这几个参数最关键cap.set(cv::CAP_PROP_FOURCC, cv::VideoWriter::fourcc(M,J,P,G)); cap.set(cv::CAP_PROP_FRAME_WIDTH, 640); cap.set(cv::CAP_PROP_FRAME_HEIGHT, 480); cap.set(cv::CAP_PROP_FPS, 30); cap.set(cv::CAP_PROP_BUFFERSIZE, 1); // 这个最重要特别是BUFFERSIZE参数默认是4意味着会有3帧的缓存延迟。设为1后延迟直接降到50ms以内。不过要注意有些摄像头驱动不支持这个参数调整。3.2 多摄像头管理项目中需要支持摄像头热插拔和多路切换。我的做法是开个监控线程定期检查/dev/video*设备节点void checkCameras() { DIR *dir opendir(/dev); if (!dir) return; struct dirent *entry; while ((entry readdir(dir))) { if (strncmp(entry-d_name, video, 5) 0) { int index atoi(entry-d_name 5); // 检查摄像头是否可用 } } closedir(dir); }4. 视频编码关键实现4.1 FFmpeg编码器封装H.264编码需要特别注意zerolatency模式否则会有500ms以上的编码延迟。我封装了个FFmpegH264Encoder类核心初始化代码如下AVDictionary* opts nullptr; av_dict_set(opts, preset, ultrafast, 0); av_dict_set(opts, tune, zerolatency, 0); av_dict_set(opts, x264-params, annexb0, 0); if (avcodec_open2(codecCtx, codec, opts) 0) { throw std::runtime_error(无法打开编码器); }其中annexb0这个参数特别重要必须和libdatachannel的RTP打包器配置保持一致否则接收端无法解析。4.2 时间戳处理WebRTC对时间戳非常敏感错误的时间戳会导致视频卡顿或加速播放。我的做法是使用steady_clock记录基准时间auto now chrono::steady_clock::now(); uint64_t timestamp_us chrono::duration_castchrono::microseconds( now.time_since_epoch()).count() - g_state.baseTimestamp;5. WebRTC传输实现5.1 信令服务器搭建libdatachannel自带的Python信令服务器其实够用但需要修改几个地方async def handler(websocket, path): if path /sender: clients[sender] websocket elif path /receiver: clients[receiver] websocket try: async for message in websocket: msg json.loads(message) # 简单的消息路由逻辑 if msg[type] offer and path /sender: await clients[receiver].send(message) finally: clients.pop(path[1:], None)5.2 Track的使用技巧libdatachannel的Track类文档很少经过源码分析发现必须使用sendFrame而不是send而且要传入正确的时间戳track-sendFrame(sample, std::chrono::durationdouble, std::micro(sampleTime_us));时间戳单位必须是微秒否则会出现周期性卡顿。这个坑我花了三天才排查出来。6. 性能优化实战6.1 编码线程分离最初我把编码和发送放在同一个线程发现帧率上不去。后来改成双线程环形缓冲区// 编码线程 while (running) { cv::Mat frame; cameraMutex.lock(); cap frame; cameraMutex.unlock(); auto encoded encoder.encode(frame); queueMutex.lock(); frameQueue.push(encoded); queueMutex.unlock(); } // 发送线程 while (running) { queueMutex.lock(); if (!frameQueue.empty()) { auto frame frameQueue.front(); frameQueue.pop(); queueMutex.unlock(); track-sendFrame(frame.data, frame.timestamp_us); } }6.2 内存池优化频繁申请释放内存会导致性能下降我实现了简单的内存池class FramePool { public: std::vectoruint8_t getBuffer(int size) { std::lock_guardstd::mutex lock(mutex); for (auto it pools.begin(); it ! pools.end(); it) { if (it-capacity() size) { auto buf std::move(*it); pools.erase(it); return buf; } } return std::vectoruint8_t(size); } void returnBuffer(std::vectoruint8_t buf) { std::lock_guardstd::mutex lock(mutex); pools.push_back(std::move(buf)); } private: std::vectorstd::vectoruint8_t pools; std::mutex mutex; };7. 常见问题排查7.1 视频卡顿问题如果出现周期性卡顿检查以下几点时间戳是否使用微秒单位编码器是否开启zerolatency模式WebSocket连接是否稳定7.2 编译错误处理编译libdatachannel时常见错误undefined reference to rtc::Init::Init()这是因为没有正确链接静态库需要在CMake中加上target_link_libraries(your_target PRIVATE rtc)8. 项目完整部署8.1 系统服务配置为了让程序开机自启我写了systemd服务文件[Unit] DescriptionWebRTC Camera Service [Service] ExecStart/usr/local/bin/webrtc_camera Restartalways Userroot [Install] WantedBymulti-user.target8.2 网页客户端适配前端需要处理SDP交换核心JavaScript代码pc.onicecandidate e { if (e.candidate) { ws.send(JSON.stringify({ type: candidate, candidate: e.candidate })); } }; ws.onmessage msg { const data JSON.parse(msg.data); if (data.type offer) { pc.setRemoteDescription(new RTCSessionDescription(data)); pc.createAnswer().then(answer { pc.setLocalDescription(answer); ws.send(JSON.stringify(answer)); }); } };这个项目从零开始搭建花了将近一个月时间期间最大的教训就是WebRTC的时间戳处理必须精确到微秒级任何偷懒都会导致视频卡顿。另外建议在RK3588上测试时先用低分辨率640x480跑通流程再逐步提升分辨率。现在这套方案在1080p下能稳定跑在25fps端到端延迟控制在300ms以内完全满足工业检测的需求。
从零构建：基于libdatachannel与FFmpeg的USB摄像头WebRTC实时推流实践
1. 项目背景与核心需求最近在RK3588开发板上折腾一个实时视频推流项目需要把USB摄像头的画面通过WebRTC传输到网页端。这个需求在智能家居、工业检测等领域很常见但实际开发时发现坑比想象中多得多。特别是当你要把OpenCV采集、FFmpeg编码和libdatachannel传输这三个模块串起来时每个环节都可能让你掉进坑里。我最初尝试用原生WebRTC库结果光是下载编译依赖就花了30GB空间编译过程更是噩梦。后来发现libdatachannel这个轻量级替代方案虽然资料少得可怜但至少能在嵌入式设备上跑起来。这个项目最核心要解决三个问题如何稳定采集摄像头画面如何实现低延迟编码怎样正确通过WebRTC发送视频帧2. 开发环境搭建2.1 硬件准备清单我用的硬件配置是RK3588开发板加两个USB摄像头模组这个板子性能足够处理1080p视频。摄像头建议选支持MJPG格式的实测YUV格式对CPU压力太大。系统用的是Ubuntu 20.04主要考虑到驱动支持比较完善。2.2 关键依赖安装安装OpenCV时有个坑要注意默认apt安装的版本可能缺少V4L2支持。我建议自己编译确保开启WITH_V4L2选项。FFmpeg需要开启x264支持这个编码器在嵌入式设备上表现最好。以下是关键命令# 安装OpenCV依赖 sudo apt-get install libgtk2.0-dev pkg-config libavcodec-dev libavformat-dev libswscale-dev # 编译x264 git clone https://code.videolan.org/videolan/x264.git cd x264 ./configure --enable-shared make -j4 sudo make install # 编译FFmpeg关键配置 ./configure --enable-gpl --enable-libx264 --enable-libx265libdatachannel的编译最麻烦需要特别注意关闭GNUTLS和NICE选项否则会引入不必要的依赖cmake -B build -DUSE_GNUTLS0 -DUSE_NICE0 -DCMAKE_BUILD_TYPERelease3. 视频采集模块实现3.1 OpenCV采集优化用OpenCV采集USB摄像头时默认参数下延迟能到200ms以上。经过反复测试发现这几个参数最关键cap.set(cv::CAP_PROP_FOURCC, cv::VideoWriter::fourcc(M,J,P,G)); cap.set(cv::CAP_PROP_FRAME_WIDTH, 640); cap.set(cv::CAP_PROP_FRAME_HEIGHT, 480); cap.set(cv::CAP_PROP_FPS, 30); cap.set(cv::CAP_PROP_BUFFERSIZE, 1); // 这个最重要特别是BUFFERSIZE参数默认是4意味着会有3帧的缓存延迟。设为1后延迟直接降到50ms以内。不过要注意有些摄像头驱动不支持这个参数调整。3.2 多摄像头管理项目中需要支持摄像头热插拔和多路切换。我的做法是开个监控线程定期检查/dev/video*设备节点void checkCameras() { DIR *dir opendir(/dev); if (!dir) return; struct dirent *entry; while ((entry readdir(dir))) { if (strncmp(entry-d_name, video, 5) 0) { int index atoi(entry-d_name 5); // 检查摄像头是否可用 } } closedir(dir); }4. 视频编码关键实现4.1 FFmpeg编码器封装H.264编码需要特别注意zerolatency模式否则会有500ms以上的编码延迟。我封装了个FFmpegH264Encoder类核心初始化代码如下AVDictionary* opts nullptr; av_dict_set(opts, preset, ultrafast, 0); av_dict_set(opts, tune, zerolatency, 0); av_dict_set(opts, x264-params, annexb0, 0); if (avcodec_open2(codecCtx, codec, opts) 0) { throw std::runtime_error(无法打开编码器); }其中annexb0这个参数特别重要必须和libdatachannel的RTP打包器配置保持一致否则接收端无法解析。4.2 时间戳处理WebRTC对时间戳非常敏感错误的时间戳会导致视频卡顿或加速播放。我的做法是使用steady_clock记录基准时间auto now chrono::steady_clock::now(); uint64_t timestamp_us chrono::duration_castchrono::microseconds( now.time_since_epoch()).count() - g_state.baseTimestamp;5. WebRTC传输实现5.1 信令服务器搭建libdatachannel自带的Python信令服务器其实够用但需要修改几个地方async def handler(websocket, path): if path /sender: clients[sender] websocket elif path /receiver: clients[receiver] websocket try: async for message in websocket: msg json.loads(message) # 简单的消息路由逻辑 if msg[type] offer and path /sender: await clients[receiver].send(message) finally: clients.pop(path[1:], None)5.2 Track的使用技巧libdatachannel的Track类文档很少经过源码分析发现必须使用sendFrame而不是send而且要传入正确的时间戳track-sendFrame(sample, std::chrono::durationdouble, std::micro(sampleTime_us));时间戳单位必须是微秒否则会出现周期性卡顿。这个坑我花了三天才排查出来。6. 性能优化实战6.1 编码线程分离最初我把编码和发送放在同一个线程发现帧率上不去。后来改成双线程环形缓冲区// 编码线程 while (running) { cv::Mat frame; cameraMutex.lock(); cap frame; cameraMutex.unlock(); auto encoded encoder.encode(frame); queueMutex.lock(); frameQueue.push(encoded); queueMutex.unlock(); } // 发送线程 while (running) { queueMutex.lock(); if (!frameQueue.empty()) { auto frame frameQueue.front(); frameQueue.pop(); queueMutex.unlock(); track-sendFrame(frame.data, frame.timestamp_us); } }6.2 内存池优化频繁申请释放内存会导致性能下降我实现了简单的内存池class FramePool { public: std::vectoruint8_t getBuffer(int size) { std::lock_guardstd::mutex lock(mutex); for (auto it pools.begin(); it ! pools.end(); it) { if (it-capacity() size) { auto buf std::move(*it); pools.erase(it); return buf; } } return std::vectoruint8_t(size); } void returnBuffer(std::vectoruint8_t buf) { std::lock_guardstd::mutex lock(mutex); pools.push_back(std::move(buf)); } private: std::vectorstd::vectoruint8_t pools; std::mutex mutex; };7. 常见问题排查7.1 视频卡顿问题如果出现周期性卡顿检查以下几点时间戳是否使用微秒单位编码器是否开启zerolatency模式WebSocket连接是否稳定7.2 编译错误处理编译libdatachannel时常见错误undefined reference to rtc::Init::Init()这是因为没有正确链接静态库需要在CMake中加上target_link_libraries(your_target PRIVATE rtc)8. 项目完整部署8.1 系统服务配置为了让程序开机自启我写了systemd服务文件[Unit] DescriptionWebRTC Camera Service [Service] ExecStart/usr/local/bin/webrtc_camera Restartalways Userroot [Install] WantedBymulti-user.target8.2 网页客户端适配前端需要处理SDP交换核心JavaScript代码pc.onicecandidate e { if (e.candidate) { ws.send(JSON.stringify({ type: candidate, candidate: e.candidate })); } }; ws.onmessage msg { const data JSON.parse(msg.data); if (data.type offer) { pc.setRemoteDescription(new RTCSessionDescription(data)); pc.createAnswer().then(answer { pc.setLocalDescription(answer); ws.send(JSON.stringify(answer)); }); } };这个项目从零开始搭建花了将近一个月时间期间最大的教训就是WebRTC的时间戳处理必须精确到微秒级任何偷懒都会导致视频卡顿。另外建议在RK3588上测试时先用低分辨率640x480跑通流程再逐步提升分辨率。现在这套方案在1080p下能稳定跑在25fps端到端延迟控制在300ms以内完全满足工业检测的需求。
