为什么在「手机先看」的传播链路里，团队会专门把 MP4 再压一条 WebM？
移动端分享最怕两件事：一是蜂窝下首包慢，二是 IM 与论坛外链二次压缩把细节抹平。用户常搜「手机 视频 省流量」「外链 mp4 转 webm」「安卓 chrome 播放 webm」「竖屏 视频 体积」——说明运营与增长更关心「点开三秒内能不能动」，而不是容器名本身。WebM 配 VP9 在安卓 Chrome、桌面 Chrome 与多数 Firefox 路线里往往能用更低码率换同等主观观感，对竖屏短视频与落地页英雄区尤其友好。需要诚实交代的是：iOS 与微信内置 WebView 对 WebM 与 Opus 的支持随系统与应用版本变化，正式投放仍建议 `<video>` 里排好 WebM 与 AAC-in-MP4 或 HLS 的顺序，并用真实 iPhone 与安卓中端机各测一遍。另一个常被忽略的点是可变帧率与异常旋转元数据：手机直出 MP4 若未标准化，转 WebM 后可能在某些播放器出现音画漂移，应先在剪辑或相册里统一帧率与方向。把省流策略写进数据看板：对比完播率与跳出率，再决定是否全站默认 WebM 优先。对增长团队而言，最好在实验分组里同时埋点设备型号、系统版本与是否开启省流模式三维标签，才能把格式收益从网络抖动与播放器策略噪声里分离出来。
面向移动分发的 MP4 转 WebM 实操顺序
- 先明确投放渠道是「纯安卓落地页」还是「混合 iOS 与安卓的社媒外链」，再决定默认首包格式；若是混合人群，请在同一母带上并行导出 WebM 与兼容 MP4 并写清 `<source>` 优先级。
- 把宽度压到常见手机安全阅读宽度，帧率对齐素材类型（口播可略降，运动镜头慎降），并在工具里选择对蜂窝友好的码率档位，避免导出后又遭 CDN 再压一遍导致糊成一片。
- 在真实蜂窝网络与目标 IM 内置浏览器里各播十秒，记录首帧时间、卡顿次数与音量；若 iOS 侧无声或黑屏，应回退到 AAC-in-MP4 而不是强迫用户升级系统。
MP4 转 WebM · 移动场景常见问答
为什么在安卓 Chrome 里很顺的 WebM，发到微信对话卡片或朋友圈外链里却可能黑屏或只有画面没有声音，这类问题应优先从编解码白名单还是从容器的二次封装策略排查？
微信内置浏览器与系统播放器对容器与音频编解码的白名单独立于标准 Chrome；应以微信官方文档与实机矩阵为准，常见做法是同时提供 AAC 音轨的 MP4 作为回退，而不是只赌 WebM。
竖屏口播 MP4 在相册里看起来正常，转 WebM 后横竖颠倒或两侧黑边变大，这更可能是旋转元数据未烧录还是工具裁切策略不同？
手机直出常依赖旋转元数据而非像素级旋转；应在导出前在剪辑里执行「真正旋转像素」或统一画幅，再进入 WebM 转换，避免各播放器解释不一致。
同一支六秒贴片，WebM 比 MP4 小一半，是否意味着我可以把内容分发网络计费与移动跳出率目标同时下调一半，还是必须把首包与播放器策略一并纳入实验设计？
体积下降不等于体验线性改善：首包还受 TLS、DNS 与播放器预加载策略影响；应以真实埋点对比 TTFB、首帧与完播，再决定是否扩大 WebM 覆盖范围。
团队想在渐进式 Web 应用离线包里默认放 WebM 以省存储，需要考虑哪些缓存失效、版本迁移与回滚策略细节，才能避免用户长期离线仍命中过期切片？
应为每条媒体资源绑定内容哈希与版本号写入 Service Worker 缓存清单，避免用户离线仍命中过期切片；大版本升级时提供清理旧缓存的迁移提示。
当投放国家包含对加密流量或特定域名拦截较严的地区时，仅缩小 WebM 体积是否足以解决播放失败，还是必须与多区域回源与合规镜像策略一起评估？
播放失败常与域名备案、内容分发网络节点可达性与中间人审查相关，单靠换编码无法解决；应准备多区域回源与合规镜像，并在监控里区分「解码失败」与「网络不可达」。