译文说明
本文由 Hy4 preview 机器翻译自韩文原文，仅供参考。技术细节请以韩文原文为准。
一个宽幅画面击穿了 720p 计费档位
概述
在上一篇文章中，我们讨论过 MPS 会依据长边/短边与宽高比来判定分辨率等级。本文则是一个不得不真正改动该判定逻辑的调试案例。用户运营的是以竖版短视频为主的服务，希望只用 720p 和 360p 两个等级来控制 ABR 转码费用，却遇到了在特定条件下意外触发 1080p 等级的问题。
问题提出：为什么只有 iPad 会被计入 1080p 费用
用户提出的问题是这样的：他已经把 ABR 模板配置为只使用 720p 和 360p 两个 rendition，但在横向宽高比大于 9:16 的输入（例如在 iPad 等平板设备上录制的视频）上，会不必要地一并触发 1080p 转码。
需求很明确。
| Rendition | 配置 |
|---|---|
| Rendition 1 - 720p | 横向分辨率限制为 720px |
| Rendition 2 - 360p | 横向分辨率限制为 360px |
需求是：当输入宽高比大于 9:16（即横向更长）时，转码模板要强制把横向分辨率上限限制为 720 或 360，避免在 iPad 这类宽屏设备上被抬到 1080p。既没改编码器也没改码率配置，却只在特定宽高比下等级跳变，因此必须拆开模板的分辨率缩放逻辑本身来看。
原因：只固定一条边，另一条边就会超出上限
该服务的 ABR 模板原本是以竖版短视频（9:16）为基准设计的。由于竖版视频占绝大多数，「把长边（高度）对齐到等级上限、短边（宽度）按比例计算」这一条规则就足够了。
问题在于，该模板所参照的等级上限本身是分别对长边和短边独立设置的。两个等级的定义如下。
| 等级 | 条件 |
|---|---|
| 360P | 长边 ≤ 640px 且 短边 ≤ 360px |
| 720P | 长边 ≤ 1280px 且 短边 ≤ 720px |
这与上一篇文章中讨论的 MPS 比例分支方式是另一种形态，但与StreamLive 的分辨率等级判定相同，都采用「必须同时满足长边和短边才算该等级」的 AND 条件结构。也就是说，只要两个条件中有一个超出，就会被挤出该等级。
「只固定长边」这条规则在宽高比接近 9:16 时没有问题。但当宽高比落入 9:16 与 16:9 之间、也就是接近正方形的区间（包含 iPad 的 4:3 这类宽高比）时，情况就变了。在这个区间里，只把长边对齐到等级上限，短边按比例如此计算后反而会超出该等级的短边上限。
用数字来看是这样的。对 850×1280 的输入套用「把长边（1280）对齐到 720p 上限」的规则做缩放，长边已经是 1280、与上限相等，因此一点都不会缩小，短边则原样保留 850。但 720P 的短边上限是 720px。850 远超这个上限，因此该产物无法满足 720P 的 AND 条件（长边 ≤ 1280 且 短边 ≤ 720），被推到更高等级 1080P。明明没改过任何画质配置，却只因一个宽高比就导致等级跳升，其真面目正是如此。
解决：按宽高比区间划分优先级
修改方式是：把宽高比（横向 ÷ 纵向，记为 x）划分为三个区间，并在每个区间里采用不同的「哪条边先对齐上限」策略。
| 条件 | 处理 |
|---|---|
| x > 16:9 | 长边优先 |
| 16:9 ≥ x ≥ 9:16 | 短边优先 |
| x < 9:16 | 长边优先 |
两端区间（纵向很长或横向很宽的情况）先把长边对齐上限、短边按比例计算，短边也会自然落在上限之内。真正有问题的是中间区间，也就是接近正方形的宽高比。在这个区间里要反过来：先把短边对齐上限、长边按比例计算，这样长边也能落进自己的上限之内，从而同时满足两个条件。
实测验证：用四种宽高比确认
我把修改后的规则实际代入了四种宽高比。
| 宽高比 | 输入 | 判定 | 处理 | 输出 |
|---|---|---|---|---|
| 8:16（x=0.5，< 9:16） | 720×1440 | 长边优先 | 长边 1440→1280 | 640×1280 |
| 10:16（x=0.625，中间区间） | 800×1280 | 短边优先 | 短边 800→720 | 720×1152 |
| 16:8（x=2.0，> 16:9） | 1440×720 | 长边优先 | 长边 1440→1280 | 1280×640 |
| 16:10（x=1.6，中间区间） | 1280×800 | 短边优先 | 短边 800→720 | 1152×720 |
四种情况的输出都满足 720P 的 AND 条件（长边 ≤ 1280、短边 ≤ 720）。尤其是 10:16 和 16:10 这类落入「中间区间」的宽高比，短边优先规则准确生效，可以看到长边为 1152/1152，宽裕地落在上限（1280）之内。iPad 一类的 4:3（x=1.33）宽高比也属于这个中间区间，因此用同一条规则处理。
我也把同一套逻辑代入 360p 等级做了确认。
| 宽高比 | 输入 | 判定 | 处理 | 输出 |
|---|---|---|---|---|
| 比 9:16 更竖长的画面 | 360×720 | 长边优先 | 长边 720→640 | 320×640 |
| 比 9:16 更宽的画面 | 500×640 | 短边优先 | 短边 500→360 | 360×461 |
两种情况都精确满足 360P 的 AND 条件（长边 ≤ 640、短边 ≤ 360）。
小结
- 该 ABR 模板所参照的等级定义，对长边和短边各设独立上限，并且是必须同时满足两个条件的 AND 结构。与StreamLive 的分辨率判定方式属于同一形态。
- 以竖版短视频（9:16）为前提制定的「只固定长边」规则，会在宽高比处于 9:16 与 16:9 之间的区间（包含 iPad 的 4:3）里导致短边超出等级上限，这正是被意外判定为更高等级（1080P）的原因。
- 解决办法是把宽高比划分为三个区间（x>16:9、9:16≤x≤16:9、x<9:16），两端区间采用长边优先、中间区间采用短边优先，应用不同的缩放规则。
- 用四种宽高比实测验证的结果，全部满足目标等级的 AND 条件。
即便是以竖版内容为主的服务，只要存在任何一条用户上传平板或横拍视频的路径，「只固定长边就行」这个简单假设就会在该路径上被精确击穿。如果不亲自按宽高比区间算一算到底是哪条边决定等级，就会一直以为计费档位已牢牢固定在两个等级上，直到在账单上撞见意料之外的等级。