UNIT 0 reading: the camera was never the problem, so Unit 1 is the wrong lever
Take ty-20261005-1201-556-0001.mp4 (75.3s) plus its log settle it. The C920 delivers 30.0/s with ZERO gaps over 50ms and its own device stamps agree - camera, USB and driver are clean. The pump managed 34 composites per 5s at ~141ms each, and the file holds 6.8 distinct webcam images per second at 88.7% duplicates with no arrival hitch whatsoever. The judder is us holding one face for 140ms and padding the rest of a 60fps container, which is precisely what a lipreader experiences as "cutting out". So 720p is a SHARPNESS win, not a smoothness win: it triples the bytes the compositor stretches per render on a path already 4.4x over budget. The exclusive camera lock stays agreed and stays queued, but it moves after the compositor work or it makes the judder measurably worse. The number still unexplained: the 10:01 take hit 25.6 images/s and this one 6.8, with the same scene shape (full-render split=0 elements=6 dynamic=5) and the same 640x480 camera - composites went 29-34ms to 143-155ms between sessions and nothing logged says why. There is no per-element composite breakdown and no scene dump at pump start, so the next unit is measurement, not a fix. Recorded the pump-counter overcount (13/s vs 6.8/s: one 141ms composite lets ~4 camera frames arrive, and the counter stamps the first epoch the resolver sees, not the frame actually drawn) so it is not re-derived as a bug later.
This commit is contained in:
@@ -160,13 +160,22 @@ second encoder path needing a "redirect". Record+simulcast is one ffmpeg with tw
|
||||
webcam judders, ~1 hitch in 5, invisible in the output file). **UNIT 0 shipped** (counters +
|
||||
`Helpers/FrameCadence.cs`; see `ai.md` → "Frame cadence"). **Needs a creator recording before the
|
||||
next unit.** Remaining units, all agreed 2026-10-05, one Good Dog test each:
|
||||
- **Unit 1:** `MediaCaptureSharingMode.ExclusiveControl` + MJPG ≥30fps up to 1280×720 via the
|
||||
existing `SetMediaStreamPropertiesAsync` path (refused only because `SharedReadOnly`); same-camera
|
||||
`SharedReadOnly` retry. **The creator reversed the ban on taking an exclusive camera lock.**
|
||||
API probe already done — see HANDOFF.md, incl. the `SetFormatAsync` dead end.
|
||||
- **Unit 2:** blinking amber **"SD" badge**, preview only, never in the recording/stream, when a
|
||||
better format was available and not obtained. Top-right corner, or the 1:30 rim point when the
|
||||
clip is round.
|
||||
- **⛔ UNIT 1 IS NOT NEXT — re-scoped 2026-10-05.** The first real reading exonerated the camera:
|
||||
it delivers 30.0/s with zero hitches; the compositor manages **6.8 composites/s at ~141ms each**,
|
||||
so the file is **88.7% duplicate frames** and that is the judder. 720p triples the bytes stretched
|
||||
per render on an already-over-budget path. Keep `ExclusiveControl` + 720p as a **sharpness** win
|
||||
and schedule it AFTER the compositor work.
|
||||
- **⏭ ACTUAL NEXT: per-element composite timing + a scene dump at pump start.** One run names which
|
||||
of the 6 elements eats 140ms and explains the 10:03→12:01 regression (29–34ms → 143–155ms, same
|
||||
scene shape). Measurement only — no fix until it names the element.
|
||||
- **Unit 2 (later, unchanged):** blinking amber **"SD" badge**, preview only, never in the
|
||||
recording/stream, when a better format was available and not obtained. Top-right corner, or the
|
||||
1:30 rim point when the clip is round.
|
||||
- **Deferred to after Unit 1:** `MediaCaptureSharingMode.ExclusiveControl` + MJPG ≥30fps up to
|
||||
1280×720 via the existing `SetMediaStreamPropertiesAsync` path (refused only because
|
||||
`SharedReadOnly`); same-camera `SharedReadOnly` retry. **The creator reversed the ban on taking an
|
||||
exclusive camera lock.** API probe already done — see HANDOFF.md, incl. the `SetFormatAsync`
|
||||
dead end.
|
||||
- ⛔ **No fallback-camera feature, ever** — *"that's bypassing the user's explicit choice."*
|
||||
- ⛔ **No background removal** — re-affirmed out 2026-10-05.
|
||||
- **TASK 40 — App Settings round** — plan saved 2026-09-22 (`TASKS/task-40-app-settings-round.md`),
|
||||
|
||||
Reference in New Issue
Block a user