第 9 章 · 播放器：从 manifest 到第一帧

预计阅读时间：20 分钟

本章你会理解：播放器点击"播放"到画面出现都做了什么、Web/iOS/Android 播放器各有什么限制、首帧优化的招数、自研和开源怎么选。

9.1播放器到底在做什么

你点击"播放"后，播放器内部要完成至少 10 件事：

      ①  解析 manifest (m3u8/mpd)

      ②  决定从哪个档位开始

      ③  下载 init segment + 第一个 media segment

      ④  解析 fMP4 box 结构

      ⑤  分离 video ES + audio ES

      ⑥  送入解码器（硬解或软解）

      ⑦  解码出 YUV 图像 + PCM 音频

      ⑧  音视频同步（lipsync）

      ⑨  YUV → RGB 色彩转换

      ⑩  送到显示器渲染

同时还要：

• 持续下载后面的切片

• 运行 ABR 算法

• 上报 QoE 数据

• 响应用户操作（暂停、seek、调清晰度）

• 处理 DRM challenge

一个现代播放器动辄十几万行代码，不是随便写一个 <video> 标签那么简单。

9.2Web 播放器：<video> + MSE + EME

原生 <video> 够吗

      <video src="video.mp4" controls></video>
    

这能播一个 MP4，但不能播 HLS/DASH/CMAF：

• <video> 只能收一个连续的 MP4 文件

• HLS/DASH 是"一堆切片"，需要 JS 把切片塞进 <video> 里

Safari 是个例外——它原生支持 HLS（Apple 自家的东西），直接 <video src="index.m3u8"> 能播。

MSE（Media Source Extensions）

MSE 是 W3C 的 API，允许 JS 动态往 video 里塞字节。

      const video = document.querySelector('video');

      const mediaSource = new MediaSource();

      video.src = URL.createObjectURL(mediaSource);

      mediaSource.addEventListener('sourceopen', () => {

          const sourceBuffer = mediaSource.addSourceBuffer(

              'video/mp4; codecs="avc1.64001f,mp4a.40.2"'

          );

          fetch('seg_01.m4s')

              .then(r => r.arrayBuffer())

              .then(buffer => sourceBuffer.appendBuffer(buffer));

      });

有了 MSE，JS 就能：

• 解析 m3u8/mpd 自己实现

• 按需下载切片

• 塞进 SourceBuffer

• 浏览器负责渲染

hls.js 和 Shaka Player 就是基于 MSE 建立的。

EME（Encrypted Media Extensions）

EME 是 W3C 的 DRM API，让 JS 对接浏览器内置的 CDM（Widevine in Chrome、PlayReady in Edge、FairPlay in Safari）。

      video.addEventListener('encrypted', async (event) => {

          const keySystem = 'com.widevine.alpha';

          const mediaKeys = await navigator.requestMediaKeySystemAccess(

              keySystem, config

          ).then(a => a.createMediaKeys());

          video.setMediaKeys(mediaKeys);

          const session = mediaKeys.createSession();

          session.addEventListener('message', async (event) => {

              // event.message 是 CDM 生成的 challenge

              const license = await fetch('/license', {

                  method: 'POST',

                  body: event.message

              }).then(r => r.arrayBuffer());

              session.update(license);

          });

          session.generateRequest('cenc', event.initData);

      });

主流 Web 播放器开源库

库	主打	维护者	规模
hls.js	HLS	Dailymotion / video-dev	最成熟 HLS JS
Shaka Player	DASH + HLS	Google	功能最全
dash.js	DASH	DASH-IF	DASH 参考实现
Video.js	UI 框架	Brightcove	支持多种后端

推荐：HLS-only 选 hls.js；DASH 或混合选 Shaka Player。

9.3iOS 播放器：AVPlayer 一家独大

AVPlayer 是什么

• iOS 系统原生播放器

• 唯一官方方式播放 FairPlay DRM 内容

• 苹果的 HLS 起源和最强支持

AVPlayer 的限制

限制 1：协议只能用 HLS（不原生支持 DASH）。

限制 2：ABR 是黑盒。只有少量 API 可调：

      // 限制最大码率

      playerItem.preferredPeakBitRate = 2_000_000  // 最多 2 Mbps

      // 前向缓冲秒数

      playerItem.preferredForwardBufferDuration = 10  // 10 秒

