Every capture mode but the fastest is discarded — 1080p120 cannot be selected at all

[liversedge]

Found on 25 August 2026 trying to answer a direct question — "is the encoder dropping less at 120 fps?" — and discovering the app cannot be asked it.

What the hardware offers, and what the app keeps

AVFoundationCaptureDevice.enumerateCapability() collapses the format list to the best rate per (lens, resolution):

let key = "\(lens.rawValue)-\(dims.width)x\(dims.height)"
if let existing = best[key], existing.fps >= maxRate { continue }
best[key] = mode

On an iPhone 16 the wide camera actually offers, measured on the device:

1440x1080 @ 60 fps YES intrinsics
1920x1080 @ 30 fps YES intrinsics
1920x1080 @ 60 fps YES intrinsics
1920x1080 @ 120 fps YES intrinsics
1920x1080 @ 240 fps NO intrinsics

⛔ Four of those five are discarded. claimed keeps only 1920x1080 @ 240 for that lens and resolution, so 1080p120, 1080p60 and 1080p30 do not exist as far as the rest of the application is concerned.

What that does in practice

AppModel.remeasure(atMost: 120) filters capability.claimed on fps <= 120 and takes the best remaining. With every 1080p rate below 240 collapsed away, the best thing left is a different resolution entirely:

requested cap 120 fps → selected 3840x2160 @ 60

⛔ Asking for 120 fps silently gives you 4K60, which is the direction REQ-RES-1 rules out in as many words — target 1080p at the highest sustainable rate, and do not reach for 4K. And it performs as you would expect: on that mode the app realised 43.1 fps against a claimed 60, with a 8703 ms gap and 190 encoder-busy drops.

⚠ The comment explaining the collapse is right about the wrong thing. "A device reports dozens of formats that differ only in pixel encoding and photo capability; the capability card is about geometry and rate." True — for the capability card, which is one sentence on A1. It is not true for mode selection, and the same collapsed list serves both.

⛔ And it hides the one mode that solves #19

The intrinsics table above is the sharp part. 1920x1080 @ 240 is the only 1080p row that does not deliver an intrinsic matrix, and #19 is open precisely because the declaration overclaims intrinsics: per_frame at that rate. 1920x1080 @ 120 delivers them — and is exactly the row the collapse throws away.

So the trade a user might reasonably want to make — half the frame rate, but real per-frame intrinsics — is not expressible anywhere in this application, and the mode that would make it is invisible.

Worth deciding

• Keep the collapsed list for the capability card, and carry the full enumeration for selection? The two want different things from the same walk.
• If the full list is kept, what does the user-facing choice look like — a rate picker, or a declared preference like "prefer intrinsics over rate"?
• ⚠ enumerateCapability runs on every refreshCapability(); keeping every format grows the declaration, which is already sized in #98's findings against a 64 KiB origination queue. Check the declaration still fits before widening what is declared.

Exit criterion

⛔ A rate the hardware offers can be selected and armed. Specifically: 1920x1080 @ 120 is reachable, arms, and reports per-frame intrinsics on the Capture — and asking for at most 120 fps never returns a 4K mode.

[liversedge]

The evidence, dumped off the phone rather than reasoned about

Mark, 25 August: "you can't select 120fps? that doesn't make ANY sense — the native video apps let you use 120 fps. Something smells off here." Correct that something is off. It is this repository, not the hardware or AVFoundation.

Tests/DeviceSessionTests.swift now dumps all three lists side by side. On the iPhone 16:

What AVFoundation reports — 55 formats per lens, 20 distinct geometry@rate, identical on both back cameras:

1280x720 @ 240 1920x1080 @ 240 3840x2160 @ 60
1920x1080 @ 120 ← 1920x1080 @ 60 3840x2160 @ 30
1920x1080 @ 30 1920x1440 @ 60 4032x3024 @ 30 (+ 11 smaller)

What enumerateCapability() keeps — 110 formats walked, 28 kept:

1920x1080 @ 240 ultraWide 3840x2160 @ 60 wide
1920x1080 @ 240 wide 1920x1440 @ 60 wide
1280x720 @ 240 wide 1440x1080 @ 60 wide … and 22 more

⛔ 1920x1080 @ 120 is not in the kept list, on either lens. One line does it — if let existing = best[key], existing.fps >= maxRate { continue } — where key is lens + width + height. Every rate below the top one for a given geometry is discarded.

What a rate cap then selects, by the rule remeasure(atMost:) uses:

