MediaSource.isTypeSupported() 是验证浏览器是否支持特定编码的最轻量可靠方法，需传入完整 MIME + 编码字符串（如 "video/mp4; codecs=\"avc1.64001f\""），返回 true 仅表示“可能支持”，实际播放还受硬件、驱动等限制。
用 MediaSource.isTypeSupported() 判断编码是否被浏览器支持
浏览器本身不提供直接读取视频文件编码格式（如 avc1.64001f、mp4a.40.2）的 API，但可以通过 MediaSource.isTypeSupported() 检查某类 MIME 类型 + 编码字符串是否能被当前环境解码。这是最轻量、最可靠的第一步验证。
- 它只接受完整 MIME + 编码字符串，例如
"video/mp4; codecs=\"avc1.64001f\""或"audio/mp4; codecs=\"mp4a.40.2\"" - 返回
true仅表示“可能支持”，不代表该视频一定能播——实际解码还依赖硬件、驱动、系统限制 - 对 HLS 或 MSE 动态加载场景，必须在创建
MediaSource实例前调用，且不能跨源调用（CORS 会拦截）
从 MP4 文件头解析 avcC 和 esds Box 获取编码细节
如果已知视频是 MP4（或 MOV、M4A），可借助 FileReader 读取前几 KB，手动解析容器中的编码描述信息。MP4 的视频编码信息藏在 avcC box（H.264/AVC）或 hvcC box（H.265/HEVC）里；音频则在 esds（AAC）或 dac3（AC3）中。
- 需按字节读取，跳过
ftyp、moov等 header，定位到具体 box 起始位置 -
avcC中第 5 字节是 profile_idc，后续字节含 level、sps/pps 原始数据，可推导出标准编码字符串如"avc1.64001f" - 纯前端解析有精度限制：无法区分 Baseline/High Profile 下的某些子集，也难处理 fragmented MP4
const parseAvccBox = (bytes) => {
// 假设 bytes 是 Uint8Array，已定位到 avcC box payload 起始
const profile = bytes[1];
const level = bytes[3];
const naluLengthSize = (bytes[4] & 3) + 1; // 1, 2 or 4
return `avc1.${profile.toString(16).padStart(2, '0')}${level.toString(16).padStart(2, '0')}00`;
};
用 canPlayType() 辅助推测主编码类型
HTMLMediaElement.canPlayType() 不返回具体编码，但能快速排除明显不兼容的格式，比如 video.canPlayType("video/webm; codecs=\"vp9\"") 返回 "probably" 就说明 VP9 解码链大概率就绪。
- 它对
codecs参数敏感，引号必须存在，空格不能省略，大小写部分影响结果（如"avc1.64001f"和"AVC1.64001F"可能不同） - 返回值只有
""、"maybe"、"probably"，没有中间状态，也不反映当前 video 元素加载的是什么文件 - 适合做播放前快速兜底判断，不适合用于分析已加载视频的实际编码
服务端解析仍是获取准确编码信息的首选方案
前端 JS 无法可靠提取完整编码参数（如 H.264 的 CABAC 开关、色度采样、bit depth），也无法识别 DRM 加密流或自定义封装格式。真正需要精确信息（比如转码决策、CDN 分发策略、合规性检查），必须由服务端完成解析。
立即学习“前端免费学习笔记（深入）”；
- 推荐工具：FFmpeg（
ffprobe -v quiet -show_entries stream=codec_name,width,height,profile,level -of json） - 前端可发起一次轻量请求，传入视频 URL，后端返回结构化编码信息 JSON
- 注意避免跨域问题：后端需正确设置
Access-Control-Allow-Origin，且视频资源本身也要允许跨域（CrossOrigin="anonymous"）
编码字符串里的每个数字都有含义，比如 avc1.64001f 中的 1f 是 level_idc（31 → Level 3.1），但浏览器不会告诉你这个映射关系——靠 JS 硬猜容易错，尤其遇到新编码如 AV1 的 av01.0.05M.08，字段含义完全不同。
