企业官网建设流程全解析

1. 流媒体适配的底层逻辑与方案选型

做过流媒体播放的朋友大概率都经历过这种场景：后端转码服务跑得好好的，日志里切片文件一个不少，m3u8 索引也正常生成，可前端一打开页面，要么黑屏转圈，要么直接报一个MEDIA_ERR_SRC_NOT_SUPPORTED，控制台里连个像样的错误堆栈都不给。折腾半天发现，问题既不在网络，也不在服务器，而是卡在了浏览器对编码格式的支持差异上。这就是 HLS 视频编码兼容性最典型的坑，也是我写这篇实战总结的直接原因。

HLS，全称 HTTP Live Streaming，本质上就是把一整段视频切成一个个小的 TS 或 fMP4 分片，再用一个 m3u8 文本索引把这些分片串起来，播放器按顺序拉取、解码、渲染。它的核心优势是走标准 HTTP 协议，天然穿透各类网络环境，还能根据带宽动态切换不同码率的流。但它的“阿喀琉斯之踵”也很明显：编码格式的兼容性完全取决于播放端（浏览器或原生播放器）的解码能力。服务端只管切，能不能播是客户端的事。

这篇文章面向的是正在做流媒体播放适配的开发者和运维同学，尤其是那些后端用 FFmpeg 转码、前端用 hls.js 或原生 video 标签、移动端用 ExoPlayer 或 Media3 的团队。我会把 H.264 和 H.265 在不同浏览器、不同平台上的支持现状讲透，把常见的排错路径一条条拆开，再给出可以直接抄作业的配置方案。不管你是刚接触流媒体的新手，还是已经踩过几轮坑的老手，应该都能从里面找到对你有用的东西。

1.1 为什么编码格式是 HLS 适配的第一道坎

要理解兼容性问题，得先搞清楚 HLS 播放链路里编码格式到底在哪些环节起作用。一条完整的链路是这样的：采集端拿到原始视频流，转码服务把它编码成 H.264 或 H.265，封装成 TS 或 fMP4 分片，CDN 分发出去，播放器拉取分片后交给底层解码器解码，最后渲染到屏幕上。这里面编码格式决定了分片里的数据长什么样，而解码器决定了播放端能不能读懂这些数据。

H.264（也叫 AVC）是 2003 年定稿的老牌标准，经过二十多年发展，几乎所有能播视频的设备都支持硬解。它的压缩效率放在今天看一般，但胜在兼容性无敌。H.265（也叫 HEVC）是 2013 年推出的下一代标准，同样画质下码率能比 H.264 低 40% 到 50%，对带宽敏感的场景非常友好。但问题在于，H.265 的专利授权体系极其复杂，导致很多浏览器厂商在支持上非常保守，尤其是涉及软件解码的部分。

这就引出了一个关键认知：H.265 在浏览器上的支持，几乎完全依赖硬件解码能力。Chrome 在 Windows 上能不能播 H.265，取决于你的显卡和驱动是否支持 HEVC 硬解，以及操作系统有没有装对应的解码组件。同一台机器，Edge 能播，Chrome 可能就播不了，因为两者的解码策略不同。这种碎片化的支持现状，就是适配工作最大的难点。

1.2 主流浏览器对 H.264 与 H.265 的支持现状

我把目前主流浏览器和平台的支持情况整理成了一张表，这张表是基于我实际测试和公开资料交叉验证的结果，可以作为你选型时的参考基线。

从这张表能看出几个规律。第一，H.264 是真正的通用语言，没有任何一个主流平台会拒绝它。第二，H.265 的支持呈现明显的生态割裂：苹果全家桶最积极，Windows 上的 Edge 表现最好，Chrome 看硬件脸色，Firefox 基本躺平。第三，移动端 Android 的 H.265 支持完全取决于设备芯片，旗舰机基本没问题，中低端机就要打问号了。

提示：不要用“浏览器版本号”来判断 H.265 支持，同一个 Chrome 版本在不同硬件上表现可能完全不同。判断依据应该是运行时的能力检测，而不是静态的版本对照表。

1.3 方案选型的核心权衡：兼容性、带宽与成本

