TV浏览器视频不播放的主因是系统级策略限制与解码兼容性问题：需监听OK键触发play()、绕过canPlayType()、同域部署资源、强制Baseline Profile编码。
video 元素加载成功但不触发 play() —— 大多是策略拦截
TV 浏览器普遍启用更严格的自动播放策略：即使加了 autoplay 和 muted，也可能被内核层静默拒绝，且不抛出 DOMException，video.play() 返回的 Promise 直接 pending 或 resolve 空转。
原因在于 TV 系统要求用户必须有明确遥控器“确认”动作（如 OK 键按下）才能激活媒体播放，这是硬性合规要求（防止广告无声自播耗电/扰民）。
实操建议：
- 必须绑定
keydown事件监听keyCode === 13（回车/OK 键），在该回调中调用video.play() - 避免依赖
click：TV 上没有鼠标，click在焦点元素上可能不触发，或延迟极高 - 不要在
DOMContentLoaded或load中直接调用play()，大概率失败且无提示
canPlayType() 返回空字符串，但视频实际能播 —— TV 特定 UA 检测失效
很多 TV 浏览器（尤其老款 Tizen 4.x / webOS 3.x）会篡改 MediaElement.canPlayType() 的返回值，对所有格式统一返回空字符串，导致 JS 逻辑误判“不支持”，跳过加载。这不是 bug，是厂商为简化媒体栈做的主动屏蔽。
实操建议：
- 绕过
canPlayType()判断，直接设置src或插入load() - 监听
loadedmetadata而非canplay：前者表示元数据已解析，可安全调用play()；后者在 TV 上常不触发 - 若需 fallback，用
error事件 +video.error?.code === 4（MEDIA_ERR_SRC_NOT_SUPPORTED）来判断真正不支持
Network 面板显示 200，但 video.readyState 停在 0 —— MIME 或跨域头被 TV 内核忽略
TV 浏览器对响应头的解析比桌面 Chrome 更宽松甚至错误：即使服务端返回了正确的 Content-Type: video/mp4 和 Access-Control-Allow-Origin: *，内核仍可能因内部白名单机制拒绝加载（尤其当视频域名不在 TV 系统预置“可信媒体源”列表中）。
实操建议：
- 把视频资源放在与 HTML 同域下，彻底规避跨域问题（TV 对同域最友好）
- 检查服务器是否返回了
X-Content-Type-Options: nosniff—— TV 内核对此更敏感，可能直接拒解码 - 用
curl -I [video-url]确认响应头，但别只信这个：TV 可能无视你看到的头，按自己规则重写
ffprobe 显示 H.264+AAC，但 TV 黑屏只有声音 —— Profile/Level 不兼容
TV 芯片解码器能力远弱于手机/PC，常见问题不是“不支持 H.264”，而是不支持 Main Profile Level 4.2 以上，或不支持 B-frame、CABAC 等高级特性。此时 readyState 可能卡在 1（HAVE_METADATA），play() 无报错但无画面。
实操建议：
立即学习“前端免费学习笔记（深入）”；
ffmpeg -i input.mp4 \ -c:v libx264 -profile:v baseline -level 3.0 \ -c:a aac -b:a 128k \ -movflags +faststart \ output_tv.mp4
-
-profile:v baseline是关键：确保所有 TV 芯片都能硬解（Tizen 2.4+、webOS 2.0+ 均要求此 profile） - 避免
-x264opts keyint=...类高级参数，TV 解码器不识别 - 用
ffprobe output_tv.mp4验证输出中profile: Constrained Baseline和level: 3.0