无法自定义"选哪档切片"的逻辑。

限制 3：切片下载队列不可见。想预载、想自定义 cache 策略要绕开。

绕开限制：AVAssetResourceLoaderDelegate

要自定义行为需要用 AVAssetResourceLoaderDelegate —— 劫持 manifest 和 segment 请求，返回自己准备的字节：

      class CustomLoader: NSObject, AVAssetResourceLoaderDelegate {

          func resourceLoader(

              _ resourceLoader: AVAssetResourceLoader,

              shouldWaitForLoadingOfRequestedResource

                  loadingRequest: AVAssetResourceLoadingRequest

          ) -> Bool {

              let url = loadingRequest.request.url!

              // 自己下载或从本地预载池拿

              fetchFromOurCache(url) { data in

                  loadingRequest.dataRequest?.respond(with: data)

                  loadingRequest.finishLoading()

              }

              return true

          }

      }

工程复杂，但头部 APP（TikTok、短剧 APP）常这么做以实现零 TTFF。

AVQueuePlayer：预载多条队列

      let queue = AVQueuePlayer()

      queue.insert(AVPlayerItem(url: episode1URL), after: nil)

      queue.insert(AVPlayerItem(url: episode2URL), after: nil)  // 预载

      queue.insert(AVPlayerItem(url: episode3URL), after: nil)  // 预载

AVQueuePlayer 会自动预载队列里的下一个 item（部分预载，具体由系统决定）。

9.4Android 播放器：ExoPlayer / Media3

ExoPlayer

Google 官方的开源播放器，已在 Android 生态取代老的 MediaPlayer：

• 支持 HLS、DASH、SmoothStreaming、Progressive

• 原生 Widevine DRM（通过 MediaDrm API）

• 完全开源可自定义

Media3

AndroidX Media3 是 ExoPlayer 的"下一代封装"（2022+）：

      implementation "androidx.media3:media3-exoplayer:1.3.0"

      implementation "androidx.media3:media3-exoplayer-hls:1.3.0"

      implementation "androidx.media3:media3-exoplayer-dash:1.3.0"

      val player = ExoPlayer.Builder(context)

          .setTrackSelector(DefaultTrackSelector(context).apply {

              setParameters(buildUponParameters().setMaxVideoBitrate(2_000_000))

          })

          .setLoadControl(DefaultLoadControl.Builder()

              .setBufferDurationsMs(15_000, 30_000, 1_500, 2_500)

              .build())

          .build()

      player.setMediaItem(MediaItem.fromUri("https://.../master.m3u8"))

      player.prepare()

      player.play()

可自定义的东西比 iOS 多得多

• TrackSelector：码率选择、分辨率限制

• LoadControl：缓冲参数

• MediaSourceFactory：自定义下载、CDN 调度

• RenderersFactory：自定义渲染（后处理滤镜等）

跨平台：想在 iOS 和 Android 一套代码？常见方案 React Native Video（底层 iOS=AVPlayer、Android=ExoPlayer）、Flutter video_player、或自己用 FFmpeg + MediaCodec/VideoToolbox 实现。

9.5首帧优化：怎么让点击到出画面最快

首帧时间 TTFF（Time To First Frame）是 VOD/短视频最敏感的指标。影响因素：

      ① DNS 解析         ~20-100ms

      ② TCP 握手         ~30-100ms

      ③ TLS 握手         ~50-200ms

      ④ 拉 manifest      ~30-200ms

      ⑤ 拉 init segment  ~50-100ms

      ⑥ 拉第 1 个切片    ~100-500ms

      ⑦ 解码 + 渲染      ~50-200ms

累加起来动辄 1-2 秒。怎么压到 300ms 以下？

优化手段清单

手段	节省时间
DNS Prefetch（APP 启动就解析域名）	20-100ms
HTTP/3 + 0-RTT（之前连过直接建连）	50-200ms
Preconnect（提前建 TLS）	50-200ms
Manifest Prefetch（下一集 manifest 提前拉）	200ms
短 GOP（1-2s）+ 短 segment（2s）	1-2 秒（启动不用等 6s）
启动档位用低码率	切片小下载快
Init Segment 本地缓存	50-100ms
预载下一集首 3 片	对切集几乎零延迟
硬件解码	解码 ~0ms 开销