知道了支持现状，接下来就是选型。这里没有标准答案，只有权衡。我一般会从三个维度来考虑：兼容性覆盖范围、带宽成本、转码成本。

如果你的用户群体非常分散，什么设备都有，那 H.264 是唯一稳妥的选择。它的兼容性接近 100%，你不用担心用户打不开。代价是带宽成本高，同样画质下比 H.265 多消耗 40% 左右的流量。对于日活百万级的应用，这个差价可能非常可观。

如果你的用户主要集中在苹果生态，或者你能确定目标设备都支持 H.265 硬解，那用 H.265 能省下大量带宽。但你要做好降级方案，一旦检测到不支持，立刻切回 H.264 流。

最务实的做法是双编码并行：服务端同时转出 H.264 和 H.265 两套流，m3u8 索引里通过CODECS属性标注编码格式，播放端根据自身能力选择。这样既保证了兼容性，又能在支持的设备上省带宽。代价是转码和存储成本翻倍，需要根据业务规模算账。

我在实际项目里更倾向于“H.264 为主，H.265 为辅”的策略：默认走 H.264，检测到设备支持 H.265 且网络条件一般时，再切换到 H.265 流。这样既不会因为兼容性问题丢用户，又能在合适场景下优化体验。

2. HLS 编码参数与分片封装的实操细节

选型定了，接下来就是具体的编码和封装。这一步的细节非常多，一个参数没配对，可能就会导致播放端解析失败。我见过太多案例，视频在本地播放器里好好的，一放到浏览器就出问题，根源往往就在编码参数或封装格式上。

2.1 H.264 编码的关键参数配置

用 FFmpeg 做 H.264 转码，有几个参数是必须关注的。我先给一份经过实战验证的基础配置，然后再逐条解释为什么这么设。

ffmpeg -i input.mp4 \ -c:v libx264 \ -profile:v high \ -level:v 4.1 \ -pix_fmt yuv420p \ -preset medium \ -crf 23 \ -g 48 \ -keyint_min 48 \ -sc_threshold 0 \ -c:a aac \ -b:a 128k \ -ar 44100 \ -ac 2 \ -f hls \ -hls_time 6 \ -hls_playlist_type vod \ -hls_segment_filename "segment_%03d.ts" \ output.m3u8

-profile:v high和-level:v 4.1这两个参数决定了编码的“档次”。High Profile 提供了更好的压缩效率，Level 4.1 则限制了最大码率和分辨率，确保大多数设备能解码。如果你的目标设备比较老，可以降到 Main Profile 和 Level 3.1，兼容性会更好，但压缩效率会下降。

-pix_fmt yuv420p是必须设置的。浏览器对像素格式非常挑剔，如果输出的是 yuv444p 或 yuv422p，很多浏览器直接拒绝播放。yuv420p 是兼容性最好的选择，虽然色彩信息有损失，但肉眼基本看不出来。

-g 48和-keyint_min 48控制关键帧间隔。HLS 分片必须从关键帧开始，所以关键帧间隔要和分片时长匹配。假设视频是 24fps，分片时长 2 秒，那关键帧间隔就应该是 48。如果这个值设得不对，FFmpeg 会在切片时强制插入关键帧，导致码率波动和画质下降。

-sc_threshold 0是关闭场景切换检测。默认情况下，FFmpeg 会在场景切换时插入关键帧，这会打乱我们设定的关键帧间隔，导致分片边界不规整。关掉它，关键帧就会严格按照-g的设定出现。

2.2 H.265 编码的差异化配置与注意事项

H.265 的配置思路和 H.264 类似，但有几个关键差异。首先是编码器选择，libx265 的编码速度比 libx264 慢很多，如果转码量大，需要考虑硬件加速方案。其次是 Profile 的选择，H.265 的 Main Profile 对应 H.264 的 High Profile，Main 10 则支持 10bit 色深。

ffmpeg -i input.mp4 \ -c:v libx265 \ -profile:v main \ -pix_fmt yuv420p \ -preset medium \ -crf 28 \ -g 48 \ -keyint_min 48 \ -sc_threshold 0 \ -tag:v hvc1 \ -c:a aac \ -b:a 128k \ -f hls \ -hls_time 6 \ -hls_playlist_type vod \ -hls_segment_filename "segment_%03d.ts" \ output.m3u8

