HTML5 播放 MP4 失败主因是封装与编码兼容性不足：MP4 为容器，需 H.264+AAC 组合（全浏览器支持），H.265 仅 Safari 原生支持，AV1 新版 Chrome/Firefox/Edge 支持但 Safari 有限；须用 ffmpeg 加 -movflags +faststart 确保 moov 在前，并正确声明 source 的 codecs 类型，服务端需支持 byte-range 和合理缓存。
HTML5
不是所有 MP4 都能直接被 播放，核心在于封装格式（container）和编码格式（codec）是否被浏览器支持。MP4 只是容器，里面可能装 H.264、H.265、AV1 编码的视频，以及 AAC、MP3、Opus 等音频——而浏览器只认其中一部分组合。
常见错误现象：VIDEO_ERROR_DECODE、MediaError.MEDIA_ERR_SRC_NOT_SUPPORTED、静音/黑屏但无报错、进度条不可拖拽（因缺失关键帧索引）。
- H.264 + AAC 是目前兼容性最好的组合，Chrome/Firefox/Safari/Edge 全支持
- H.265（HEVC）仅 Safari 原生支持，Chrome 和 Firefox 默认不支持（需手动启用或依赖系统解码器）
- AV1 视频在 Chrome 109+、Firefox 108+、Edge 110+ 支持，但 Safari 目前仍不支持（iOS 17.4 开始有限支持）
- MP4 文件若缺少
moovbox（尤其是放在文件末尾），会导致无法流式加载或拖拽失败
用 ffmpeg 生成兼容 HTML5 的 MP4
别直接上传剪辑软件导出的 MP4——它大概率没做 Web 适配。必须重编码并确保关键元数据前置。
推荐命令（H.264 + AAC，moov 移到开头）：
立即学习“前端免费学习笔记（深入）”；
ffmpeg -i input.mp4 -c:v libx264 -profile:v baseline -level 3.0 -c:a aac -b:a 128k -movflags +faststart output.mp4
-
-profile:v baseline和-level 3.0提升老旧设备兼容性（如 iOS 6+、Android 4.0+） -
-movflags +faststart把moovbox 搬到文件开头，否则浏览器得下载完整文件才能开始播放 - 避免使用
-crf 18等高画质参数而不设-maxrate，容易导致码率突增、卡顿 - 如果源是 HDR 或高帧率（>60fps），浏览器可能静音或跳帧，建议先转为 SDR + 30/60fps
多个 MP4 格式怎么让浏览器自动选一个
用 type 属性必须准确，否则浏览器会跳过整个 。
正确写法示例：
-
type中的codecs值必须与实际编码严格匹配，大小写敏感；可用ffprobe -v quiet -show_entries stream=codec_name,codec_tag_string video.mp4查看真实值 - 浏览器按
- 不要写
type="video/mp4"而不带codecs，这等于没声明编码能力，多数浏览器会忽略 - Safari 对
avc1的 profile/level 标注很敏感，写成avc1.64001F（High@5.1）可能被拒，降为avc1.42E01E（Baseline@3.0）更稳
CDN 或服务端要配合做什么
即使文件本身合规，服务端配置不对，照样播不了。重点在 HTTP 响应头和字节范围支持。
- 必须返回
Accept-Ranges: bytes，否则 Safari 和部分安卓 WebView 无法拖拽或起播延迟极高 - 确保 CDN 开启 byte-range 请求支持（Cloudflare 默认开，AWS S3 静态托管也默认支持）
- 避免给 MP4 加
Cache-Control: no-cache，重复请求会浪费流量；合理用immutable+ 长期缓存（如max-age=31536000） - 如果走自建服务（如 Nginx），确认已启用
sendfile on;和tcp_nopush on;，这对大文件流式传输有实际影响
真正麻烦的从来不是“能不能播”，而是“为什么在 A 设备上能，在 B 设备上点一下就报错”。每个 MP4 文件背后都有编码参数、元数据位置、服务响应、客户端解码器四层耦合——漏掉任何一层，用户看到的都只是个静止的 poster 图。
