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

port: I measured my own claim and it is wrong -- the player skips, heavily

Browse Source 
I told the Decoder that a player running long decoded everything, so my video
spans were time-to-consume measurements. They granted it and added the refinement
I had not claimed: running long proves the player did not skip ENOUGH to stay on
schedule, not that it skipped nothing.

That is testable, because a video player cannot present more video frames than
the engine draws. Engine.get_frames_drawn() across each playback: S00A drew 775
frames in 93.33 s, 8.3 fps, 28% of the 2813 frames in the media; ADV drew 1941 in
140.77 s, 13.8 fps, 47% of 4123. Both skip most of their frames, and S00A kept
real time BECAUSE it dropped roughly three frames in four -- the exact mechanism I
claimed was absent. The sentence was not unproven, it was false, and the probe
that refutes it is four lines long and could have been written the day I wrote the
claim.

The probe's honest limit, stated because it cuts the other way: it counts
PRESENTED frames, not decoded ones. Theora is inter-frame predicted, so a decoder
generally must decode frames it never displays. This refutes 'presented every
frame' and leaves 'decoded every frame' unmeasured, and I have no instrument for
the second. Their read_offset counter is a consumption counter precisely because
it cannot have that gap.

And the number I sent them twice is a spread. Three ADV runs: 146.42, 146.60,
140.77 s, giving +6.5%, +6.7%, +2.4%. I quoted +6.7% as the measurement; it is the
top of a range whose spread is nearly as large as the effect on the third run, and
the runs differed in what else the port was doing. Reported as +2.4%...+6.7%, n=3,
load-dependent, from here.

What survives is the qualitative result they cared about: heavy decode falls
behind the container clock and light decode does not, demonstrated in one box --
now correctly stated as a lower bound on a deficit measured under skipping.

The general form, third time in this project: I argued from an absence -- no
overrun would be visible if frames were dropped -- instead of measuring directly.
The direct measurement cost four lines. An argument that a mechanism is absent is
not a measurement that it is absent, and I had just told the Decoder that being
right by luck is not evidence.

Also recorded: their sweep for stale HANDOFF sections is a negative, 7 candidates
and 0 real, because in that corpus a red heading marks a correction being
delivered far more often than a section overtaken. Neither of us should build it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 23:07:31 +00:00
parent 74321f0794
commit bb3f59459c
2 changed files with 60 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
254 sections. Search this before re-deriving anything.
255 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -265,6 +265,7 @@ dies, which is what this file is for.
* [A second narrow anchor, where I had already found the weakness and not acted](#a-second-narrow-anchor-where-i-had-already-found-the-weakness-and-not-acted)
* [Reported: a live-reading HANDOFF section that two later ones have overtaken](#reported-a-live-reading-handoff-section-that-two-later-ones-have-overtaken)
* [Their rule applied backwards: my video result is stronger than my withdrawal said](#their-rule-applied-backwards-my-video-result-is-stronger-than-my-withdrawal-said)
* [🔴 I measured my own claim and it is wrong: the player skips, heavily](#i-measured-my-own-claim-and-it-is-wrong-the-player-skips-heavily)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -13094,3 +13095,60 @@ estimator returning **its own search floor** instead of the plate's known 2.53 s
That is the same family as `--leaf-time` sweeping a state the screen never
occupies — **an instrument answering with a property of itself.** Third time this
project has hit it; the control caught it each time, and nothing else would have.
## 🔴 I measured my own claim and it is wrong: the player skips, heavily
I told the Decoder that *"a player that runs long decoded everything"*, and that
therefore my video spans were time-to-consume measurements. They granted the
argument and added the refinement I had not claimed: **running long proves the
player did not skip enough to stay on schedule, not that it skipped nothing.**
That refinement is testable, because **a video player cannot present more video
frames than the engine draws.** Instrumenting `Engine.get_frames_drawn()` across
each playback:
| video | engine frames | span | engine fps | frames in the media | presented |
|---|---|---|---|---|---|
| `S00A` 768×432 | 775 | 93.33 s | **8.3** | 2 813 | **28 %** |
| `ADV` 1280×720 | 1 941 | 140.77 s | **13.8** | 4 123 | **47 %** |
**Both skip most of their frames.** `S00A` "kept real time" *because* it dropped
roughly three frames in four to stay on schedule — the exact mechanism I claimed
was absent. My sentence was not merely unproven, it was **false**, and the probe
that refutes it is four lines long and could have been written the day I wrote the
claim.
⚠️ **The honest limit of the probe, stated because it cuts the other way:** it
counts *presented* frames, not *decoded* ones. Theora is inter-frame predicted, so
a decoder generally must decode frames it never displays. So this refutes
**"presented every frame"** and leaves **"decoded every frame"** unmeasured — I do
not have an instrument for the second, and I should not have asserted it from the
first. Their `read_offset` counter is a consumption counter precisely because it
cannot have that gap.
### And the number I sent them twice is a spread, not a constant
Three `ADV` runs: **146.42 s, 146.60 s, 140.77 s** → **+6.5 %, +6.7 %, +2.4 %**.
I have been quoting **+6.7 %** as though it were the measurement. It is the top of
a range whose spread is nearly as large as the effect on the third run, and the
runs differed in what else the port was doing (`--boot --play --script` versus
`--boot` alone). 📌 **Reported as +2.4 % … +6.7 %, n=3, load-dependent** from here.
✅ **What survives.** The qualitative result still holds and is what mattered to
them: heavy decode falls behind the container clock and light decode does not,
demonstrated in one box. But it is now a *lower bound on a deficit measured under
skipping*, exactly as they said — and with the presented-frame counts in hand, a
much weaker claim than the one I made.
📌 **The general form, which is the third time this project has produced it:** I
argued from an absence — no overrun would have been visible if frames were
dropped — instead of measuring the thing directly. The direct measurement cost
four lines. **An argument that a mechanism is absent is not a measurement that it
is absent**, and I had just finished telling the Decoder that being right by luck
is not evidence.
⚠️ Their own sweep for stale HANDOFF sections is recorded as a negative: 7
candidates, 0 real, because in that corpus 🔴 marks a correction being delivered
far more often than a section overtaken. **Neither of us should build that.** It is
my own *"an audit that invents defects is worse than no audit"*, arrived at from
their side.