这里重点说-tag:v hvc1这个参数。H.265 在 MP4 容器里有两个常见的 tag：hvc1和hev1。苹果系的设备（Safari、iOS、macOS）只认 hvc1，如果 tag 是 hev1，Safari 会直接拒绝播放。这个坑我踩过不止一次，明明编码没问题，就是播不了，最后发现是 tag 的问题。所以只要你的目标平台包含苹果设备，这个参数必须加上。

另外，H.265 的 CRF 值一般比 H.264 高 4 到 6，因为它的压缩效率更高。H.264 用 CRF 23 的话，H.265 用 CRF 28 左右能获得相近的画质。但这不是绝对的，具体还要看内容复杂度。

2.3 TS 与 fMP4 分片格式的选择依据

HLS 的分片格式主要有两种：传统的 MPEG-TS 和较新的 fMP4（碎片化 MP4）。两者各有优劣，选择哪个要看你的具体场景。

TS 格式的优点是兼容性极好，几乎所有支持 HLS 的播放器都能播，包括各种老旧的机顶盒和智能电视。缺点是封装开销大，每个分片都有额外的头部信息，而且不支持一些现代编码特性。fMP4 格式的优点是封装效率高，支持更灵活的编码配置，而且和 DASH 协议可以共用分片。缺点是部分老设备不支持。

我的建议是：如果目标设备包含智能电视、机顶盒等传统终端，优先用 TS；如果主要是现代浏览器和移动端，可以用 fMP4。如果拿不准，就用 TS，它的兼容性下限更高。

用 FFmpeg 输出 fMP4 分片的配置如下：

ffmpeg -i input.mp4 \ -c:v libx264 \ -profile:v high \ -pix_fmt yuv420p \ -c:a aac \ -f hls \ -hls_time 6 \ -hls_playlist_type vod \ -hls_segment_type fmp4 \ -hls_fmp4_init_filename "init.mp4" \ -hls_segment_filename "segment_%03d.m4s" \ output.m3u8

注意-hls_segment_type fmp4和-hls_fmp4_init_filename这两个参数，fMP4 格式需要一个初始化分片（init segment），里面包含了解码器配置信息，播放器必须先加载它才能解码后续分片。

2.4 m3u8 索引文件里的编码声明

m3u8 索引文件里的CODECS属性非常重要，它告诉播放器这个流用的是什么编码，播放器据此判断自己能不能播。如果这个属性写错了或者没写，播放器可能会误判，导致本来能播的流播不了。

一个标准的 H.264 m3u8 索引长这样：

#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:6 #EXT-X-PLAYLIST-TYPE:VOD #EXT-X-MAP:URI="init.mp4" #EXTINF:6.000, #EXT-X-BITRATE:1200 segment_000.m4s #EXTINF:6.000, #EXT-X-BITRATE:1200 segment_001.m4s #EXT-X-ENDLIST

如果是多码率自适应流，主索引里会这样标注：

#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=1500000,CODECS="avc1.64001f,mp4a.40.2",RESOLUTION=1280x720 720p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=3000000,CODECS="hvc1.1.6.L93.B0,mp4a.40.2",RESOLUTION=1920x1080 1080p_hevc.m3u8

avc1.64001f是 H.264 High Profile Level 3.1 的编码字符串，hvc1.1.6.L93.B0是 H.265 Main Profile 的编码字符串。播放器读到CODECS后，会调用MediaSource.isTypeSupported()或类似的能力检测接口，判断自己能不能解码。如果不支持，就会跳过这个流，选择其他可用的流。

注意：CODECS字符串必须和实际编码参数完全一致。如果实际编码是 Main Profile，但CODECS写成了 High Profile，播放器可能会误判导致播放失败。这个细节很容易被忽略，但排查起来非常费劲。

3. 浏览器端播放适配的完整实现路径

服务端的流准备好了，接下来就是浏览器端怎么播。这一步是整个链路里最容易出问题的环节，因为浏览器的解码能力差异太大，而且错误信息往往非常模糊。我下面按“能力检测 → 播放器选择 → 错误处理 → 降级策略”的顺序，把完整的实现路径讲清楚。

