📚 课程目录第1章 WebRTC与嵌入式系统概述

1. WebRTC与嵌入式系统概述

各位同学好，我是老张。做了十几年嵌入式通信，最近五年一直在跟WebRTC死磕。今天咱们开篇先聊聊，为什么要把WebRTC塞进嵌入式系统里。

说白了，WebRTC不是浏览器专利。它是一套完整的实时通信协议栈，音频、视频、数据传输全包了。我最早接触WebRTC是在2015年，当时给一个无人机项目做图传，试过RTMP、HLS，延迟都太大。后来发现WebRTC能把端到端延迟压到200ms以内，嗯，就是它了。

先看一张整体架构图，帮你建立全局认知。

这张图我建议你存下来。整个课程都会围绕这五层展开。注意看引擎层——音频引擎里的回声消除（AEC）、视频引擎里的码率控制，这些在嵌入式平台上经常要手调参数。

嵌入式系统跟PC、手机不一样。我列几个关键差异，你感受一下。

核心矛盾：WebRTC原本为PC和手机设计，代码量约300万行。嵌入式平台需要做大量裁剪——去掉不必要的编解码器、精简协议栈、优化内存分配。我在一个ARM Cortex-A7项目上，硬是把WebRTC的二进制体积从80MB砍到了12MB。

为什么非要低延迟？因为延迟高了，系统就没法用。我举三个典型场景。

飞手操控无人机，视频延迟超过300ms，炸机风险剧增。我做过一个农业植保无人机项目，要求端到端延迟<150ms。WebRTC的NACK重传和FEC前向纠错在这里起了大作用。

手术机器人、排爆机器人，操作指令和视频反馈必须同步。延迟超过100ms，操作员就会感觉"手跟不上眼"。WebRTC的RTCDataChannel可以传控制指令，跟音视频走同一条ICE通道，省掉额外建连的开销。

智能门铃、对讲机、老人看护设备。这些设备往往跑在WiFi弱信号下，丢包率可能到10%。WebRTC的拥塞控制算法（GCC）能自适应调整码率，保证通话不中断。

我的经验：嵌入式WebRTC项目，80%的坑不在WebRTC本身，而在底层——网卡驱动不稳定、内存碎片、时钟不同步。做项目时先把底层调稳，再碰WebRTC。

这门课的目标很明确：让你能在嵌入式Linux系统上，跑通一个低延迟的WebRTC通话。

具体来说，学完你能做到：

学习路径我建议这样走：

注意：如果你之前没接触过WebRTC，建议先看第2章的基础概念。别一上来就搞交叉编译，容易心态崩。我见过太多人卡在编译环节就放弃了。

好，第一章就到这里。记住一句话：WebRTC在嵌入式上的核心挑战，是用有限的资源，跑出实时的效果。后面每一章，我都会带着你一步步解决这个问题。