docs(overlays): record the alert-clip/media decode overlap
This commit is contained in:
+10
-1
@@ -93,7 +93,16 @@ published decisions (recorded in `TASKS/task-43-native-alerts.md`):
|
||||
AND the file exists; the shipped `Assets/alert-default.mp4` is stamped into the `Asset`
|
||||
table at startup (`AlertDefaultVideoKey` setting; the prune keeps it via UNION) and
|
||||
read-at-play; any decode failure falls back to the six `AlertRenderer` animations
|
||||
(deliberate, not an error). Fades in/out via **`FadeDurationSeconds = 0.30`**
|
||||
(deliberate, not an error). **Known overlap (recorded 2026-11-05):** the video half of
|
||||
`AlertClipDecoder.RunVideoAsync` and `MediaVideoSource.RunAsync` are near-duplicates —
|
||||
same ffmpeg args (`-f rawvideo -pix_fmt bgra -vf scale=W:H -an -`), same
|
||||
`RawVideoFrameReader` feed loop, same `IFrameRateProbe` + delay pacing, both behind
|
||||
`IDecodeProcess`. What differs is ownership and role, not decoding: alerts are per-play
|
||||
and disposed at drain, media is a refcounted per-path session; alerts also run an
|
||||
`f32le` audio pipe into the mixer, media deliberately sends no audio (the desktop
|
||||
loopback carries it, TRAX-style); alerts play once, media loops. A shared raw-video pump
|
||||
is the obvious consolidation if a third consumer appears — do not do it for two.
|
||||
Fades in/out via **`FadeDurationSeconds = 0.30`**
|
||||
(`AlertOverlayLayer` const): fade-in by `elapsed` on straight-alpha frame copies;
|
||||
EOF → freeze-frame → fade-out → drain (the clip branch of `Advance` **clears
|
||||
`_current` before `AdvanceToNext`** — the miss that the TASK 47 test caught). Audio
|
||||
|
||||
Reference in New Issue
Block a user