1. WebRTC 实时转码概述
各位好，我是老张。在流媒体这行摸爬滚打了十几年，今天咱们来聊聊 WebRTC 实时转码。说实话，这个组合在几年前还是个「奢侈品」，现在却成了很多场景的刚需。
先问个问题：你用过视频通话吧？或者 Zoom 开会？你有没有发现，有时候网络差，画面会变模糊，但通话不会断。这背后，就有实时转码的影子。
什么是实时转码
转码，说白了就是把一种编码格式的视频流，转成另一种格式。比如把 H.264 转成 VP8，或者把 1080p 降成 720p。
但「实时」这两个字，才是真正的难点。它要求：
- 延迟极低：端到端延迟通常要求 < 500ms
- 处理速度快：转码速度必须 > 视频帧率（比如 30fps）
- 不能卡顿：丢帧、花屏都是灾难
核心定义：实时转码 = 在视频流传输过程中，以极低延迟完成编码格式、分辨率、码率或帧率的动态转换。
我刚开始做这个的时候，以为就是拿 FFmpeg 加个参数跑一下。结果一上线，延迟直接飙到 3 秒。嗯，那会儿我才意识到，实时转码和离线转码完全是两码事。
为什么需要实时转码
你想想看，如果没有实时转码，会怎样？
假设你开发了一个视频会议 App。用户 A 用的是 iPhone，支持 H.264 硬编。用户 B 用的是老款 Android 手机，只支持 VP8。没有转码，他俩就互相看不见。这就是最典型的场景——终端兼容性。
我列几个常见的需求场景：
| 场景 | 为什么需要转码 | 我遇到的坑 |
|---|---|---|
| 跨平台互通 | 不同浏览器/设备支持的编码格式不同 | 曾经有个用户用 Safari，死活看不到画面，最后发现是 H.264 和 VP8 不兼容 |
| 网络自适应 | 用户网络波动时，需要动态降低码率 | 直接降码率会导致花屏，必须配合转码做分辨率缩放 |
| 多端同屏 | 手机、PC、电视需要不同的分辨率和码率 | 给电视推 360p 画面，用户投诉「糊得没法看」 |
| 录制存档 | 实时流需要转成标准格式存盘 | 直接存原始流，播放器不认，还得二次转码 |
说白了，实时转码解决的是「一个源，多个目标」的问题。没有它，WebRTC 的互联互通就是个笑话。
WebRTC 与转码的关系
WebRTC 本身的设计理念是「端到端直连」。它希望两个浏览器直接通信，中间不经过服务器。但现实很骨感——
纯 P2P 模式下，如果两端编码格式不一致，WebRTC 会尝试协商。协商失败？那就直接断开。这就是为什么很多 WebRTC 应用需要引入 SFU（Selective Forwarding Unit） 或 MCU（Multipoint Control Unit）。
而转码，通常发生在 SFU/MCU 内部：
- SFU 模式：默认只转发，不转码。但遇到编码不匹配时，必须转码。
- MCU 模式：所有流汇合后统一转码，再分发给各端。
我的建议：能用 SFU 就别用 MCU。SFU 延迟低、资源消耗小。只有遇到编码不兼容或需要合流时，才考虑转码。
我曾经帮一家客户排查问题，他们用 MCU 做 8 人会议，服务器 CPU 直接跑满。换成 SFU + 按需转码后，CPU 降了 70%。你看，架构选型很重要。
下面这张图，展示了 WebRTC 实时转码的核心流程：
注意：转码不是免费的午餐。每路转码都会消耗 CPU/GPU 资源。我曾经见过一个项目，8 路 1080p 同时转码，直接把服务器干宕机了。一定要做好资源预算和限流策略。
最后说一句，WebRTC 和转码的关系，可以总结为：WebRTC 负责传输，转码负责适配。没有转码，WebRTC 只能在小范围、同构环境下工作。有了转码，才能真正做到「一次编码，处处播放」。
嗯，这一章就到这里。记住一句话：实时转码的核心不是「能不能转」，而是「转得快、转得稳、转得省」。