短剧 APP 的"零 TTFF"方案

核心思想：

      当前播放第 N 集：

      ┌────────────────────────────────────────────────┐

      │  N-1 集（保留缓冲 5s） [万一用户回滑]            │

      │  N   集（完整加载）                              │

      │  N+1 集（预载 init + 首 3 切片 ≈ 6-12s）       │

      │  N+2 集（预取 init + 首 1 切片）                 │

      └────────────────────────────────────────────────┘

9.6缓冲策略：不让用户看到转圈圈

Buffer（缓冲区）是已下载但还没播的秒数。经典设计：

      播放头 ─►  [已播放 →  播放点]  [已下载但未播 → 缓冲]  [还没下]

                             ◄────── Buffer Level ──────►

三个阈值：

• Min Buffer（起播需要的最小缓冲，如 3s）

• Target Buffer（理想缓冲，如 30s）

• Max Buffer（缓冲上限，如 60s，防止预下太多浪费）

业务场景差异

场景	Min	Target	Max
长电影	3s	30s	120s
短剧	1s	10s	20s
低延迟直播	0.5s	2s	6s

缓冲耗尽（Rebuffer）应对

缓冲归零 → 必须停下等 → 用户看到转圈圈。策略：

• 缓冲 < 安全线 → ABR 下一个切片强制选最低档（保命）

• 切换 CDN 节点重试

• 上报事件触发告警

9.7音视频同步（Lip Sync）

视频帧和音频帧是分别解码的，怎么保持同步？

依据 PTS（Presentation Timestamp）：每帧都有一个"该什么时候显示"的时间戳。

      视频帧 PTS:  0.000   0.033   0.066   0.100 ...

      音频帧 PTS:  0.000   0.021   0.042   0.064 ...

                      ▲ 以音频为基准

                      ▲ 视频帧播放时间 = 音频当前时间 + 偏差校正

大多数播放器用音频作为主时钟（人耳对时间偏差更敏感），视频按音频对齐。

9.8硬件解码 vs 软件解码

	硬件解码	软件解码
性能	快，能解 4K 60fps	慢，4K 可能吃不消
功耗	低	高
灵活性	受硬件支持限制	任意格式
兼容性问题	某些手机对特殊码流兼容差	稳定

优先用硬解。只有硬解不支持（AV1 在老芯片、不常见编码参数）时再回落到软解。

9.9自研播放器 vs 开源

方案	适用	成本
直接用开源（hls.js / ExoPlayer / AVPlayer）	99% 的 VOD 平台	低，几人月集成
在开源上做少量定制	有特殊 UI / ABR / 埋点需求	中
深度自研（替换 ExoPlayer 内核、iOS 绕开 AVPlayer）	头部 APP（TikTok、短剧 APP、直播平台）	高，几十人月

不要轻易自研播放器内核。除非你有明确的性能或体验问题是开源播放器无法满足，且有预算维护。

9.10播放器必做的埋点（为下一章铺垫）

无论用开源还是自研，下面埋点一定要做：

事件	含义
`video_attempt`	用户触发播放
`video_start`	第一帧渲染
`video_rebuffer_start`	卡顿开始
`video_rebuffer_end`	卡顿结束
`bitrate_change`	切换了码率档位
`video_complete`	播放完成
`video_error`	出错
`video_exit`	用户退出

每事件附带：video_id、user_id、cdn、network_type、device、bitrate、buffer_level 等维度。

详见下一章：QoE 数据体系。

本章要点回顾

1. Web 播放 HLS/DASH 必须靠 MSE；DRM 必须靠 EME。

2. iOS 播放 HLS + FairPlay 只能用 AVPlayer，ABR 是黑盒。

3. Android ExoPlayer / Media3 开源可自定义，灵活度高。

4. TTFF 优化的核心手段：DNS Prefetch + HTTP/3 + 短 GOP + 预载。

5. 缓冲三阈值：Min / Target / Max；按业务场景调整。

6. 音视频同步以音频为主时钟。

7. 尽量用开源播放器，别轻易自研内核。

← 上一章：DRM 版权保护目录下一章：QoE 数据体系 →