23、WebRTC与IoT：嵌入式设备上的WebRTC、实时视频监控、远程控制

嵌入式设备跑WebRTC？很多人第一反应是“跑得动吗？”

说实话，五年前我也不敢这么想。那时候我在一个智能家居项目里，想在摄像头模组上直接推流，结果折腾了两个月，最后老老实实走RTSP转发的路子。但这两年情况完全变了——芯片性能上来了，WebRTC的C++库也优化得越来越轻量。现在，我敢说，在树莓派4、ESP32-S3甚至某些Linux嵌入式板卡上跑WebRTC，已经是成熟方案了。

为什么IoT需要WebRTC？

传统的IoT视频方案，要么走RTSP，要么走HTTP-FLV。但这两个都有个硬伤：穿透NAT。你想想看，家里的摄像头在内网，手机在外面，中间隔着路由器。RTSP基本没辙，你得配端口映射。HTTP-FLV延迟又高。

WebRTC自带ICE/STUN/TURN，说白了就是帮你搞定“内网设备怎么被外网访问”这个难题。而且它天生就是P2P的，延迟低到几百毫秒。我在一个远程车控项目里实测过，树莓派摄像头通过WebRTC推流到手机，端到端延迟稳定在200ms以内。

嵌入式WebRTC的架构选择

嵌入式设备上跑WebRTC，通常有两种路子。我两种都踩过坑，给你说说区别。

方案	代表库	资源消耗	适用场景
全量WebRTC Native	libwebrtc (Google官方)	RAM > 128MB, Flash > 50MB	树莓派4、RK3588等Linux板卡
轻量级WebRTC	libdatachannel, gstreamer-webrtc	RAM > 16MB, Flash > 5MB	ESP32-S3、RT-Thread设备

我个人习惯：如果设备跑的是完整Linux，直接用Google官方的libwebrtc编译。如果是RTOS或者资源受限的MCU，那就用libdatachannel只做DataChannel通信，视频流走单独的H264编码器。

实时视频监控：从摄像头到浏览器

这是最常见的场景。嵌入式设备采集摄像头数据，编码成H264/H265，通过WebRTC推送到浏览器。核心流程就三步：

1. 采集与编码：V4L2采集原始帧，硬件编码器压缩成H264
2. 打包与发送：将H264 NAL单元封装成RTP包，通过WebRTC PeerConnection发送
3. 信令交换：通过MQTT或WebSocket交换SDP和ICE候选

下面是我在树莓派上用过的一个简化代码片段，用gstreamer配合webrtcbin实现推流：

// 树莓派端：gstreamer webrtcbin 推流
GST_DEBUG=3 gst-launch-1.0 \
    v4l2src device=/dev/video0 ! \
    video/x-raw,width=640,height=480 ! \
    v4l2h264enc extra-controls="encode,quantisation_range=1" ! \
    h264parse ! \
    queue ! \
    webrtcbin name=send \
    stun-server=stun://stun.l.google.com:19302 \
    bundle-policy=max-bundle \
    -- send::on-negotiation-needed \
    "send::create-offer"

这段代码里，v4l2h264enc用的是树莓派的硬件编码器，CPU占用极低。我在项目里实测，720p推流CPU占用不到15%。

远程控制：双向通信的难点

视频监控只是单向推流，远程控制需要双向通信。比如你通过浏览器控制嵌入式设备的GPIO、电机或者舵机。

这里有个关键点：控制指令必须可靠，不能丢包。WebRTC的DataChannel默认是SCTP协议，支持可靠传输。但如果你用视频通道传控制指令，那就大错特错了——视频丢包可以忍，控制指令丢包可能让设备失控。

我建议的做法：

• 控制指令走DataChannel：设置ordered: true, maxRetransmits: 3，保证指令必达
• 视频流走MediaStream：允许适度丢包，保证实时性
• 心跳机制：每5秒发一次ping，检测连接状态

下面是一个简单的DataChannel发送指令的示例：

// 浏览器端发送控制指令
const dc = peerConnection.createDataChannel('control', {
    ordered: true,
    maxRetransmits: 3
});

dc.onopen = () => {
    // 发送GPIO高电平指令
    dc.send(JSON.stringify({ pin: 18, value: 1 }));
};

// 嵌入式设备端接收
dc.onmessage = (event) => {
    const cmd = JSON.parse(event.data);
    digitalWrite(cmd.pin, cmd.value);  // 控制GPIO
};

嗯，这里要注意：嵌入式设备的网络栈可能比较弱。我曾经在某个RTOS设备上发现DataChannel频繁断连，后来排查是SCTP缓冲区太小。把sctp-buffers从默认的16KB调到64KB就稳定了。

知识体系与核心逻辑

下面这张图，是我自己总结的嵌入式WebRTC架构。你看一眼，基本就明白整个链路了。

实战中的几个关键配置

嵌入式设备资源有限，WebRTC的配置不能照搬PC端。我列几个我常用的调优参数：

• 视频分辨率：640x480足矣，720p以上对编码器压力大
• 帧率：15fps，再高嵌入式设备扛不住
• 码率：500kbps ~ 1Mbps，根据WiFi信号动态调整
• ICE候选类型：优先用host候选，减少STUN/TURN延迟
• 缓冲区：jitterBuffer设为100ms，太低容易卡顿

远程控制的可靠性保障

远程控制最怕什么？指令丢了，或者指令重复执行。我踩过一个大坑：

有一次做智能灯控，浏览器发送“关闭灯光”指令，结果网络抖动，指令重传了两次。设备端收到两条指令，灯闪了两下才关掉。用户投诉说“灯有鬼”。

解决方案很简单：指令去重。每条指令带一个递增的序列号，设备端记录最后执行的序列号，重复的指令直接丢弃。

// 设备端去重逻辑
uint32_t last_seq = 0;
void on_control_msg(const char* msg) {
    json_t* root = json_parse(msg);
    uint32_t seq = json_get_int(root, "seq");
    if (seq <= last_seq) {
        // 重复指令，丢弃
        return;
    }
    last_seq = seq;
    // 执行控制逻辑
    execute_command(root);
}

另外，我建议在DataChannel上实现ACK机制。设备收到指令后，回复一条ACK，浏览器端如果3秒内没收到ACK，就重发。这样既保证了可靠性，又不会因为网络延迟导致误操作。

写在最后

嵌入式WebRTC这块，说白了就是“用有限的资源，做实时的事”。你不需要把整个WebRTC协议栈都搬上去，只需要把核心的P2P通信、视频编码、DataChannel用好，就能做出很实用的产品。

我个人觉得，未来两年，WebRTC在IoT领域会爆发。尤其是那些需要远程视频交互和控制的场景——智能门铃、农业大棚监控、工业巡检机器人。门槛已经降得很低了，剩下的就是你怎么组合这些技术。

嗯，如果你正在做类似的项目，记住一句话：先让视频通起来，再优化；先让控制可靠，再谈体验。