fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

method: land the pacing re-correction itself

Browse Source 
The previous commit's message described this change but an exact-match miss meant
only the ui-keyframe-time-unit.md half landed. This is the METHOD half: their
argument was refuted by their own frame count (28 % and 47 % of frames presented),
so my correction of a correct entry is withdrawn and the original reading stands.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 23:08:48 +00:00
parent 5eabcf07b0
commit 40cf9b5025
1 changed files with 30 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
docs/re/METHOD.md
View File

@@ -2469,19 +2469,37 @@ elapsed clock time stays on schedule by doing less work: a uniformly starved clo
presents fewer frames per real second and still finishes in exactly the media's
duration. **The failure produces the appearance of success.**
🔴 **CORRECTED 2026-08-30, same day — I described their measurement as the
skippable kind and that was wrong.** They pointed out that the *overrun is itself
the evidence*: a player dropping frames to keep up finishes **early or on time**,
and theirs ran **146.6 s for 137.44 s of media**. Running long is inconsistent with
having skipped its way back onto schedule. So their `ADV` +6.7 % and `S00A` −0.5 %
belong to the time-to-consume class after all — the class endorsed below — and the
withdrawal applies only to the *audit* use, not to the load-starvation finding.
🔴 **CORRECTED TWICE, and the second correction restores the first reading.**
They argued the overrun was itself proof nothing was skipped — a player dropping
frames finishes early or on time, and theirs ran **146.6 s for 137.44 s of media**.
I accepted that and rewrote this entry. **Then they measured it**, counting the
frames the engine actually drew:
⚠️ One refinement they did not claim and I would not grant: running long proves the
player did not skip **enough to stay on schedule**, not that it skipped *nothing*.
Any dropping that did occur makes the true decode time longer still, so **+6.7 % is
a lower bound on the deficit**. That cuts in favour of their conclusion, not
against it.
| | engine frames | span | frames in media | presented |
|---|---|---|---|---|
| `S00A` 768×432 | 775 | 93.33 s | 2 813 | **28 %** |
| `ADV` 1280×720 | 1 941 | 140.77 s | 4 123 | **47 %** |
**The player skips, heavily.** `S00A` held real time *because* it dropped three
frames in four — the mechanism the argument said was absent. So the reading above
was right, their argument was wrong, and **my correction of it was wrong**.
⚠️ **I corrected a correct entry on an argument, having just written on this page
that a consumption counter is what makes an audit.** Their inference sounded right
and I did not ask what would measure it; the measurement was four lines. **An
argument from an absence — "no overrun would be visible if frames were dropped" —
is not evidence, and accepting one is the same error as making one.**
📌 Their own limit, which they stated and I would not have caught: the probe counts
**presented** frames, not **decoded** ones. Theora is inter-frame predicted, so a
decoder must decode frames it never shows. This refutes *"presented every frame"*
and leaves *"decoded every frame"* unmeasured. `read_offset` is a consumption
counter precisely because it cannot have that gap.
🔴 **And their figure is a spread, not a value**: three `ADV` runs gave **146.42,
146.60, 140.77 s** → **+2.4 %…+6.7 %, n=3, load-dependent**. It reached this corpus
twice as a flat "+6.7 %". The qualitative finding — heavy decode falls behind,
light does not — survives as a **lower bound measured under skipping**.
⚠️ My audio measurement survives that objection, and it is worth being precise
about *why*, because the two look alike: `input_buffer_read_offset` is a