91% 的公开案例到不了 1080p，因为一半被 X 压成了 720p

Alpha Lay · 2026-09-26

想拿公开案例来评估画质的人，会遇到一个不容易察觉的问题：你看到的不是模型输出的画质，是转载链路之后剩下的画质。

我们把每条案例的视频分辨率拉出来统计了一遍。

数据是怎么来的

res 字段记录视频文件的宽×高，读自容器元数据。1,274 条全部有值，共 110 种不同规格。

先看单一规格的集中度：

一半的案例是同一个规格：1280x720。

按短边（横屏取高、竖屏取宽）分档：

短边 ≤720 的合计 1,157 条（90.8%）。 也就是说：想找一条真正的高清样本，公开案例里只有 117 条可选。

这对做评测的人是个硬约束——用这批素材去评画质、评细节保留、评人脸纹理，样本本身就受限。

X 原生视频的短边中位数是 360 像素，只有其他托管方的一半。

这解释了一个看似矛盾的现象：这批案例 87.4% 来源于 X，但只有 12.2% 的文件托管在 X 上。搬运方把文件转存到自己的存储，客观上提高了画质——因为 X 对上传视频的压缩很激进。

反过来看最清晰的来源：pub-…r2.dev 那 20 条里，16 条（80%）是短边超过 720 的高清文件，而它在全库的占比只有 1.6%。这是唯一一个以高清为主的托管渠道。

短边 ≤480 的共 202 条，它们的托管分布：

63% 的低分辨率案例来自 X 原生托管。 所以这不是「创作者做了低清视频」，而是平台压缩的结果。

我们顺手做了一项一致性检查：ori（画幅）与 res（宽高）是否矛盾——比如标为「横屏」但宽小于高。

结果：0 条不一致。

这是一条正面发现，值得单独说：说明画幅字段是从文件本身读出来的，而不是从发布描述里猜的。在一个 95% 记录待语义复核的库里，能有这样一个零误差的字段，说明客观测量字段的可信度远高于语义字段。

如果你要评测画质或细节：公开案例里只有 117 条可用（短边 >720）。先按分辨率筛，再开始评——否则你会把压缩损失误判成模型能力不足。

如果你在挑参考案例学构图：720p 足够看构图和动作，但不要用它判断纹理、皮肤细节或文字清晰度。

如果你在做自己的索引：这条结论值得记下——视频文件在传播链路上会经历一次不可逆的降质，而且降质幅度由托管方决定（4 倍差）。想保住画质，要么抓原始上传（往往已失效），要么找到以高清为主的镜像源。

分辨率不是画质。 1280x720 的文件可能码率很高，2560x1440 的可能是低码率拉伸。我们只统计了尺寸，没有测码率或实际锐度。
容器元数据可能被改写：部分托管方会在转码时保留原尺寸标签但降低码率，本文无法识别这种情况。
res 反映的是「我们抓到的那一份」：同一视频在别的镜像可能分辨率不同（这也是上一段说的跨托管差异）。
110 种规格里含大量非标准值（如 1260x720、1258x720、1280x736），说明转码链路不统一；这类「准 720p」被归入 720 档，可能轻微高估 720 档的纯度。
全部数字基于 1,274 条索引记录。

案例详情里带分辨率字段，可按画幅与分辨率筛选：https://cases.aishifu.shop/