HLS 三方案对比

TS·200+Range、JPG·206、JPG·200 三列并排。Android 上 hls.js 目前 JPG·200 也很快，暂时保留；差异主要在 iOS，可用 Range / Seek 测试验证。

结论：Android 走 hls.js（MSE），目前 JPG·200 使用 HLS 也能做到很快，暂时保留。只对 iOS 做区分：AVPlayer 接管不走 hls.js，JPG·200 能播但 Seek 易卡死。

  • 待测试iOS 上 JPG·206 表现如何？（Range、Seek）
  • 待思考以 iPhone 为主是否应使用 TS·200+Range？

标准 TS · 200+Range

标准 HLS，无 Range 时 200 整段；有 Range 时 206 按需拉取。

  • 分片后缀：.ts
  • Content-Type：video/mp2t
  • HTTP 状态码：200 OK（无 Range）/ 206（有 Range）
  • Android：hls.js Range 按需，Seek 实测很快
  • Content-Range：有 Range 请求时返回

/hls/index.m3u8

引擎：检测中…

伪装 JPG · 206

均衡方案：外观为图片资源，同时支持 Range 按需传输。

  • 分片后缀：.jpg
  • Content-Type：image/jpeg
  • HTTP 状态码：206 Partial Content
  • Android：hls.js Range 按需，Seek 实测很快
  • Content-Range：有（伪装 + 按需传输）

/hls-jpg-206/index.m3u8

引擎：检测中…

伪装 JPG · 200

纯伪装方案，忽略 Range，整文件返回。

  • 分片后缀：.jpg
  • Content-Type：image/jpeg
  • HTTP 状态码：200 OK
  • Android：hls.js 实测也很快，暂时保留
  • iOS：AVPlayer 能播，但 Seek 极易卡死
  • Content-Range：无（整文件返回）

/hls-jpg/index.m3u8

引擎：检测中…

方案优劣对比

两列对比极端方案：标准 TS·200+Range vs 纯伪装 JPG·200。Range 按需传输的核心优势是起播更快、省 CDN 带宽费用。 兼顾伪装与性能见下方「最佳建议」。

标准 HLS · TS · 200+Range

优势

  • 起播更快：Seek / 弱网下只拉需要的数据，首帧等待时间更短
  • 省 CDN 费用：CDN 按流量计费，206 避免整段重传，带宽账单更低
  • 支持 HTTP Range，按需传输
  • CDN 生态成熟，语义规范

缺点

  • .ts、video/mp2t 易被识别拦截
  • 无法伪装成图片资源

纯伪装 · JPG · 200

优势

  • 外观像图片，实现最简单
  • 可能绕过只拦视频的策略
  • 顺序播放与 206 方案接近

缺点

  • 无视 Range，要 1KB 仍下整段
  • iOS Seek 易卡死：AVPlayer 实测能播，拖动进度条极易无响应
  • CDN 费用高：无效流量计入账单
按场景选择
场景更优方案原因
起播速度（弱网 / Seek）TS·200+Range只拉首段所需字节，等待时间更短，首帧更快
CDN / 源站带宽费用TS·200+Range按字节计费时少传无效数据，流量账单显著更低
从头顺序播放、好网络差不多都要拉完整分片，解码相同，体验接近
Seek / 拖动进度条TS·200+Range支持 Range，可按需拉取，少传无效字节
弱网（1–5 Mbps）TS·200+Range传输量差异被放大，起播与 Seek 明显更快
省流量 / 移动网络TS·200+Range避免「只要 1KB 却下整段」的浪费
需绕过视频流检测JPG·200URL 与 MIME 呈现为图片资源（但牺牲 Range 优势）
iOS Safari（AVPlayer 接管）待思考JPG·200 实测能播但 Seek 易卡死；JPG·206 待测试；是否用 TS·200+Range 待思考
标准 CDN 商业分发TS·200+Range生态成熟，符合 HTTP / HLS 规范
如何在本页验证：播放性能相近是正常的（同一份 H.264）。点击上方 Range / Seek 测试，对比状态码、Content-Type、实际下载量；或在 DevTools → Network 查看分片 Response Headers。

最佳建议 · JPG · 206（均衡方案）

若既要绕过视频检测，又要 206 的传输优势，推荐采用此方案。