3.1 播放前的编解码能力检测方法

在决定用哪个流之前，必须先检测当前浏览器能不能解码。最可靠的方法是使用MediaSource.isTypeSupported()接口，传入完整的 MIME 类型字符串，返回布尔值。

function checkCodecSupport(codecString) { const mimeType = `video/mp4; codecs="${codecString}"`; if (typeof MediaSource !== 'undefined' && MediaSource.isTypeSupported) { return MediaSource.isTypeSupported(mimeType); } return false; } // 检测 H.264 High Profile Level 4.1 const h264Supported = checkCodecSupport('avc1.640029'); // 检测 H.265 Main Profile const h265Supported = checkCodecSupport('hvc1.1.6.L93.B0'); console.log('H.264 支持:', h264Supported); console.log('H.265 支持:', h265Supported);

这里有个细节要注意：isTypeSupported的检测结果只代表浏览器声称支持，不代表实际一定能播。有些情况下，浏览器返回 true，但实际解码时因为硬件或驱动问题失败。所以检测之后还要有运行时错误处理兜底。

另外，对于 H.265 的检测，不同浏览器对 codec 字符串的格式要求可能不同。有的认hvc1，有的认hev1，有的两个都认。稳妥的做法是两个都测一遍，只要有一个返回 true 就认为支持。

function checkH265Support() { const variants = [ 'video/mp4; codecs="hvc1.1.6.L93.B0"', 'video/mp4; codecs="hev1.1.6.L93.B0"', 'video/mp4; codecs="hvc1"', 'video/mp4; codecs="hev1"' ]; return variants.some(type => { try { return MediaSource.isTypeSupported(type); } catch (e) { return false; } }); }

3.2 hls.js 与原生 video 标签的选型对比

浏览器端播放 HLS，有两条路：用原生 video 标签直接播，或者用 hls.js 这类 JavaScript 库来播。两者的适用场景完全不同。

Safari 和 iOS 上的原生 video 标签原生支持 HLS，直接设置src为 m3u8 地址就能播，不需要任何库。而且它能利用系统级的硬件解码，性能和功耗都最优。所以在苹果生态里，优先用原生播放。

Chrome、Firefox、Edge 这些浏览器不支持原生 HLS，必须借助 hls.js 或类似库。hls.js 的原理是用 JavaScript 把 TS 分片解析出来，通过 MSE（Media Source Extensions）接口喂给 video 标签。它支持自适应码率切换、错误恢复、字幕等功能，是目前最成熟的方案。

我的选型策略是这样的：

