WebCodecs - tag - 沐木https://oldletter.cn/tags/webcodecs/WebCodecs - tag - 沐木Hugo -- gohugo.iozh-cnSat, 11 Jul 2026 00:00:00 +0000实时视频（三）：解码与断流https://oldletter.cn/posts/rtsp-browser-03-webcodecs-wasm/Sat, 11 Jul 2026 00:00:00 +0000mumuhttps://oldletter.cn/posts/rtsp-browser-03-webcodecs-wasm/

系列导航：8 | 9 | 10

浏览器有 VideoDecoder 接口，不代表当前 H.264/H.265 配置一定可用。能力探测、输入格式、解码队列和断流重建必须放在同一条状态链里。当前 demo 采用 Worker 解耦主线程，Rust/WASM 在解码提交前检查码流结构。

能力探测绑定具体配置

收到参数集后构造 VideoDecoderConfig，配置中包含 codec string、description、codedWidth、codedHeight 和必要的硬件提示。先调用 VideoDecoder.isConfigSupported()，成功后再创建解码器。参数集摘要、分辨率或 profile 变化时，旧结果失效，必须重新探测。

stateDiagram-v2 [*] --> Idle Idle --> Probing: 收到参数集 Probing --> WebCodecs: 支持 Probing --> Wasm: 不支持或初始化失败 WebCodecs --> Playing: 关键帧可解码 Wasm --> Playing: Worker 初始化完成 Playing --> WaitingKeyframe: 丢包或配置变化 WaitingKeyframe --> Probing: 新参数集 Playing --> Recovering: 断流或解码错误 Recovering --> Probing: 重建成功 Recovering --> Error: 超过重试预算

探测失败和解码失败是两类信号。前者说明配置不被当前实现接受，后者可能来自 Annex B/长度前缀不匹配、缺失参考帧或坏包。用异常重试代替能力探测会让错误路径反复创建解码器，页面只会越来越卡。

]]>实时视频（一）：RTSP 到浏览器的协议选择https://oldletter.cn/posts/rtsp-browser-01-protocol-options/Sat, 11 Jul 2026 00:00:00 +0000mumuhttps://oldletter.cn/posts/rtsp-browser-01-protocol-options/

系列导航：8 | 9 | 10

浏览器没有通用的 RTSP 播放入口。摄像头的 RTP 负载需要经过协议转换、容器封装或转码，才能交给浏览器的媒体栈。协议选择不能从“哪个库能播放”开始，应从延迟预算、编码格式、网络边界、并发方式和音频要求倒推。

先写延迟预算

端到端延迟可以拆成：

$$L = L_{capture} + L_{encode} + L_{gateway} + L_{network} + L_{buffer} + L_{decode} + L_{render}$$

每一项都要有观测点。只看浏览器缓冲区会漏掉摄像头编码和网关排队。实时云台控制通常需要低延迟和快速恢复，回放或大屏分发更看重 CDN 复用和长连接稳定性。延迟预算写成上限后，协议比较才有可执行标准。

flowchart TD Camera[RTSP 摄像头] --> Pull[服务端拉流与保活] Pull --> RTP[RTP 解包] RTP --> AU[Access Unit] AU --> WebRTC[WebRTC 打包] AU --> FMP4[fMP4 封装] AU --> WS[WebSocket 字节通道] WebRTC --> Browser[浏览器播放] FMP4 --> MSE[MSE] FMP4 --> HLS[LL-HLS] WS --> Decoder[WebCodecs 或 WASM] MSE --> Browser HLS --> Browser Decoder --> Browser

四种下游路径

WebRTC 适合交互预览。它有 ICE、拥塞控制、抖动缓冲和关键帧反馈，工程重点落在信令、TURN、会话权限和媒体服务器。低延迟不等于零延迟，编码 GOP、网络中继和浏览器缓冲仍会影响体验。

]]>