为什么推荐

  • 兼顾起播更快、省 CDN 费用（同 206 按需传输）
  • 外观像图片（.jpg + image/jpeg），可绕过视频流检测
  • Android hls.js 实测：Range 按需 + Seek 很快
  • 比 JPG·200 少传无效流量，弱网 / Seek 体验明显更好
  • 比 TS·200+Range 多一层伪装，适合受限网络环境

需注意

  • 206 + 图片 MIME 可能被严格审计怀疑
  • 内容非真 JPEG，无法用 img 标签直接展示
  • 标准商用 CDN 场景仍优先 TS·200+Range
  • iOS 上 JPG·200 实测能播，但 Seek 极易卡死；JPG·206 见下方说明
结论：上方中间播放器即为 JPG·206 实测。对比表只列 TS·200+Range 与 JPG·200 两极端；实际落地时，JPG·206 往往是更均衡的选择。

Android · hls.js 按需加载

Android Chrome / WebView 上 Hls.isSupported() 为 true，由 hls.js + MSE 接管播放。 配合 Range 方案可按需拉分片，Seek 只下载目标段所需数据，实测非常快。

配置Android hls.js说明
TS·200+Range + hls.js✅ 按需 + Seek 快hls.js 发 Range 请求，服务端 206 按需返回；起播与拖动进度条均只拉必要字节，实测 Seek 很快
JPG·206 + hls.js✅ 按需 + Seek 快同 TS·200+Range 的 Range 能力，外加 .jpg + image/jpeg 伪装；Android 落地首选均衡方案
JPG·200 + hls.js✅ 能播，实测也快hls.js 可解析 H.264，Android 上起播与 Seek 实测表现可接受，暂时保留；与 iOS AVPlayer 路径区分对待
落地建议：Android 统一走 hls.js，JPG·200 暂时保留；需 Range 按需或伪装时再考虑 TS·200+Range / JPG·206。差异主要在 iOS，见下方说明。

iOS WebKit / AVPlayer 兼容性

iPhone Safari 上 Hls.isSupported() 通常为 false，播放器会回退为 video.src = m3u8，由 原生 AVPlayer 接管——不会走 hls.js。 桌面 Chrome 的 hls.js 测通，不能代表 iOS 表现。

配置iOS AVPlayer（实际路径）说明Apple 文档
标准 .ts + video/mp2t + 200+Range✅ 最稳AVPlayer 原生解析 TS 分片，生产首选
标准 .ts 未设 video/mp2t⚠️ 多数能播AVPlayer 常能按内容解析，但不规范，CDN 缓存可能异常
JPG·200 + image/jpeg + 200⚠️ 能播，Seek 易卡死iOS 实测：AVPlayer 接管后顺序播放可起播，但拖动进度条 / Seek 极易卡住无响应；200 无视 Range，每次 Seek 需拉整段分片，加重卡顿
JPG·206 + image/jpeg + 206待测试iOS 走 AVPlayer，JPG·206 的 Range、Seek 表现待实测验证
.jpg URL + video/mp2t（不推荐）⚠️ 不确定URL 与 MIME 不一致，伪装失效；不如直接用 TS·200+Range
落地建议：Android 侧 JPG·200 + hls.js 实测也很快，暂时保留；iOS 侧 JPG·206 待测试，JPG·200 实测能起播但 Seek 易卡死。TS·200+Range 是否作为 iPhone 主方案，见页顶思考项。 更多参阅 Apple HTTP Live Streaming。

Range 1KB 对比（证明 206 按需传输）

点击按钮后由 fetch + Range 发起，与播放器 hls.js 的 xhr 不是同一条请求。JPG·200 播放时常见 200+整段；本表若出现 206+1KB 多为 CF 边缘切片。

指标TS · 200+RangeJPG · 206JPG · 200
请求 Rangebytes=0-1023bytes=0-1023bytes=0-1023
HTTP 状态码---
实际下载量---
浪费流量---
Content-Type---
Content-Range---
遵守 Range---
请求耗时---
错误---

Seek 对比（证明 206 在弱网下更快）

Seek 就绪时间为本机全速实测；弱网理论基于目标分片 Range 测试下载量估算。 JPG·200 应拉整段，与 206 的 ~1KB 不可直接比耗时。目标：segment_007（/hls/segment_007.ts）

指标TS · 200+RangeJPG · 206JPG · 200
Seek 就绪时间（实测）先点 Seek 测试先点 Seek 测试先点 Seek 测试
Seek 下载分片数---
Seek 下载总量---
目标分片 Range 测试---
1Mbps 弱网理论---
5Mbps 弱网理论---
遵守 Range---