TV浏览器视频卡顿主因是解码能力、资源加载策略与系统限制叠加，非video标签错误；需moov前置、服务端支持Range、禁用autoplay、手动触发play()并真机调试。
video 标签在 TV 浏览器里卡，真不是标签写错了
TV 浏览器（如飞视浏览器领先版 TV 版）播放 HTML5 视频卡顿，90% 以上和 标签本身无关，而是底层解码能力、资源加载策略与 TV 系统限制三者叠加的结果。桌面 Chrome 能播流畅，不等于 TV 上能跑通——iOS Safari 限 Level 3.1、Android TV 各厂商硬解模块差异大、WebOS/Tizen 对 MSE 支持残缺，都是默认“不兼容”的现实。
moov 头没前置 + 没开 Range 请求 = TV 上必卡首帧
TV 浏览器普遍不支持完整文件预加载，一旦 video.mp4 的 moov 头在文件末尾，就必须等整个文件下载完才能解析元数据，首帧延迟动辄 5–10 秒；更糟的是，若服务端未返回 206 Partial Content，MediaSource Extensions (MSE) 直接失效，分片加载无从谈起。
- 用
ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4强制把moov移到开头 - Nginx/Apache 必须开启
Accept-Ranges: bytes响应头（Nginx 默认已开，但某些定制固件会关） - 验证方式：用
curl -I http://your.tv.site/video.mp4查看是否含Accept-Ranges: bytes
autoplay 和 preload="auto" 在 TV 上基本是摆设
TV 浏览器几乎全部遵循严格用户手势策略：没遥控器按键事件触发，video.play() 会静音失败；preload="auto" 在多数 TV UA（如 WebOS 6+、Tizen 6.5）中被忽略，根本不会提前拉流。真正影响首帧的是：poster 图像尺寸、关键帧间隔、以及是否启用异步解码。
-
poster图片建议 ≤1280×720，超大会阻塞渲染线程（尤其内存小的低端电视） -
编码时设置 keyframe interval ≤
2s（即-g 48@24fps），否则拖动后黑屏明显 - Chromium 内核 TV 浏览器可加
decoding="async"属性缓解主线程压力：
硬件加速开关 ≠ 打开就更好
TV 设备 GPU 驱动老旧、YUV 转 RGB 渲染路径异常、或显存带宽不足时，“开硬件加速”反而导致画面撕裂、绿屏、或卡死在第一帧。QQ 浏览器 TV 版、飞视浏览器等都出现过类似问题，关闭后切回软件解码反而稳定。
立即学习“前端免费学习笔记（深入）”；
- 进入浏览器设置 → 找到「高级」或「实验室功能」→ 关闭
硬件加速 - 重启浏览器后，用
chrome://media-internals（若支持）查pipeline_state是否卡在kPlaying或反复kSeeking - 注意：部分 TV 浏览器（如 Tizen）不暴露
chrome://页面，只能靠日志或外接 ADB 抓logcat
TV 端 HTML5 播放不是“换个属性就行”的事，它卡在编码、传输、解码、渲染四层交界处，而每一层在不同 TV 平台上的行为都不一致。最稳妥的做法是：固定 H.264 Main@3.1 + AAC 编码、moov 前置、服务端支持 Range、禁用 autoplay、手动监听 canplay 后再 play()，并始终用真机调试——模拟器永远看不出 YUV 采样错位或音频时钟漂移。
