WebRTC仅负责实时传输原始音视频流,不处理裁剪、转码或滤镜;实际处理需借助Canvas、WebGL或FFmpeg.wasm等前端技术,其核心优势在于毫秒级端到端延迟、NAT穿透和P2P连接。
很多人以为 WebRTC 能直接“裁剪”“转码”“加滤镜”,其实它只是个实时通信管道——RTCPeerConnection 传的是原始视频帧(通过 getUserMedia 拿到的 Me),后续所有处理都得靠你自己接在它前面或后面做。
diaStream
真正干活的是:Canvas + requestAnimationFrame 做逐帧绘制与修改,或 WebAssembly + FFmpeg.wasm 做编码/解码,或 WebGL 做高性能滤镜。WebRTC 只管把摄像头流塞进去、把处理后的流送出去。
这是最轻量、兼容性最好、适合滤镜/叠加/裁剪等简单操作的方式。关键点不是“能不能”,而是“怎么避免卡顿和丢帧”:
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);
}
WebRTC 不提供编码器控制,也无法导出文件。MediaRecorder 只能录成 Blob(通常是 webm),且不支持 H.264 编码(Safari 除外)。要生成标准 MP4 或调整码率/分辨率,必须上 FFmpeg.wasm:
load 并复用实例Uint8Array 或 File,不能直接喂 MediaStream;需先用 MediaRecorder 录一段 webm,再传给 FFmpeg-i input.webm -c:v libx264 -b:v 2M -s 1280x720 output.mp4,注意 libx264 在 wasm 中需手动启用编译选项别在它不负责的环节浪费时间。它强在:
RTCPeerConnection + SDP 协商后,音视频帧从采集到远端渲染通常
Google Congestion Control,自动降帧率/分辨率,无需你写带宽探测逻辑如果你的需求是“让用户上传视频→后台转码→返回链接”,WebRTC 完全不合适;但如果是“两人开视频会议时实时共享白板+文字标注”,那它就是目前唯一可行的方案。
复杂点在于:WebRTC 的 API 表面简单,但 SDP 协商失败、ICE 连接卡住、音频轨道静音无提示、移动端后台被挂起导致黑屏……这些问题不会报错,只会“没画面”。调试得靠 peerConnection.getStats() 和 Chrome 的 chrome://webrtc-internals。