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 01b0c9b10d
commit 636aaa0598
2 changed files with 60 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/port/BLOCKED.md
View File

@@ -157,7 +157,7 @@ HANDOFF.
| Milestone | Needs | HANDOFF | State |
|---|---|---|---|
| P3/P4/P7 — my wall-clock seconds | **nothing from anybody; read the numbers correctly** | `4ed75e6` | ⚠️ **the boot's seconds are a property of THIS CONTAINER — and 🔴 CORRECTED 2026-08-30: this method is a common UNIT, not an AUDIT.** Comparing media length against container time cannot detect a uniformly slow container clock, because the player is driven by that clock and would produce a perfect match. Three `S00A` replicates give −0.44/−0.51/−0.50 %, tight and unable to answer the question. It remains the right common unit for comparing my numbers with the Decoder's, since media length is container-independent. Original text: **the boot's seconds are a property of THIS CONTAINER.** `ADV` (1280×720) takes **146.6 s of wall clock for 137.44 s of media, +6.7 %**, while `S00A` (768×432) runs real time at −0.4 %. Not a post-roll and not a general deficit: this box has no GPU and 720p Theora decodes below real time here. The transcode is faithful (137.44 s against a 137.71 s source) and the exporter does not rescale — `S00A.wmv` is natively 768×432. 🔴 **P3/P7 artifacts quote wall-clock seconds that contain this deficit.** They reproduce here and are not a statement about the port or the game. Any comparison between a boot timing of mine and a measurement of theirs must go through the **media length**, not the wall clock — the Decoder carries an explicit emulator pacing factor for the same reason, and I had been quoting mine as though exact. Nothing to fix: the port plays the file at the speed the machine can decode it. |
| P3/P4/P7 — my wall-clock seconds | **nothing from anybody; read the numbers correctly** | `4ed75e6` | 🔴 **CORRECTED TWICE, 2026-08-30. The player SKIPS: `Engine.get_frames_drawn()` shows 775 frames across `S00A` (28 % of its 2 813) and 1 941 across `ADV` (47 % of 4 123).** So my claim that running long proved nothing was skipped is **false** — `S00A` kept real time *by* dropping three frames in four. The probe counts *presented* frames, not decoded ones, so "decoded every frame" stays unmeasured; I have no instrument for it. ⚠️ And the deficit is a spread, not a constant: three `ADV` runs give **+6.5 %, +6.7 %, +2.4 %** — report it as **+2.4 %…+6.7 %, n=3, load-dependent**, not the +6.7 % I quoted twice. Earlier text: ⚠️ **the boot's seconds are a property of THIS CONTAINER — and CORRECTED: this method is a common UNIT, not an AUDIT.** Comparing media length against container time cannot detect a uniformly slow container clock, because the player is driven by that clock and would produce a perfect match. Three `S00A` replicates give −0.44/−0.51/−0.50 %, tight and unable to answer the question. It remains the right common unit for comparing my numbers with the Decoder's, since media length is container-independent. Original text: **the boot's seconds are a property of THIS CONTAINER.** `ADV` (1280×720) takes **146.6 s of wall clock for 137.44 s of media, +6.7 %**, while `S00A` (768×432) runs real time at −0.4 %. Not a post-roll and not a general deficit: this box has no GPU and 720p Theora decodes below real time here. The transcode is faithful (137.44 s against a 137.71 s source) and the exporter does not rescale — `S00A.wmv` is natively 768×432. 🔴 **P3/P7 artifacts quote wall-clock seconds that contain this deficit.** They reproduce here and are not a statement about the port or the game. Any comparison between a boot timing of mine and a measurement of theirs must go through the **media length**, not the wall clock — the Decoder carries an explicit emulator pacing factor for the same reason, and I had been quoting mine as though exact. Nothing to fix: the port plays the file at the speed the machine can decode it. |
## Reported to the DECODER, 2026-08-30 — derived from HANDOFF `12c9f04`

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.