HTML5 <video> 标签本身不决定硬件解码是否启用,但其属性(如playsinline、preload="auto"、autoplay+muted)、<source>配置及加载方式会显著影响浏览器是否选择硬件解码通路;canPlayType()返回"probably"仅表示语法支持,非实际硬解能力,需用MediaCapabilities.decodingInfo()实测验证。
HTML5 <video> 标签本身不决定硬件解码是否启用,但它的属性、<source> 配置和加载方式,会显著影响浏览器是否选择走硬件解码通路——不是“能不能”,而是“愿不愿意”。
<video> 属性会触发硬解判断浏览器把 <video> 的某些属性当作“是否值得提前初始化 GPU 解码器”的信号,不是开关,是提示:
playsinline:iOS Safari 必须存在,才可能对 H.264 MP4 启用硬解;缺失时大概率 fallback 到软解或静音拦截preload="auto":比 metadata 更早触发解码器初始化(尤其 Chrome/Edge),但会增加首屏流量;none 则几乎必然延迟硬解建立autoplay + muted:静音自动播放更容易让浏览器在页面加载阶段就拉起硬解通道;有声 autoplay 常被拦截,导致解码器延迟启动甚至不启动width/height 设为小数,或用 transform: scale() 缩放:部分 Intel 核显、旧 Android GPU 驱动会在非整数分辨率下主动禁用硬解canPlayType() 返回 "probably" 就代表能硬解吗不。它只说明浏览器“语法上认识这个编码字符串”,和实际解码能力无关:
video.canPlayType('video/mp4; codecs="avc1.64001f"') 返回 "probably",只表示支持 Level 4.1 以下的 H.264 Baseline/Main ProfileMediaCapabilities.decodingInfo(),例如:navigator.mediaCapabilities.decodingInfo({type: 'media-source', video: {contentType: 'video/mp4; codecs="avc1.64001f"', width: 1920, height: 1080, bitrate: 4000000, framerate: 30}})
<source> 插入前就完成判断;需配合 preload="none" 和 JS 控制流<source> 写对了因为硬解支持不是“写对标签就生效”,而是浏览器+系统+硬件三重许可:
立即学习“前端免费学习笔记(深入)”;
hvc1.1.2.L153.B0)开箱即用的主流浏览器;Chrome 默认禁用 HEVC,即使系统装了 Microsoft HEVC 扩展,也常因版权策略不启用av01.0.05M.08)在桌面 Chrome/Firefox 已支持硬解,但移动端仅 Pixel 6+/iOS 17.4+ 有限支持;误标会导致 canPlayType() 返回 "maybe",加载后直接黑屏chrome://media-internals 里看到 ffmpeg_video_decoder 不一定等于软解——Chrome 会把它桥接到 VAAPI,得看 hardware_accelerated: true 字段loadedmetadata 和 error,不能只信 canPlayType()
没有统一 API,但可交叉验证:
chrome://media-internals,播放后点开对应 player_id,重点看 video_decoder_name 和 pipeline_state;mojo_video_decoder + hardware_accelerated: true 才算真硬解VideoProc 进程 CPU 占用;或终端运行 sudo powermetrics --samplers gpu_power | grep -i decoder
vainfo 确认 VAAPI 就绪,再用 intel_gpu_top 观察 Video 引擎负载真正容易被忽略的是:即使硬解启用,若视频含大量 B-frame、分辨率超 GPU 解码上限(如核显不支持 4:2:2 10bit)、或驱动未开启节能模式,浏览器也会静默回落到软解——你根本看不到报错,只看到 CPU 占用飙高、发热、续航变短。