WebRTC仅负责实时传输原始音视频流，不处理裁剪、转码或滤镜；实际处理需借助Canvas、WebGL或FFmpeg.wasm等前端技术，其核心优势在于毫秒级端到端延迟、NAT穿透和P2P连接。
WebRTC 本身不处理视频，只负责传输
很多人以为 WebRTC 能直接“裁剪”“转码”“加滤镜”，其实它只是个实时通信管道——RTCPeerConnection 传的是原始视频帧（通过 getUserMedia 拿到的 MediaStream），后续所有处理都得靠你自己接在它前面或后面做。
真正干活的是：Canvas + requestAnimationFrame 做逐帧绘制与修改，或 WebAssembly + FFmpeg.wasm 做编码/解码，或 WebGL 做高性能滤镜。WebRTC 只管把摄像头流塞进去、把处理后的流送出去。
用 Canvas 实时处理视频帧的典型流程
这是最轻量、兼容性最好、适合滤镜/叠加/裁剪等简单操作的方式。关键点不是“能不能”，而是“怎么避免卡顿和丢帧”：
-
video元素必须设置playsinline和autoplay，否则 iOS Safari 会拒绝播放 - 不要在
requestAnimationFrame里反复调用canvas.getContext('2d')，缓存一次即可 - 用
canvas.width/canvas.height显式设为视频自然尺寸（video.videoWidth/video.videoHeight），否则缩放会失真 - 处理前先检查
video.readyState === 4，否则drawImage会静默失败
const video = document.getElementById('input-video');
const canvas = document.getElementById('process-canvas');
const ctx = canvas.getContext('2d');
function processFrame() {
if (video.readyState === video.HAVE_ENOUGH_DATA) {
canvas.width = video.videoWidth;
canvas.height = video.videoHeight;
ctx.drawImage(video, 0, 0, canvas.width, canvas.height);
// 在这里加滤镜：ctx.globalCompositeOperation = 'multiply'; 等
}
requestAnimationFrame(processFrame);
}
想转码或导出 MP4？别指望 WebRTC，用 FFmpeg.wasm
WebRTC 不提供编码器控制，也无法导出文件。MediaRecorder 只能录成 Blob（通常是 webm），且不支持 H.264 编码（Safari 除外）。要生成标准 MP4 或调整码率/分辨率，必须上 FFmpeg.wasm：
- 初始化耗时长（首次加载 wasm 模块约 5–10 秒），建议提前
load并复用实例 - 输入必须是
Uint8Array或File，不能直接喂MediaStream；需先用MediaRecorder录一段 webm，再传给 FFmpeg - 命令行参数风格：
-i input.webm -c:v libx264 -b:v 2M -s 1280x720 output.mp4，注意libx264在 wasm 中需手动启用编译选项 - 内存占用高，长时间处理易触发浏览器 OOM，建议分段处理
WebRTC 真正擅长的三件事
别在它不负责的环节浪费时间。它强在：
-
毫秒级端到端延迟：用
RTCPeerConnection+SDP协商后，音视频帧从采集到远端渲染通常 -
自适应网络抖动：内置
Google Congestion Control，自动降帧率/分辨率，无需你写带宽探测逻辑 - 免服务器中转的 P2P：两个浏览器直连（配合 STUN/TURN），流量不经过你的后端，省带宽也省成本
如果你的需求是“让用户上传视频→后台转码→返回链接”，WebRTC 完全不合适；但如果是“两人开视频会议时实时共享白板+文字标注”，那它就是目前唯一可行的方案。
复杂点在于：WebRTC 的 API 表面简单，但 SDP 协商失败、ICE 连接卡住、音频轨道静音无提示、移动端后台被挂起导致黑屏……这些问题不会报错，只会“没画面”。调试得靠 peerConnection.getStats() 和 Chrome 的 chrome://webrtc-internals。
