一、WebRTC与FFmpeg概述：技术栈全景、流媒体角色与转码必要性

1.1 WebRTC技术栈全景——不只是“浏览器打电话”

很多人一听到WebRTC，第一反应就是“网页视频通话”。嗯，这个理解没错，但太窄了。我在2015年第一次接触WebRTC时，也觉得它就是个浏览器API。后来真正做项目才发现，WebRTC的技术栈远比想象中庞大。

说白了，WebRTC是一套实时通信的完整解决方案。它涵盖了音视频采集、编码、网络传输、解码渲染全链路。你想想看，要让两个浏览器之间流畅地传视频，背后要解决多少问题？

• 媒体引擎：负责音视频的采集、降噪、回声消除、自动增益控制。我踩过最大的坑就是回声消除参数没调好，线上会议被投诉“像在澡堂子里开会”。
• 编解码器：VP8、VP9、H.264、AV1，WebRTC默认支持这些。不同浏览器支持的编码器不一样，这就是后面要讲转码的根源。
• 网络传输层：基于ICE、STUN、TURN实现NAT穿透，用DTLS加密，用SRTP保护媒体流。这块我当年调试了整整两周才把TURN服务器配稳。
• 拥塞控制：GCC（Google Congestion Control）算法动态调整码率，保证网络波动时不卡死。

1.2 FFmpeg在流媒体中的角色——瑞士军刀，但别乱挥

FFmpeg在流媒体领域的地位，怎么说呢？就像螺丝刀在工具箱里——你几乎找不到一个不需要它的场景。我做流媒体这十年，FFmpeg帮我解决过的问题包括但不限于：格式转换、码率调整、分辨率缩放、音视频同步修复、切片、推流、拉流……

具体到WebRTC场景，FFmpeg主要扮演这几个角色：

角色	说明	我遇到的典型场景
转码器	将一种编码格式转为另一种	Chrome只支持H.264，Safari偏好VP8，中间必须转
滤镜处理器	缩放、裁剪、叠加水印、调整帧率	直播时给视频加实时字幕，用filter_complex搞定
封装/解封装器	在MP4、FLV、TS、WebM之间互转	客户要求录制的WebRTC会话存成MP4，直接走FFmpeg remux
推流/拉流客户端	通过RTMP、SRT、HLS等协议收发流	把WebRTC流转成RTMP推到CDN，FFmpeg一把梭

1.3 为什么需要转码——三个字：不兼容

你可能会问：WebRTC不是已经支持多种编码器了吗？为什么还要额外转码？

原因很简单：客户端能力不统一。我举个例子你就明白了——

• 浏览器差异：Chrome和Firefox默认用VP8/VP9，Safari和Edge（旧版）只支持H.264。一个会议里四个人用四种浏览器，不转码就有人看不到画面。
• 移动端碎片化：Android手机硬件编码器千奇百怪，有的只支持H.264 Baseline Profile，有的支持High Profile。我曾经在某个国产手机上调试了三天，发现它的VP8编码器输出全是花屏——最后只能强制转H.264。
• 网络自适应：用户从WiFi切到4G，带宽从10Mbps掉到1Mbps。这时候需要动态降低分辨率或码率，但WebRTC原生的SVC（可伸缩编码）支持有限，转码是最灵活的方案。
• 录制与分发：WebRTC流通常是RTP包，要存成文件或推到CDN，必须转成MP4、HLS或RTMP格式。这一步几乎100%需要FFmpeg介入。

1.4 核心知识体系：WebRTC + FFmpeg转码流程全景图

下面这张图是我自己梳理的WebRTC与FFmpeg转码流程核心结构。你看一眼就能明白整个课程要讲什么。

1.5 本章小结——你该带走什么

• WebRTC 是一套完整的实时通信技术栈，不只是浏览器API。它的媒体引擎、编解码器、网络传输层、拥塞控制，每一个模块都可能成为转码的触发点。
• FFmpeg 是流媒体领域的瑞士军刀，但在WebRTC场景下，它的角色集中在解码 → 滤镜处理 → 重新编码这个链条上。延迟是最大的挑战。
• 转码的必要性 源于客户端能力不统一：浏览器差异、移动端碎片化、网络自适应、录制分发需求。这不是“锦上添花”，是“雪中送炭”。