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

port: make the frame count permanent, then correct what I read from it twice

Browse Source 
The Decoder's closing point -- the inference is cheap and the measurement looks
expensive right up until someone does it -- is actionable, so the probe I
reverted is now permanent. The exporter records each transcode's duration and
frame rate in the manifest (probed from the file it wrote, not the source), and
every video run prints what it showed against what the media holds. An instrument
that has to be added before the question can be asked will not be there the next
time somebody reasons instead.

Then the instrument corrected me twice more.

It is an UPPER BOUND, not a count. It counts engine frames, and the engine renders
the UI at its own rate: on a quiet box ADV drew 6480 frames across a 4123-frame
video, 44 fps against the media's 30. Above that crossover it constrains nothing,
and '157% presented' is the counter used outside its range. The report now says so
instead of printing a percentage.

So 'the player skips, heavily' is not supported. At 8.3 engine fps under
contention S00A could not have shown more than 28% -- a valid bound under
contention and nothing more. Quiet, the bound is 88-90%, permitting anything from
no drops to a tenth.

And the 720p-versus-432p contrast is refuted -- the finding I sent them twice. I
reported ADV +6.7% against S00A -0.5% and built 'heavy decode falls behind, light
keeps up' on it. Quiet, both run +6.7...+6.9%. The -0.5% was a contended run in
which the player dropped frames to hold schedule. I was measuring which run
happened to share the box and reading it as a property of the resolution.

What survives is sturdier than either: playback runs +6.7%...+6.9% long on this
container, five runs, both videos, quiet, resolution-independent.

Three corrections in three iterations, all mine, all the same shape: argued from
an absence; measured and over-read; then found the measurement was taken under a
confound I introduced myself by running the suite alongside it. Their rule needs a
companion -- ask what the quantity can be skipped by, and ask what else was
running.

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:26:18 +00:00
parent bb3f59459c
commit 13bc0b02f7
6 changed files with 176 additions and 3 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` | 🔴 **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. |
| P3/P4/P7 — my wall-clock seconds | **nothing from anybody; read the numbers correctly** | `4ed75e6` | 🔴 **CORRECTED THREE TIMES, 2026-08-30. Settled reading: playback runs +6.7 %…+6.9 % long on this box, 5 runs, BOTH videos, quiet — consistent and RESOLUTION-INDEPENDENT.** The `ADV`-versus-`S00A` contrast I reported (+6.7 % against −0.5 %) is **refuted**: the −0.5 % run was contended and the player dropped frames to hold schedule. The frame counter is an **upper bound on frames shown, vacuous once the engine outruns the stream** — quiet, `ADV` drew 6 480 engine frames across a 4 123-frame video. So *"the player skips heavily"* is **not supported** either; at 8.3 engine fps under contention `S00A` could not have shown more than 28 %, and that is all it said. Earlier text: **CORRECTED TWICE. 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`

54
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 -->
255 sections. Search this before re-deriving anything.
256 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)
@@ -266,6 +266,7 @@ dies, which is what this file is for.
* [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)
* [🔴 Correcting the correction: the frame probe is an UPPER BOUND, and my contrast was contention](#correcting-the-correction-the-frame-probe-is-an-upper-bound-and-my-contrast-was-contention)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -13152,3 +13153,54 @@ candidates, 0 real, because in that corpus 🔴 marks a correction being deliver
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.
## 🔴 Correcting the correction: the frame probe is an UPPER BOUND, and my contrast was contention
I refuted my own claim yesterday with a frame counter and reported *"the player
skips, heavily — 28 % of `S00A`'s frames and 47 % of `ADV`'s"*. **Both numbers
were taken while other work was running on this box, and the instrument does not
mean what I said it means.**
Measured again with nothing else running:
| | engine frames | media frames | span vs media |
|---|---|---|---|
| `S00A` ×3 | 2 531 / 2 532 / 2 477 | 2 813 | **+6.8 %, +6.8 %, +6.7 %** |
| `ADV` ×1 | **6 480** | 4 123 | **+6.9 %** |
**`ADV` drew 6 480 frames across a 4 123-frame video — 157 %.** The engine renders
the UI at its own rate, not the movie's, so engine frames bound *shown* frames
from above **only while the engine is slower than the stream**. Above that
crossover the counter constrains nothing, and "157 % presented" is not a
measurement — it is the instrument used outside its range. The runtime report now
says exactly that instead of printing a percentage.
### Two of my own claims fall, and one of them was the headline
* 🔴 **"The player skips, heavily" is not supported.** What the contended run
showed is that at 8.3 engine fps `S00A` *could not* have shown more than 28 % —
a valid upper bound under contention, and nothing more. On a quiet box the
bound is 88–90 %, which permits anything from no drops to a tenth.
* 🔴 **The 720p-versus-432p contrast is refuted, and it was the finding I sent
them twice.** I reported `ADV` +6.7 % against `S00A` −0.5 % and built
"heavy decode falls behind, light decode keeps up" on it. **Quiet, both run
+6.7 … +6.9 %.** The −0.5 % was a *contended* run in which the player dropped
frames to hold its schedule. **I was measuring which run happened to share the
box, and reading it as a property of the resolution.**
✅ **What survives, and it is now the sturdiest number here:** playback runs
**+6.7 % … +6.9 %** long on this container, five runs, both videos, quiet —
consistent and resolution-independent. That is a real deficit and it is *not* the
mechanism I described.
📌 **Three corrections in three iterations, all mine, all the same shape.** I
argued from an absence; measured it and over-read the measurement; then found the
measurement was taken under a confound I had introduced myself by running the
suite alongside it. **The instrument was right to build and I published each
reading before asking what else was true of the run that produced it.** The
Decoder's rule needs a companion: ask what the quantity can be skipped by — *and
ask what else was running.*
⚠️ The probe stays **permanent and printed by default**, with its crossover
stated in the report itself. Its value was never the first number it gave; it is
that the next claim about frames has to be made in front of it.