17370845950

TV浏览器视频不播放的主因是系统级策略限制与解码兼容性问题：需监听OK键触发play()、绕过canPlayType()、同域部署资源、强制Baseline Profile编码。

TV 浏览器（如三星 Tizen、LG webOS、小米 PatchWall 内置浏览器）本质上是定制化 Chromium 或 WebKit 分支，但对 HTML5 `

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

TV 浏览器的“HTML5 视频不触发”，90% 不是前端代码写错了，而是你把它当成桌面浏览器在调试——它有自己的规则集、自己的策略链、自己的解码底线。最易被忽略的是：**不报错 ≠ 成功，没画面 ≠ 没加载，Promise resolve ≠ 真播放**。