91% of these cases never reach 1080p — because half of them were compressed to 720p by X

By Alpha Lay · 2026-09-26

Anyone hoping to use public cases to assess image quality runs into a problem that is easy to miss: what you are looking at is not the model's output quality, it is what survived the reposting chain.

We pulled the resolution of every case.

Where the data comes from

The res field records the video file's width×height, read from container metadata. All 1,274 have a value, across 110 distinct specs.

Concentration on a single spec first:

Half the corpus is one spec: 1280x720.

Finding 1: Only 9.2% have a short side above 720

Banded by short side (height for landscape, width for vertical):

Short side ≤720 accounts for 1,157 cases (90.8%). In other words: if you want a genuinely high-resolution sample, only 117 exist in the public corpus.

That is a hard constraint for evaluation — assessing image quality, detail retention or facial texture against this material hits a sample ceiling.

Finding 2: Compression is set by the host, and varies 4x

Native X video has a median short side of 360 pixels — half that of the other hosts.

That explains an apparent contradiction: 87.4% of these cases originate on X, yet only 12.2% of the files are hosted on X. Reposting parties migrate files to their own storage, which objectively improves quality — X compresses uploaded video aggressively.

Now the clearest source: of the 20 cases on pub-…r2.dev, 16 (80%) have a short side above 720, against a 1.6% share of the whole corpus. It is the only predominantly high-definition channel.

Finding 3: Among low-resolution cases, native X is over 60%

There are 202 cases with a short side ≤480:

63% of the low-resolution cases come from native X hosting. So this is not "creators made low-res videos" — it is platform compression.

Finding 4: Framing and resolution agree (the good news)

We also ran a consistency check: does ori (framing) ever contradict res (width and height) — for instance, "landscape" with width below height?

Result: 0 contradictions.

This is a positive finding worth calling out. It shows the framing field is read from the file itself, not inferred from a description. In a library where 95% of records are pending semantic review, having one zero-error field demonstrates that objective measurements are far more trustworthy than semantic labels.

What you can do with this

If you evaluate image quality or detail: only 117 public cases are usable (short side >720). Filter by resolution before you start — otherwise you will read compression loss as model weakness.

If you pick reference cases to study composition: 720p is enough for framing and action, but do not use it to judge texture, skin detail or text legibility.

If you build your own index: worth recording — a video file suffers one irreversible quality loss in the reposting chain, and the magnitude is set by the host (4x spread). To preserve quality, either grab the original upload (often already gone) or find a mirror that skews high-definition.

Method and limitations

• Resolution is not quality. A 1280x720 file can carry a high bitrate; a 2560x1440 file can be an upscale of something soft. We measured dimensions only — no bitrate or measured sharpness.
• Container metadata can be rewritten: some hosts transcode while keeping the original dimension labels. We cannot detect this.
• res reflects the copy we captured: the same video may differ across mirrors (which is the cross-host variation described above).
• The 110 specs include many non-standard values (1260x720, 1258x720, 1280x736), showing inconsistent transcoding. These "near-720p" values are grouped into the 720 band, which may slightly overstate its purity.
• All figures use the 1,274 index records.

Reproduce it

Case detail views carry the resolution field and can be filtered by framing and resolution: https://cases.aishifu.shop/