TV浏览器不支持setSinkId等API，需用MSE+ CMAF分片实现低延迟，依赖后端支持≤200ms分片，并注意各平台兼容性限制。
TV浏览器不支持 HTMLMediaElement.setSinkId 怎么办
TV浏览器（如三星Tizen、LG webOS、Android TV内置浏览器）普遍不支持 setSinkId 或 mediaCapabilities.decodingInfo，这意味着无法通过标准 Web API 动态切换音频输出设备或精确探测解码延迟。所谓“低延迟模式”在TV端不是开关式功能，而是依赖底层播放器策略和媒体加载方式的综合结果。
- 不要尝试在TV浏览器中调用
video.setSinkId—— 大部分会直接抛出NotSupportedError或静默失败 - webOS 6+ 和 Tizen 6.5+ 虽暴露了部分
MediaSource扩展，但未开放低延迟缓冲控制接口（如sourceBuffer.mode = "sequence"也不起作用） - 真正起效的是绕过默认播放器，改用 MSE + 自定义 buffer 策略，但需后端配合提供低延迟分片（如 CMAF chunked encoding）
用 preload="metadata" + autoplay 强制预加载是否有效
在TV浏览器中，preload="metadata" 几乎无效 —— 多数TV系统会忽略该属性，直接走完整加载流程；而盲目加 autoplay 反而可能触发静音拦截（尤其 Android TV Chrome），导致 play() 被拒绝并抛出 NotAllowedError。
- 必须显式绑定用户手势（如遥控器“确认键”点击）后才可调用
video.play()，否则静音状态下无法启动播放 -
preload="none"在部分Tizen机型上反而更可控：手动在canplay事件后调用video.play()，能避开自动加载引发的缓冲抖动 - 实测发现，
video.buffered.end(0)返回值常为0，说明TV浏览器根本不报告真实缓冲范围，不能依赖它做延迟判断
如何用 MediaSource 实现最低可行延迟（CMAF + fMP4）
这是目前TV端唯一可落地的降延路径：绕过原生 的黑盒加载逻辑，接管分片加载与 append 流程。前提是服务端支持 CMAF 封装、chunked transfer encoding，并提供 ≤200ms 的单个 .m4s 分片。
const mediaSource = new MediaSource();
video.src = URL.createObjectURL(mediaSource);
mediaSource.addEventListener('sourceopen', () => {
const sourceBuffer = mediaSource.addSourceBuffer('video/mp4; codecs="avc1.640029"');
// 每次只 append 一个 ~150ms 的 chunk
fetch('/live/chunk-1.m4s')
.then(r => r.arrayBuffer())
.then(buf => {
sourceBuffer.appendBuffer(buf);
// 关键：append 后立即 seek 到末尾，避免缓冲区堆积
video.currentTime = video.duration;
});
});
- 必须设置
sourceBuffer.mode = "segments"（非 "sequence"），否则 Tizen 会报错InvalidStateError - Android TV Chrome 需额外禁用硬件加速：
chrome://flags/#disable-gpu（仅调试用，不可上线） - webOS 上需在
config.xml中声明
为什么 video.playbackRate = 1.01 有时能“感觉更跟手”
这不是真正的低延迟，而是利用人耳对音画同步的容忍窗口（±40ms）制造的错觉。略微超速播放（1.01–1.03x）会让画面提前抵达，抵消部分音频通路延迟，尤其在蓝牙音箱场景下较明显。但副作用是音调升高、长期观看易疲劳。
立即学习“前端免费学习笔记（深入）”；
- 必须在
playing事件之后设置，否则部分TV浏览器会重置为 1.0 - LG webOS 5.x 会静默忽略非整数倍速，仅支持 0.5 / 1.0 / 1.5 / 2.0
- 三星Tizen 5.5+ 支持小数倍速，但需同时设置
video.preservesPitch = false，否则卡顿
