先判断是哪一种问题
“H.265 播放不了”通常混在一起说，实际至少要分成三类：
- 黑屏：播放请求已发出，但浏览器没有得到可解码的视频，或根本没有收到媒体数据。
- 花屏、绿屏：已经收到视频，但参考帧、关键帧、分片或解码路径有异常。
- 首帧慢：最后能够播放，只是等待关键帧、协议握手、探测或转码启动的时间过长。
先确定症状，再看浏览器控制台、网关日志和源流信息，比直接更换播放器更容易找到原因。
第一步先验证输入码流
用能够显示详细媒体信息的播放器或探测工具直接打开 RTSP / RTMP 源，确认编码确实是 H.265，并记录分辨率、帧率、码率、GOP、音频编码和时间戳。主码流能播放，还应继续检查子码流；不少摄像头的两路编码配置并不相同。
如果源流本身就会丢帧、时间戳跳变或长时间没有关键帧，网页端通常只会把问题放大。此时应先调整摄像头编码参数或检查网络，不要把故障归到 WebRTC、HLS 或播放器上。
为什么同一路 H.265 在不同浏览器表现不同
浏览器能否播放 H.265，取决于操作系统提供的解码能力、浏览器版本、硬件与驱动、封装和实际输出协议。某台电脑能播，不代表所有 Windows、macOS、Android 或移动浏览器都能播。
面向普通办公电脑和多种终端时，H.264 仍是更稳妥的兼容基线。摄像头可以保留 H.265 主码流用于高画质录像，同时提供 H.264 子码流用于网页预览；如果设备无法同时输出合适的子码流，再考虑由网关转码。
黑屏时按媒体链路逐段检查
- 浏览器是否成功建立 WebRTC、HTTP-FLV / WS-FLV 或 HLS 请求。
- 网关是否已经拉到源流，视频包和码率是否持续增长。
- 输出中是否包含浏览器可接受的视频编码和必要的参数集。
- HTTPS、证书、ICE、端口和防火墙是否让媒体真正到达浏览器。
- 换用 H.264 子码流后是否立即恢复。
如果 H.264 正常、H.265 黑屏，优先检查浏览器解码兼容和输出策略；如果两者都黑屏，应先回到地址、认证、网络和媒体会话。
花屏通常与关键帧和丢包有关
H.265 解码依赖前后参考关系。刚加入播放时没有拿到完整关键帧、网络丢包造成重要分片缺失，或摄像头输出不规范，都可能表现为短暂花屏或持续绿屏。
可以缩短摄像头 GOP 后复测，观察是否总在等待下一个关键帧时恢复；同时对比局域网直连和跨网链路。如果直连稳定、跨网异常，就要继续检查丢包、抖动、MTU、传输缓冲和中间转发。
首帧慢要分别看等待发生在哪里
首帧时间通常由连接建立、源流探测、等待关键帧、转码器启动和播放器缓冲共同组成。建议分别记录“请求发出—网关收到首包”“网关收到首包—输出首个可解码帧”“浏览器收到数据—画面呈现”三个阶段。
GOP 过长时，新加入的播放器可能需要等待数秒。把关键帧间隔调整到适合预览的范围，通常比一味缩短播放器缓冲更有效。若启用了 H.265 转 H.264，还要把转码初始化时间和服务器负载单独记录。
什么时候用网关转码，什么时候保留原码流
终端环境可控、客户端具备 H.265 解码能力时，可以保留原码流，减少转码带来的算力消耗和画质损失。面向浏览器、低配办公电脑或多种移动终端时，可优先使用 H.264 子码流；只有设备侧无法提供合适输出时，再启用 H.265 转 H.264。
StreamGate 适合统一接入摄像头和 NVR，并为网页端选择 WebRTC、HTTP-FLV / WS-FLV 或 HLS 输出。需要把播放、硬件解码和低延迟参数直接嵌入桌面端或移动端软件时，则可使用 StreamCore SDK 在目标终端上验证。
上线前的验证清单
- 准备同一设备的 H.264、H.265 主码流和子码流。
- 覆盖实际使用的浏览器、操作系统、显卡和驱动。
- 分别验证单画面、4/9/16 分屏、录像并行和长时间播放。
- 记录首包、首帧、稳定播放、重连和延迟漂移，不只看一次截图。
- 确认当前走原码流、子码流还是转码输出，并能从日志或运行状态中判断。
- 出现异常时保留源流信息、浏览器控制台、网关日志和复现时间。