音视频处理
浏览器里的音视频，早就不只是“播放器标签”
很多前端工程师第一次接触这个 topic，印象还停留在：
<video>- 播放器皮肤
- 调一下进度条
这当然是音视频的一部分。
但今天的 Web 平台已经远不止这些。
浏览器已经能承载：
- 采集
- 录制
- 屏幕共享
- 编解码
- 直播播放
- 低延迟通话
- 本地转码和裁剪
所以“音视频处理”不再只是媒体标签 API。
它已经是一条独立的前端能力线。
为什么这个 topic 很容易被低估
因为很多日常前端工作并不直接做底层音视频。
于是团队容易误以为：
音视频是一个很垂直的小领域。
其实不是。
它对很多现代产品都很关键。
例如：
- 视频会议
- 在线教育
- 直播和互动直播
- 在线录屏
- 视频剪辑和内容创作
- 语音和播客工具
只要产品进入这些方向，前端团队就会很快发现：
音视频不是“后端或客户端专属问题”。
Web 前端本身就处在用户体验最前线。
先把概念讲清楚
更准确地说，Web 音视频处理是：
在浏览器中围绕采集、传输、播放、录制、编解码和交互编辑所形成的一整套多媒体工程能力。
这个定义里最重要的是：
- 采集
- 传输
- 播放
- 录制
- 编解码
因为这些不是一个 API 能解决的。
它们是不同层次的问题。
采集能力为什么是第一层分界线
只要应用要接触：
- 摄像头
- 麦克风
- 屏幕
前端就立刻进入一套新的权限和设备语境。
getUserMedia 和 getDisplayMedia 之所以重要，不只是因为能拿到流。
更重要的是，它们把浏览器从“展示页面”推进成了“接入用户设备能力”的平台。
这一步会带来很多新的工程问题：
- 权限申请时机
- 失败提示
- 设备切换
- 权限撤销
- 浏览器兼容差异
MediaStream 为什么应该被理解成“媒体状态容器”
很多初学者会把 MediaStream 理解成：
一个拿来播的视频对象。
这不够。
更有用的理解是：
MediaStream 是一组音视频轨道的容器，它把采集、处理、录制和播放这些环节连接起来。
只要这样理解，你就会更容易看懂：
- 为什么同一条流既能预览又能录制
- 为什么轨道可以开关
- 为什么不同输出链路可以共享同一底层流
MediaRecorder 为什么看起来简单，真实产品却不轻松
MediaRecorder 的 API 形态很友好。
所以很多人会误以为“录制功能很好做”。
真正做进产品后，困难通常很快出现：
- 浏览器支持差异
- 编码格式差异
- 文件体积
- 长时间录制内存压力
- 上传策略
- 录制中断和恢复
这说明 MediaRecorder 解决的是“浏览器内录制能力入口”。
并不自动解决完整录制产品体验。
播放问题为什么经常比“播出来了”复杂得多
音视频播放在业务里往往涉及：
- 起播速度
- 卡顿率
- 清晰度切换
- 弱网容错
- 首帧时间
- 字幕和轨道切换
这时你就会发现，播放不是一个 <video src=""> 能讲完的事。
尤其一旦进入直播或长视频，前端就必须理解：
- 分段
- 缓冲
- 自适应码率
- 协议差异
HLS、DASH、WebRTC 不能放在一个“协议表”里就算讲完
HLS
更接近今天实际业务里的主流分发路径之一。
尤其适合：
- 点播
- 延迟要求没那么极端的直播
它的价值在于：
通过分段和 playlist 组织，和普通 HTTP/CDN 生态能较好协同。
DASH
同样是分段式、自适应码率思路的重要路线。
它更偏开放标准语境。
WebRTC
它和前两者最大的不同，是目标问题就不一样。
WebRTC 更像在解决：
- 双向
- 超低延迟
- 实时互动
所以团队不要把这三者简单看成“播放协议三选一”。
它们本身对应的问题域就不同。
为什么直播和通话会让前端难度陡增
一旦进入：
- 互动直播
- 视频会议
- 连麦
系统就不再只是播放。
你开始处理：
- 采集
- 编码
- 上行
- 下行
- 网络抖动
- 同步
- 设备切换
- 声音回声和降噪体验
这时音视频前端就会明显进入“系统工程”。
所以做过 WebRTC 或大规模直播前端的人，通常会对性能、网络和设备边界有很深刻的认知。
WebCodecs 为什么重要
WebCodecs 的价值，不在于“又多了一个底层 API”。
它真正重要的地方是：
前端终于能更直接地接触编解码层，而不一定总是依赖一个完整的 FFmpeg 级方案。
这对：
- 自定义处理
- 更细的性能控制
- 高级媒体工作流
都很有意义。
但也正因为它更底层，它不适合被理解成“人人都该直接上手的通用方案”。
FFmpeg.wasm 为什么有吸引力，也为什么不能乱用
很多团队会因为 FFmpeg.wasm 很强而感到兴奋。
这可以理解。
因为它意味着很多原本只能放在服务端或原生端的事情，现在浏览器也能尝试了。
例如：
- 格式转换
- 裁剪
- 合并
- 简单转码
但这里必须讲清楚：
FFmpeg.wasm 的问题不只是“能不能跑”。
更现实的是：
- 包体积
- 首次初始化
- 内存占用
- 设备性能差异
所以它更适合：
- 工具型产品
- 编辑型产品
- 对本地处理价值很高的场景
而不是所有普通内容站都应该默认引入。
Web 音视频产品最容易踩的坑是什么
坑一：把音视频当成普通表单功能
这会低估权限、设备和性能复杂度。
坑二：把播放器问题只看成 UI 问题
实际更大的瓶颈常常在协议、网络和缓冲策略。
坑三：忽略浏览器差异和平台限制
移动端浏览器、桌面浏览器、App 内 WebView 的能力边界并不相同。
坑四：过早在浏览器里做重型处理
浏览器端处理很吸引人。
但必须先问：
这个任务真的值得把计算成本放在用户设备上吗？
中国互联网语境里为什么音视频前端能力特别现实
中国互联网里，音视频类需求非常普遍。
例如：
- 直播电商
- 短视频
- 在线教育
- 会议与协作
- 内容创作工具
所以音视频前端在中国语境里并不是偏门能力。
很多时候它和：
- 播放体验
- 互动体验
- 弱网容错
- WebView 环境
这些现实问题直接绑定。
海外语境里为什么更容易把它和 creator tools、协作产品放在一起讨论
海外语境里，音视频前端能力很容易进入：
- creator economy
- remote collaboration
- SaaS 工具
- browser-based editing
这些产品叙事。
这会让团队更重视：
- 浏览器本地处理
- 实时协作
- 多轨编辑
- 编解码与导出体验
所以海外很多讨论会更强调：
- WebCodecs
- FFmpeg.wasm
- 浏览器端媒体工作流
面试或技术分享里怎么讲更成熟
一个更成熟的说法可以是：
Web 音视频处理并不只是调用 <video> 或接一个录制 API，而是在浏览器中处理采集、传输、播放、录制和编解码的一整套能力。真正的工程难点通常不在“能不能播”，而在协议选择、网络容错、设备权限、编解码成本和用户设备承载能力。
像 HLS、DASH、WebRTC、MediaRecorder、WebCodecs、FFmpeg.wasm 这些能力分别位于不同层次，理解它们各自解决的问题，比背 API 名字更重要。
实践建议
实践一：做一个最小录制工具
包括：
- 摄像头预览
- 开始/停止录制
- 本地回放
你会很快看到权限、格式和状态管理问题。
实践二：搭一个 HLS 播放页并做弱网实验
观察：
- 起播时间
- 缓冲行为
- 失败恢复
实践三：做一次浏览器端视频处理对照实验
用：
- FFmpeg.wasm
- 纯服务端处理
各做一次简单转码或裁剪，对比：
- 用户等待时间
- 设备压力
- 上传成本