const video = document.getElementById('video'); const videoSrc = 'https://example.com/stream.m3u8'; if (video.canPlayType('application/vnd.apple.mpegurl')) { // Safari 或 iOS，原生支持 HLS video.src = videoSrc; } else if (Hls.isSupported()) { // 其他浏览器，用 hls.js const hls = new Hls({ enableWorker: true, lowLatencyMode: false, maxBufferLength: 30, maxMaxBufferLength: 60 }); hls.loadSource(videoSrc); hls.attachMedia(video); hls.on(Hls.Events.MANIFEST_PARSED, () => { video.play().catch(e => console.log('自动播放被拦截:', e)); }); } else { console.error('当前浏览器不支持 HLS 播放'); }

video.canPlayType('application/vnd.apple.mpegurl')是判断原生 HLS 支持的标准方法。返回"maybe"或"probably"都表示支持。这个方法在 Safari 上返回"maybe"，在 Chrome 上返回空字符串。

3.3 hls.js 的关键配置项与调优

hls.js 的默认配置能应付大部分场景，但在一些特殊情况下需要调优。我挑几个最常调整的参数说说。

maxBufferLength控制缓冲区最大长度，默认 30 秒。如果你的流码率很高，或者用户网络不稳定，可以适当调大，减少卡顿。但调太大也会增加内存占用和起播延迟。

maxMaxBufferLength是缓冲区的硬上限，默认 600 秒。一般不用动，除非你有特殊需求。

enableWorker开启后，hls.js 会把解析工作放到 Web Worker 里，避免阻塞主线程。对于高码率流，建议开启。

lowLatencyMode是低延迟模式，适合直播场景。点播场景不要开，会增加不必要的开销。

fragLoadingMaxRetry和manifestLoadingMaxRetry控制加载失败的重试次数。默认值偏保守，网络环境差的话可以调大。

const hlsConfig = { enableWorker: true, lowLatencyMode: false, maxBufferLength: 30, maxMaxBufferLength: 60, fragLoadingMaxRetry: 6, manifestLoadingMaxRetry: 4, levelLoadingMaxRetry: 4, fragLoadingRetryDelay: 1000, manifestLoadingRetryDelay: 1000, startLevel: -1, // 自动选择起始码率 abrEwmaDefaultEstimate: 500000 // 初始带宽估计 500kbps }; const hls = new Hls(hlsConfig);

startLevel: -1表示自动选择起始码率，hls.js 会根据网络状况选一个合适的。如果你希望固定从某个码率开始，可以设成对应的 level 索引。

abrEwmaDefaultEstimate是初始带宽估计值，影响起播时的码率选择。设得太高会导致起播卡顿，设得太低会导致画质差。500kbps 是个比较稳妥的默认值。

3.4 播放错误的捕获与降级处理

浏览器播放视频出错时，video 元素会触发error事件，但error对象的信息非常有限，只有一个code和message。常见的错误码有这几个：

MEDIA_ERR_DECODE和MEDIA_ERR_SRC_NOT_SUPPORTED是兼容性问题最常触发的两个错误。遇到这两个错误，基本可以确定是编码格式的问题。

hls.js 有自己的错误处理机制，会触发Hls.Events.ERROR事件，错误对象里包含type、details、fatal等信息。fatal: true表示致命错误，播放无法继续，需要降级处理。

hls.on(Hls.Events.ERROR, (event, data) => { console.error('HLS 错误:', data.type, data.details, data.fatal); if (data.fatal) { switch (data.type) { case Hls.ErrorTypes.NETWORK_ERROR: // 网络错误，尝试重新加载 hls.startLoad(); break; case Hls.ErrorTypes.MEDIA_ERROR: // 媒体错误，尝试恢复 hls.recoverMediaError(); break; default: // 无法恢复，销毁并降级 hls.destroy(); fallbackToH264(); break; } } }); function fallbackToH264() { // 切换到 H.264 流 const h264Src = 'https://example.com/stream_h264.m3u8'; if (Hls.isSupported()) { const newHls = new Hls(); newHls.loadSource(h264Src); newHls.attachMedia(video); } else { video.src = h264Src; } }

降级策略的核心思路是：先尝试恢复，恢复不了就换流。recoverMediaError()会尝试重新初始化解码器，对于偶发的解码错误有效。如果是编码格式根本不支持，那就只能换 H.264 流。

实操心得：降级逻辑一定要做，而且要在用户无感知的情况下完成。我见过一些项目，H.265 流播不了就直接报错，用户看到黑屏就流失了。正确的做法是静默切换到 H.264 流，用户最多感觉到画质略有变化，但不会中断观看。

4. 移动端与特殊平台的适配要点

浏览器端的适配讲完了，但流媒体的战场远不止浏览器。移动端的 ExoPlayer/Media3、智能电视、机顶盒，每个平台都有自己的脾气。这一章我重点讲 Android 端的适配，因为这是除浏览器外最常见的场景。

4.1 Android Media3 ExoPlayer 播放 HLS 的配置

Android 上播放 HLS，目前官方推荐的是 Media3 ExoPlayer。它对 HLS 的支持比较完善，但 H.265 的支持仍然依赖设备硬解。配置上需要注意几个点。

首先是依赖引入，Media3 的 HLS 模块是独立的，需要单独引入：

implementation "androidx.media3:media3-exoplayer:1.2.0" implementation "androidx.media3:media3-exoplayer-hls:1.2.0" implementation "androidx.media3:media3-ui:1.2.0"

然后是播放器的创建和配置：

val trackSelector = DefaultTrackSelector(context).apply { setParameters( buildUponParameters() .setMaxVideoSizeSd() .setAllowVideoMixedMimeTypeAdaptiveness(true) .setAllowVideoNonSeamlessAdaptiveness(true) ) } val player = ExoPlayer.Builder(context) .setTrackSelector(trackSelector) .setMediaSourceFactory( DefaultMediaSourceFactory(context).setLiveTargetOffsetMs(5000) ) .build() val mediaItem = MediaItem.fromUri("https://example.com/stream.m3u8") player.setMediaItem(mediaItem) player.prepare() player.play()

setAllowVideoMixedMimeTypeAdaptiveness(true)这个配置很关键。它允许播放器在自适应码率切换时，在不同编码格式的流之间切换。比如从 H.265 流切到 H.264 流，如果这个选项没开，切换会失败。

4.2 设备解码能力查询与流选择

Android 设备的解码能力差异极大，同一个应用在不同手机上表现可能完全不同。所以在选择流之前，必须先查询设备的解码能力。

Media3 提供了MediaCodecInfo接口来查询：

fun isCodecSupported(mimeType: String): Boolean { val codecList = MediaCodecList(MediaCodecList.REGULAR_CODECS) return codecList.codecInfos.any { codecInfo -> !codecInfo.isEncoder && codecInfo.supportedTypes.any { it.equals(mimeType, ignoreCase = true) } } } val h264Supported = isCodecSupported("video/avc") val h265Supported = isCodecSupported("video/hevc") Log.d("CodecCheck", "H.264: $h264Supported, H.265: $h265Supported")

video/avc是 H.264 的 MIME 类型，video/hevc是 H.265 的。查询到支持情况后，就可以决定加载哪个 m3u8 索引。

但要注意，MediaCodecList返回的是设备声称支持的解码器，实际能不能用还要看具体参数。比如设备支持 H.265，但只支持 Main Profile，不支持 Main 10，那 10bit 的 H.265 流还是播不了。所以查询之后，最好再用MediaCodecInfo.CodecCapabilities做更细粒度的判断。

4.3 移动端常见的兼容性坑与规避

移动端的坑比浏览器端更多，我挑几个最典型的说说。

第一个坑是 H.265 的 profile 不匹配。很多设备支持 H.265 Main Profile，但不支持 Main 10。如果你的流是 10bit 编码的，设备会直接报解码错误。规避方法是服务端转码时统一用 8bit，或者准备两套流。

第二个坑是音频编码。HLS 的音频一般是 AAC，但有些设备对 AAC 的 profile 也有要求。LC-AAC 兼容性最好，HE-AAC 虽然省带宽，但部分老设备不支持。如果遇到有画面没声音的情况，先检查音频编码。

第三个坑是分片时长。移动网络不稳定，分片太长容易卡顿，太短又增加请求开销。一般建议 4 到 6 秒，直播场景可以短到 2 秒。但有些设备对分片时长有硬性要求，比如必须能被某个数整除，这个要在实际测试中验证。

第四个坑是 HTTPS 混合内容。如果你的页面是 HTTPS 的，m3u8 和分片也必须是 HTTPS，否则会被浏览器拦截。这个在浏览器端很常见，移动端 WebView 里也一样。

提示：移动端适配一定要在真机上测，模拟器的解码能力和真机差异很大。尤其是 H.265，很多模拟器根本不支持，测了也白测。

5. 典型故障排查实录与速查手册

前面讲了原理和配置，这一章我整理一些实际排查过的案例，把问题现象、排查思路和解决方法列出来，方便你遇到类似问题时快速定位。

5.1 黑屏无报错类问题的排查路径

黑屏是最让人头疼的问题，因为浏览器往往不给任何错误信息。遇到黑屏，我一般按这个顺序排查。

第一步，看控制台有没有报错。如果连MEDIA_ERR_SRC_NOT_SUPPORTED都没有，说明请求可能根本没发出去，或者被拦截了。检查 m3u8 的 URL 是否正确，跨域配置是否允许。

第二步，看网络面板。m3u8 请求返回了吗？分片请求返回了吗？返回的状态码是什么？如果 m3u8 返回 200 但分片返回 404，说明切片路径配置有问题。

第三步，看 m3u8 内容。把 m3u8 下载下来，检查CODECS属性是否正确，分片路径是否可访问。有时候 m3u8 里的路径是相对路径，但实际部署时路径层级变了，导致分片加载失败。

第四步，看编码参数。用ffprobe检查实际编码格式，确认和 m3u8 里声明的一致。重点看 profile、level、pix_fmt 这几个参数。

ffprobe -v error -select_streams v:0 \ -show_entries stream=codec_name,profile,level,pix_fmt,width,height \ -of default=noprint_wrappers=1 input.ts

第五步，用最小化测试。写一个最简单的 HTML 页面，只放一个 video 标签，直接播 m3u8。排除掉业务代码的干扰，看能不能播。如果最小化测试能播，说明问题在业务代码里；如果也不能播，说明是流本身的问题。

5.2 H.265 在 Chrome 上无法播放的定位方法

H.265 在 Chrome 上播不了，是最常见的兼容性问题。定位方法如下。

首先确认 Chrome 版本和操作系统。Chrome 从 107 版本开始支持 H.265 硬解，但需要 Windows 10 以上、显卡支持 HEVC 硬解、并且安装了 HEVC 视频扩展。这三个条件缺一不可。

然后检查MediaSource.isTypeSupported的返回值。如果返回 false，说明 Chrome 认为自己不支持，那就别折腾了，直接降级到 H.264。如果返回 true 但实际播不了，说明是运行时解码失败，需要看具体的错误信息。

在 Chrome 地址栏输入chrome://media-internals，可以看到详细的媒体播放日志。里面会记录解码器的初始化过程、失败原因等信息。这个工具非常有用，但知道的人不多。

还有一个方法是看chrome://gpu，里面会列出当前系统支持的硬件解码格式。如果 HEVC 那一项显示Hardware accelerated，说明支持硬解；如果显示Software only或Disabled，说明不支持。

5.3 常见问题速查表

我把常见的兼容性问题整理成了一张速查表，遇到问题可以先在这里对号入座。

5.4 独家避坑经验分享

最后分享几个我在实际项目中踩过的坑，都是文档里不会写的。

第一个坑：不要迷信isTypeSupported的返回值。有些浏览器返回 true，但实际解码时因为驱动问题失败。所以检测之后一定要有运行时错误处理，不能只靠检测结果。

第二个坑：H.265 的 level 要留余量。比如你的视频是 1080p 30fps，理论上 Level 4.0 就够了，但有些设备对 level 的解析比较严格，建议用 Level 4.1 或更高，留一点余量。

第三个坑：m3u8 的EXT-X-VERSION要匹配。如果用了 fMP4 分片，版本号至少要 7；如果用了EXT-X-MAP，版本号至少要 6。版本号写低了，播放器可能不认某些标签。

第四个坑：CDN 缓存要配置正确。m3u8 索引文件不能缓存太久，否则更新不及时；分片文件可以缓存很久，因为它们是不可变的。如果 CDN 把 m3u8 缓存了，直播场景会出现拉不到最新分片的问题。

第五个坑：测试要覆盖真实设备。我在模拟器上测 H.265 好好的，一到真机就播不了，因为模拟器用的是软件解码，真机用的是硬件解码，两者行为不一致。所以移动端适配一定要在真机上测，而且要覆盖不同品牌、不同价位的设备。

第六个坑：降级逻辑要幂等。如果降级到 H.264 之后还是播不了，不要再无限降级，要有终止条件。我见过一个项目，降级逻辑写成了死循环，用户设备不支持任何格式时，页面直接卡死。

第七个坑：日志要打全。兼容性问题排查最怕信息不足。建议在播放器的关键节点都打上日志，包括能力检测结果、流选择结果、错误事件、降级触发等。这些日志在排查线上问题时非常有用。

我在实际使用中发现，流媒体适配这件事，80% 的问题都出在编码格式和封装格式的细节上，剩下 20% 是网络和配置问题。把编码参数配对，把 m3u8 写对，把降级逻辑做扎实，大部分兼容性问题都能解决。真正难的是那些偶发的、和具体设备相关的边缘情况，这些只能靠充分的测试和完整的日志来覆盖。