hyperframes 这个名字，我第一次见到是在前公司做 360 度全景直播的排期表上。当时我们负责把一路 8K 全景视频推到手机端，结果测试机一上手，发热、掉帧、卡顿全来了，码率调到 60Mbps 还是被测试小姐姐吐槽"糊成马赛克"。后来把编码、传输、播放全链路翻了个底朝天，才意识到问题根本不在播放器，而在"把所有画面送给所有用户"这个思路上。hyperframes 就是奔着这个痛点来的。今天这篇不写概念,聊点实际的东西：全景视频为什么这么吃带宽，hyperframes 这类分层方案到底省在哪，以及落地时真正会踩到的坑。
1. 为什么会有 hyperframes 这个方案：全景视频的"带宽原罪"
1.1 全景视频的码率账，算完你就知道为什么传统传输模型撑不住
先做一道算术题。一路 8K 全景视频，分辨率是 7680 x 3840，按 60fps 来算，每一帧的像素量达到 2949 万像素，约等于 4K 视频的 4 倍、1080p 的 16 倍。就算用 HEVC 这类比较新的编码器，全景画面里那种高纹理、高频细节的场景，码率也稳稳落在 80~120Mbps 这个量级。如果你见过几十上百个机位的全景直播流，心里应该有数。
换个说法可能更直观：全景画面相当于把 6 块 2K 屏幕拼成一个球，而且用户随时可能把脸贴到其中任何一块上看细节。你要保证他"贴上去"那一瞬间画面还是清晰的，就得让每一块都保持足够高的码率。可是用户真正能同时看到的，只有其中一块。
传统直播的做法是什么？把完整全景画面编码成一路视频，整包传给每一个用户。用户明明只盯着球面的四分之一看，服务器却把整个球面的数据都塞进他的带宽里。这里就出现了一个很尴尬的结构性浪费：不管你看不看，数据都给你了。
实际算一下这个浪费量。取一个典型视场角 100 度 x 60 度，球面总面积按 360 度 x 180 度来算，可见区域大约占球面面积的 1/4 到 1/6 之间，取个中间值 20% 好了。也就是说，如果你按 8K 全景整包传输 100Mbps，里面至少有 80Mbps 是用户根本看不见的画面占用的。这不是编码效率问题，而是"整包传输"这个模型本身就非常不划算。
1.2 用户的行为模式，让"按需加载"成为唯一靠谱的出路
全景视频用户的行为很难预测，但也有规律：大部分时间头部在缓慢摆动，偶尔快速转头，极少有人故意盯着身后一动不动看五分钟。这意味着"当前视口 + 附近区域"的高清内容，比"整个球面"的高清内容重要得多。
这里我用一个生活类比：你在一家自助餐厅，面前摆着 50 道菜，但你手里只有一个盘子，胃口也有限。你会把每一种菜都盛一大盘吗？不会，你会先盛当前想吃的，等吃完了再去补。hyperframes 的思路就是这样：给用户一个能转头的"全景底图"保证体验，同时把他正在看的那道"菜"以最高质量端上来。这就是分层传输。
1.3 hyperframes 不是什么新编码器，而是一种内容组织方式
有一点必须先说清楚：hyperframes 并不是新一代视频编码标准，它不替代 H.264、H.265，也不是某种魔法格式。它更像一种"内容组织协议"——在编码之前，你先把画面拆成不同的逻辑层，再把每一层按需求传给用户，最后在用户设备上合成为完整画面。
做这个项目的时候，我们一度陷入"要不要等新的编码标准出来再优化"的误区，后来发现完全不必要。编码标准解决的是"单帧数据怎么压得更小"的问题，hyperframes 解决的是"哪些数据该被传出去"的问题。这两件事互相正交。沿用自助餐的比喻，编码器决定"每一道菜怎么做得更精致更浓缩"，而 hyperframes 管的是"你这一顿该端哪几盘菜到桌上"。
2. hyperframes 的分层结构：一列低清打底，一块高清随动
2.1 基础层：负责"你转头时永远有画面"
hyperframes 方案里，最底层也是一路视频，但它的画质不需要很高。常见设置是把 8K 全景降采样到 2K x 1K 左右，帧率可以保持 30fps，用 HEVC 编码之后码率控制在 4~8Mbps。这一路视频包含整个 360 度球面的画面，用途只有一个：兜底。
为什么需要一个低清的兜底？因为网络传输有延迟，预测也不是 100% 准。如果你只传用户当前视口的高清区域，一旦用户猛一转头，而高清区域还没跟上，用户看到的就会是一块黑屏或者卡顿。有了这个基础层，最坏情况也只是"画面模糊一下"，但永远不会黑屏。从产品体验角度来说，模糊可以忍，黑屏不能忍。
实操中有一个关键决策：基础层的分辨率怎么定。我们最初把基础层定为 4K x 2K，码率飙到 25Mbps，后来发现完全没有必要。因为基础层的定位不是给用户盯着看细节，而是"转身瞬间的临时画面"，它在渲染层会被高清视口画面盖住大部分。把基础层降到 2K x 1K 之后，码率省了 60%，用户感知层面的差异微乎其微。
有一个细节容易被忽略：基础层需要保证球面所有区域的编码质量足够一致。因为用户随时可能转到任何方向，如果在某个区域基础层压缩得太狠、出现大片色块，那在高清增强层切换过来的瞬间，画质落差会非常明显。这个在做码率分配的时候就要想到。
2.2 增强层：只有你正在看的那一块才送高清
增强层是 hyperframes 里真正吃带宽的部分，它只覆盖用户当前视口和预测的邻近区域。以我们当时的项目为例：视口范围约 100 度 x 60 度再加一圈余量，最终裁剪出来的视频区域大约是 3840 x 1920 分辨率、60fps，码率在 20~30Mbps 这个区间。
这里有一个工程上很关键的差异：到底是"一路大画幅视频 + 动态裁剪"，还是"把画面切成很多小块逐个传"。我们 1.0 版本做的是前者，也就是持续从全景画面中切出一块视口区域的视频流，这实现起来简单，但有两个麻烦：第一，视口一变，编码器就要重新配置，延迟明显；第二，CDN 对这类动态 URL 的支持很差，节点回源会乱套。
2.0 版本切到了 Tile 方案，也就是把全景画面预切成若干矩形小块。比如 8K 全景，可以切成 20 x 10 共 200 个小块，每个小块时长 2 秒。播放器根据当前视口算出需要哪几个小块，只请求其中覆盖视口的那一部分。这个方案有两个好处：预切片可以提前缓存到 CDN，用户请求的是一个稳定的静态资源 URL；视口切换只需要换一批 Tile 请求，不需要重新协商编码器参数。
需要提前算好的是 Tile 划分粒度。切太细（比如 40 x 20），每个用户请求 800 个对象，HTTP 请求开销会成为瓶颈，尤其直播场景下 2 秒一切，CDN 压力很大；切太粗（比如 8 x 4），又会有大量"半看半不看"的区域被整块传过来，带宽浪费严重。我们的经验是：按用户视口大小（约 100 度）做基准，让视口边缘附近始终能看到至少一整排完整的 Tile，这样既避免请求太碎，也不会把太多无关画面传过来。
2.3 两层画面如何合成：不只是"铺上去"这么简单
基础层和增强层到了播放器侧，要合成为一个完整的球面画面。最简单的做法是：先把基础层铺满整个球面，然后把增强层对应的区域覆盖上去。这是整个链路中最容易出问题的环节，因为两层视频之间存在分辨率差异、时间戳差异、投影方式差异，任何一个对不齐，画面就会闪或者错位。
我们做渲染时，先把基础层解码完铺成球面纹理，再把增强层各 Tile 解码后映射到球面的对应经纬度区域，以增强层覆盖基础层。为了让融合边缘更自然，我们还在增强层四周做了 2~4 度的羽化过渡，否则锐利的分割边缘在转头时会非常抢眼。这一步精度不需要特别夸张，但一定要做，实测下来能明显减少"切块感"。
另外要注意的是两组视频的帧率不必强制一致。比如基础层可以 30fps，增强层 60fps。渲染时用增强层的时间戳作为主时钟，基础层做插值到 60fps 即可。这个操作在 GPU 上做非常划算，比强制让两层都用 60fps 能省不少基础层码率。
3. 视口预测才是 hyperframes 真正的"胜负手"
3.1 为什么必须预测：因为网络延迟不允许你"看一眼再传"
很多人听到超帧方案，第一反应是：用户看到哪，就传哪嘛。但这里有个物理限制：从你发出请求到视频数据到达播放器然后解码出画面，少说也要 200~500ms。如果网络或者 CDN 缓存再慢一点，整个往返轻轻松松超过 1 秒。用户头都转过去了，你才开始传他已经不看的内容，这不叫按需传输，叫买椟还珠。
所以要做的其实是对未来 0.5~1.5 秒的视口位置做预测。预测不准的代价不是模糊，而是黑屏或者很明显的低清回退。回到某个项目枪测遇到的场景：用户一个 180 度甩头，从最左转到最右，用时 0.5 秒，过程中视口速度一度超过 300 度/秒。如果预测窗口是 500ms，而你只预测了 20 度的裕量，那用户停下来的时候，很有可能看到一块还没加载好的区域。
预测窗口取多少，取决于你对用户体验的容忍度。想要带宽省得多，就得让增强层区域尽量跟真实视口贴合，预测窗口就得短；但窗口短了，网络延迟稍微一波动，黑屏风险大增。我们最后取的折中值是 1 秒，也就是提前请求未来 1 秒可能用到的区域。这个值不是拍脑袋定的：它大于我们线上测到的"播放器请求到画面可用"的 P95 延迟，同时小到不会让增强层的区域扩大到不合理的程度。
3.2 预测模型：从"拍脑门"到"惯性+内容显著性"
第一版视口预测我们用的是最朴素的办法：把头部当前朝向直接当成未来 1 秒的朝向，然后加一个固定余量。运动慢的时候没问题，但遇到高速转头，惯性方向没跟上，照样翻车。后来换成了两段式预测。
第一段用传感器数据做短时预测。手机端的陀螺仪、加速度计采样率能到 200Hz 以上，足以算出当前角速度和加速度。用简单的惯性与匀加速模型，外推未来 0.5 秒的头部朝向，精度比"当前朝向+固定余量"高一个数量级。实测中，普通用户 0.5 秒内的平均预测误差可以压在 10 度以内。
第二段用内容特征做修正。这个比较进阶，但效果最好。比如画面里有一辆车在移动，或者某个位置有高亮度、高对比的物体，人眼有概率朝那边看。我们把显著区域权重叠加到预测结果上，适当拓宽靠近显著区域的增强范围，牺牲一点带宽换取更稳的体验。这一块我们当时跑的是 YOLO 级别的轻量检测模型，每帧代价不大，但主观体验提升明显。
不要迷信复杂的模型。我们试过 LSTMs、attention-based 的更花哨的预测模块，发现提升有限，却在 CPU 上吃掉了不少资源，延迟还上去了。头部运动本身是个强平稳过程，简单的惯性外推 + 内容显著性修正已经能覆盖绝大多数场景。核心是把采样频率和延迟降下来，而不是一味堆模型参数。
3.3 切块调度：带宽有限时，谁先谁后要想清楚
当用户带宽在 30Mbps 左右徘徊时，调度策略直接决定观看体验。我们的优先级从高到低是这样排的：
- 当前视口正中央覆盖的 Tile，最高优先级，必须以最高码率快速送达。
- 视口预测区域内、且距离真实视口最近的边缘 Tile，中优先级，尽量送达。
- 增强层区域外围的过渡区 Tile，低优先级，带宽有余量才送，否则保持基础层画面。
- 当前完全不可见的背面 Tile，默认不送增强层，只靠基础层兜底。
这套策略在带宽抖动时表现很好：优先保证"正在看的地方"清晰，其次保证"马上可能看到的地方"有次高清质量，"远处"的东西再模糊也基本不影响体验。带宽不足时，我们宁可直接放弃一部分预测区域的高清请求，也不要降低当前视口的码率——因为用户正在看的部分一旦糊了，主观体验立刻崩。
这里还有一个容易被忽略的点：切换不要频繁。调度器如果每 100ms 就根据预测结果调整一次请求列表，很容易出现刚请求了 A 区域，下一个周期又取消 A、去请求 B 的情况，大量带宽浪费在取消的和已经下发的数据上。我们把调度周期设为 500ms，并且对已请求的数据不做中途取消，只在下一轮变化请求范围。这样牺牲了一点实时性，换来了 CDN 和播放器两侧的稳定。
4. 工程落地时容易翻车的 4 个地方
4.1 同步问题：基础层和增强层时间戳对不齐，画面像瘸腿
hyperframes 落地遇到最多的问题，就是两层视频不同步。具体表现是：用户在快速转头时，会感觉画面"裂开"，低清层和高清层像两张错位的图片叠在一起，边框处还能看到明显的撕裂。
这个问题的根源通常不在编码，而在传输。基础层是长视频流，增强层是大量 2 秒小切片，两者的到达时间、缓冲深度天然不同。播放器如果简单按解码完成时间去渲染，必然错位。
解决思路是把增强层当作"主时钟"。每一帧以增强层的时间戳为准，基础层根据 PTS 做插值对齐到最近的帧。在对接播放器时，还要留意 DTS/PTS 的偏移问题：很多编码器对裁剪后的增强层并没有从 0 开始重新编排 PTS，而是保留了原全景时间戳的一个偏移量，不统一处理就会出现"两层永远差半帧"这种极其隐蔽的 Bug。我们最后在解码器外挂了一层 PTS 归一化逻辑，把增强层所有切片的 PTS 减去一个统一的基准值，问题才彻底消失。
4.2 视口预测抖动：频繁在"高清边缘"与"低清底图"之间来回跳
视口预测模型输出的是一个连续值，但如果调度模块对预测结果过于敏感，就会出现"画面一会儿从高清退到低清，一会儿又从低清恢复高清"的频繁抖变。这种视觉上的阶梯感，比一直保持中低清更令人反感。
我用一个滤波器解决这个问题：对预测的视口中心做一个滞后处理，只有当模型预测位置和当前增强层覆盖区域边缘的距离超过某个阈值（比如 20 度）时，才真正触发切换。同时，我们把增强层的覆盖范围做成了"缓变"而不是"跳变"，每次扩大缩小都限定在一个小步长内。代价是视口切换后，高清区域覆盖会滞后约 0.3 秒，但几乎感知不到——相比之下，频繁抖动的破坏力要大得多。
这个问题的另一个来源是 IMU 数据噪声。手机陀螺仪在静置时也会有几度每秒的漂移，直接用原始角速度做预测，预测点会像"喝醉了"一样乱晃。我们在算法前端加了一个滑动窗口中值滤波，窗口取 200ms，既滤掉了抖动，又不会明显增加延迟。效果非常明显，切换率至少下降了一半。
4.3 CDN 回源与缓存：200 个 Tile 同时回源，源站直接被打爆
分块传输的代价是引入了大量独立 URL，这对 CDN 的缓存策略和回源压力是个考验。直播场景尤其危险：所有用户在同一个时间点都在请求同一批分片，如果 CDN 节点上没有缓存，回源请求会在瞬间打满源站带宽，产生雪崩。
我们的做法是两件事。第一，给每个 Tile 的 URL 加上持久的 cache key，保证同一内容在不同用户间能复用缓存。第二，做"部分边缘预热"：在直播开始前，把接下来几秒可能有高请求量的 Tile 提前推送到边缘节点。预热哪个区域，就根据当前热门视口的统计来定。实测下来，这个预热策略可以让回源率从 30% 以上降到 5% 以下，源站压力骤减。
另外提一个容易忽略的点：直播切块场景下，切片时长不能太短。我们一开始把切片设成 1 秒，其实是为了降低首屏延迟，但导致 CDN 上的缓存碎片非常多，用户追帧时常常在多个版本之间跳。后来把切片时长改成 2 秒，延迟只多了 1 秒，但整体稳定性明显提升。总体体验反而更好。
4.4 播放器兼容性：同一个方案，Web 端和安卓/iOS 表现完全不同
hyperframes 方案能不能跑通，最后还真得看播放器。我们在 Web 端用 WebGL 渲染，安卓端用 ExoPlayer + 自研渲染器，iOS 端用 AVPlayer + Metal，三个端各自踩了一轮坑。
Web 端最容易踩的坑是纹理限制。增强层多路视频同时解码，很容易把 GPU 显存占满，尤其在 4K 增强层下，移动端浏览器经常崩溃。我们最后不得不限制同时活跃的 Tile 数为 4~6 路，然后通过调度器保证这 6 路恰好覆盖当前视口。
安卓端的坑是解码器资源竞争。多路解码在黑盒状态上争抢硬件解码单元，经常出现未知错误导致花屏。ExoPlayer 对每个 media source 都占用独立的解码器实例，资源不足时会直接把播放器打崩。我们只能把基础层切到软件解码，把硬件解码器优先让给增强层。这里有个经验：基础层是低分辨率，软解也扛得住，关键是别让它和增强层抢编码器。
iOS 端最大的坑是切片的拼接时序。AVPlayer 对多路 video track 的时钟同步机制和自定义渲染方案配合不好，容易在切换时出现 1~2 帧黑屏。我们最终选择不用 AVPlayer 直接渲染多路，而是绕到 AVAssetReader 级别自己做解码，再交给 Metal 合成。虽然开发量大，但可控性高，最终效果也最好。
5. 做 hyperframes 这类方案的一些个人体会
如果现在有个项目要上假帧或类似的分层传输方案，我的建议是先别急着堆 Tile 数量和预测模型。先把基础层的兜底体验做扎实，把两层的时间戳对齐做好，再谈省带宽。这两个基础问题不解决，后面调什么都是空中楼阁。
另外一个小技巧：测试时不要只坐在工位上慢悠悠晃头，要找那种"甩头看视频"的用户来测。这类用户几乎能在一分钟内把预测模型的死角全部暴露出来。我们当初就是靠一个喜欢边转椅子边看全景视频的实习生，才在两周内把预测模块从"够用"逼到"好用"。
hyperframes 这类方案后续其实还能和光场渲染、空间音频串起来玩。比如在同一套分层框架中，增加一路空间音频数据流，让头部转动时声音跟随更加自然，这些都是顺手就能接入的能力。但核心思路仍然是那个：让内容组织跟着人的感知走，而不是把整个世界原封不动地塞给每个人。
