这些能力经常被混在一起
客户经常同时问：是否支持 H.265，是否支持 WebRTC，是否支持硬件解码，是否低延迟。它们都和播放体验有关，但不是同一个层面的能力。
H.264/H.265 是视频编码格式；WebRTC 是浏览器低延迟传输和播放链路；硬件解码是用 GPU/SoC 加速解码；硬件转码是把一路码流转换成另一种编码、分辨率或码率；低延迟则同时受协议、缓冲、解码、网络和渲染影响。
H.264 和 H.265
H.264 兼容性最好，摄像头、浏览器、移动端和硬件解码支持都更广。H.265 压缩率更高，同码率画质更好或同画质码率更低，但浏览器和部分老设备的支持更复杂。
私有化项目里，H.265 常见于摄像头主码流和高分辨率录像。选型时应确认输入是否为 H.265、是否需要浏览器播放、是否需要转码，以及目标服务器是否具备硬件能力。
WebRTC
WebRTC 适合低延迟浏览器播放、值守大屏和需要快速响应的预览场景。它不是简单的视频编码格式，而是一套浏览器实时通信链路。部署时要关注 HTTPS、证书、端口、NAT、浏览器版本和网络路径。
硬件解码与硬件转码
硬件解码用于降低播放侧 CPU 压力，尤其是多路预览或高分辨率码流。硬件转码用于把 H.265 转 H.264、改变分辨率或码率、生成更适合浏览器播放的输出。
硬件能力和部署机器强相关。NVIDIA、Intel、AMD、嵌入式 SoC、国产/ARM 平台的驱动、系统接口和编解码支持都不同。选型时可以明确关注硬件解码和硬件转码能力，同时在目标机器上验证实际路径、并发能力和稳定性。
对 SDK 和网关的意义
StreamCore SDK 里，这些能力影响客户软件如何播放、渲染、推流和处理回调。StreamGate 里，这些能力影响现场网关能否更高效地预览、转码、分发和录像。
项目确认清单
- 输入码流是 H.264 还是 H.265。
- 浏览器端要看实时预览、录像回放还是低延迟大屏。
- 是否需要 WebRTC、HLS、FLV 或播放地址对接。
- 服务器是否有可用 GPU/硬件编解码后端。
- 多路预览、录像、转码和上级平台调看是否同时发生。
- SDK 包、StreamGate 标准版或专业版运行包是否在目标机器上验证过真实码流。
能力与现场验证
H.264、H.265、WebRTC 和硬件解码都可以作为产品能力评估，但现场效果还需要结合目标浏览器、显卡、驱动、系统版本、码流规格和并发负载确认。这样既能看清能力覆盖，也能避免把设备或环境差异误判为软件问题。
H.265 项目要重点验证什么
H.265 常见于高分辨率摄像头和需要节省带宽的场景。验收时应检查输入流编码、解码路径、CPU/GPU 占用、长时间播放稳定性、录像回放、截图和异常流恢复。若目标浏览器不能直接播放 H.265，应通过网关或客户端能力选择合适输出。
硬件解码不是单一开关
硬件解码通常受系统、驱动、显卡、像素格式、分辨率和并发路数影响。工程上更可靠的做法是提供软件解码兜底、运行状态指标和日志，便于现场判断当前使用的是硬件路径还是软件路径。
H.265 与硬件解码的工程价值
H.265 能在相近画质下降低码率，对多路摄像头预览、录像存储和弱网传输都有价值。硬件解码能降低 CPU 压力，让桌面端、服务器端或部分移动端在多画面预览时更稳定。评估产品能力时，应同时关注 H.264 / H.265、WebRTC、硬件解码、低延迟调优，以及目标平台上的实际验证结果。
对 StreamGate 来说，H.264/H.265、浏览器播放、录像回放和转码能力应与版本权益保持一致；对 StreamCore SDK 来说，解码能力应和平台包、增强包、硬件驱动和 Demo 验证结果对应。用户真正关心的是能否在目标系统上跑通，而不是底层组件如何组合。