cap 240 fps → 1920x1080 @ 240 ultraWide
cap 120 fps → 3840x2160 @ 60 ultraWide ⛔
cap 60 fps → 3840x2160 @ 60 ultraWide

So asking for at most 120 fps returns a 4K mode at 60 — the direction REQ-RES-1 rules out — and it does so because the 1080p120 that would have answered was thrown away three steps earlier.

⛔ A second defect the same dump exposes: the rate cap changes LENS

Look at the first row. cap 240 selects ultraWide, not wide.

remeasure(atMost:) breaks ties with ($0.fps, $0.height) < ($1.fps, $1.height) — no lens term at all — so between 1920x1080 @ 240 wide and 1920x1080 @ 240 ultraWide the winner is whichever Set iteration happened to put last. DeviceCapability.bestMode breaks the identical tie with -$0.lens.captureRank and deliberately prefers the wide lens, with a comment explaining why.

⛔ Two selectors, one list, different answers. A user who touches the rate control can be silently moved to a different physical camera — different field of view, different intrinsics, different calibration. REQ-OPT-5 is about exactly this class of silent lens change, and it is reachable here without any lens ever being named.

⚠ This also makes every measurement taken through remeasure suspect: #101's warm 240 fps run went through remeasure(atMost: 240) and was therefore very likely measuring the ultra-wide camera, not the wide one. Worth re-reading before those numbers are relied on.

Exit criterion, restated

⛔ Two parts, and the second was not in the original body:

1. 1920x1080 @ 120 is selectable, arms, and reports per-frame intrinsics on the Capture; asking for at most 120 fps never returns a 4K mode.
2. Selecting a rate never changes the lens. One ranking rule, used by both bestMode and any rate-capped selection, with the lens term in it.

[liversedge]

⚠ Correction to the comment above: the lens tie-break is non-deterministic, not consistently ultra-wide.

The dump computed cap 240 fps → 1920x1080 @ 240 ultraWide. A later run of remeasure(atMost: 240) on the same phone selected 1920x1080 @ 240 **wide**. Same code, same device, different answer.

claimed is built from a [String: VideoMode] dictionary and materialised with best.values.sorted { ($0.height, $0.fps) > ($1.height, $1.fps) } — which leaves two modes of identical height and rate in hash order. max(by:) then returns whichever of them came last. So the selected lens varies between runs.

⛔ That is worse than a consistent wrong answer, not better: a reproducible preference for the ultra-wide would at least be measurable and correctable. This one makes the capture lens a coin flip on any path that goes through a rate cap, and it is why #101's measurements had to be re-taken with the lens printed before they could be trusted.

Exit criterion part 2 stands and is now sharper: one ranking rule with the lens term in it, used by every selector, so the same list cannot yield two answers — or the same answer twice.

[liversedge]

✅ Closed against both halves of the exit criterion, verified on an iPhone 16. Fixed in dc26644.

1. A rate the hardware offers can be selected and armed.

raw formats walked 110 claimed modes 28 → 40
cap 240 fps → 1920x1080 @ 240 wide
cap 120 fps → 1920x1080 @ 120 wide (was 3840x2160 @ 60 ultraWide)
cap 60 fps → 3840x2160 @ 60 wide

The whole application then armed at 1920x1080 @ 120.0 wide and minted four Shots — so Use 120 fps now does what the button says.

2. Selecting a rate never changes the lens. One comparator, VideoMode.isWorseForCapture, with the lens term and width in it, used by bestMode and by the rate cap. Verified stable across repeated enumerations on the device rather than merely correct once — the defect was hash order, so being right one time proves nothing.

⚠ And it turned out to matter more than a mode list. With 1080p120 reachable, the #101 harness could measure it, which is what exposed the nine-second reconfiguration stall — now fixed. The mode this repository was discarding is the one that found the bug.

Cost, measured rather than assumed: the declaration grows from 13,416 bytes at 28 profiles to 18,472 at 40, far inside the 64 KiB libppcp will originate (#98), and pinned by a test so it cannot be re-broken silently.

⚠ PinPointStudio should be told the profile count roughly doubles before they meet it.

⚠ Still open and NOT closed by this: #19's intrinsics overclaim. Declaration.swift declares PPCP_INTR_PER_FRAME for every camera profile unconditionally, and this phone delivers none at 1080p240 while delivering them at 1080p120. This change is that fix's precondition — the honest per-profile claim is now expressible, because the profiles now exist.