TV浏览器无画质调节界面，所谓“提升HTML5画质”实为绕过默认解码策略，强制启用高规格硬解，效果依赖芯片平台与系统定制；video标签加playsinline无效，videoWidth/Height常返回0，禁用--disable-accelerated-video-decode等flag才可能生效。
TV 浏览器本身不提供“画质调节”界面，所谓“提升 HTML5 画质”，本质是绕过默认的视频解码/渲染策略，通过修改底层参数强制启用更高规格的解码能力或禁用降级逻辑。实际效果高度依赖芯片平台（如 Amlogic、Realtek、MTK）和 TV 系统定制程度，多数情况下仅对特定型号有效。
video 标签加 playsinline 和 webkit-playsinline 不起作用？
TV 浏览器（尤其是基于旧版 Chromium 的定制内核）常忽略移动端常用的内联播放属性。即使加上这些属性，视频仍可能被强制全屏、硬解失败或 fallback 到软解导致模糊。
- 确认 TV 浏览器是否支持
HTMLMediaElement.videoWidth/videoHeight—— 若始终返回 0，说明 video 元素未真实绑定解码器输出 - 避免使用
object-fit: cover拉伸画面，TV 端 GPU 缩放质量极差；优先用原生分辨率容器 + CSSimage-rendering: pixelated抑制插值 - 部分机型需在
上显式设置width和height属性（非 CSS），否则触发降级渲染管线
Chrome Flags 在 TV 浏览器里怎么生效？
绝大多数 TV 浏览器禁用了 chrome://flags 页面，但部分基于 Chromium 80+ 的系统（如某些 Android TV 定制 ROM）允许通过启动参数注入 flag。关键不是“开启什么”，而是“关闭哪些默认限制”。
- 必须禁用的降级开关：
--disable-accelerated-video-decode（强制启用硬解）、--disable-gpu-driver-bug-workarounds（绕过厂商屏蔽高分辨率解码的 bug 适配） - 可选增强：
--enable-features=CanvasOopRasterization,UseSkiaRenderer（提升 Canvas 渲染精度，对 WebRTC 或 WebGL 合成视频有帮助） - flag 无法通过网页 JS 注入，需由 TV 系统管理员修改浏览器启动脚本（路径类似
/system/etc/init.d/99browser或/data/local/tmp/chrome-start.sh）
MediaSource + video.webkitDecodedFrameCount 能否判断硬解状态？
不能直接判断，但可作为辅助信号。TV 浏览器中 webkitDecodedFrameCount 常恒为 0 或增长异常缓慢，不代表没硬解，只说明该字段未被正确上报。
立即学习“前端免费学习笔记（深入）”；
const mediaSource = new MediaSource();
video.src = URL.createObjectURL(mediaSource);
mediaSource.addEventListener('sourceopen', () => {
// 即使硬解开启，以下日志也可能无变化
setInterval(() => {
console.log('decoded:', video.webkitDecodedFrameCount, 'width:', video.videoWidth);
}, 1000);
});
- 更可靠的方式：监听
loadedmetadata后检查video.videoWidth >= 1280且video.readyState === 4，再结合performance.memory.totalJSHeapSize突增（软解典型特征）交叉验证 - 若
video.getVideoPlaybackQuality()返回空对象，说明浏览器未实现该 API —— 大概率处于阉割硬解状态 - 某些 MTK 方案 TV 会伪造
videoWidth，需配合canvas.getContext('2d').drawImage(video, ...)后读取 canvas 像素验证真实分辨率
真正起效的“提画质”操作，往往发生在系统层而非网页层：比如替换 /vendor/lib/egl/libGLES_mali.so（针对 Mali GPU）或 patch libstagefright.so 中的 profile-level 限制。网页能做的只是尽量不触发降级，而不是主动提升。
