feat(demo): reshoot the video against the shipped product, five photos concurrent - #56
Merged
Merged
Conversation
added 2 commits
August 3, 2026 19:12
…s concurrent
The committed cut was accurate when it was made and went stale within a day.
Four things shipped after it and the video contradicted all of them: the photo
cap is 5 and the UI says that cap belongs to the demo rather than the reel
maker, the wait is derived from the photo count, generation runs concurrently,
and the job id is in the URL so a reload no longer loses the run. The old
narration's "about five minutes a photo" described a sequential pipeline that
no longer exists, which had stopped being a stale detail and become a
misleading one.
Reshot as one unbroken take of a full five-photo run against the live service
at the commit /health was reporting. The video is 2:50 (169.70s), under the
180s cap, and 95.9s of it (56.5%) is live screen capture, up from 68.2s (44%).
Ten beats, six of them footage, including a new beat in which the tab is
reloaded mid-job and the same live reel is picked back up from the link.
Measured on the run in the video: 1508.6s of provider work completed in 445.7s
of wall clock across 5 concurrent Kling calls, a 3.4x compression. Saved
verbatim from GET /reels/jobs/<id> as demo/video-assets/usage.txt, and beat 4
quotes that run rather than an estimate.
Playwright records the page viewport only, so #reel/<job_id> can never be in
frame. The reload beat is built on the app's own resume copy instead, which is
real in-page evidence that the reload recovered a running job. A first pass
had beat 3 point at the derived estimate on screen; that line sits below the
fold behind the caption band and is not in frame, so the claim moved to beat 4
where it is plainly legible for the whole beat.
Also fixes deploy/deploy-cloudrun.sh, which still pinned --memory 512Mi. A
5-photo concurrent run OOM'd live ("Memory limit of 512 MiB exceeded with 527
MiB used") and the service was raised to 2Gi by hand, so the next deploy would
have put the OOM straight back.
Voice unchanged (Rachel). Narration only, no music, single AAC track. Zero
em-dashes in captions, narration and SRT. Every footage beat is shorter than
its source clip (slack 0.47s to 0.50s), so nothing freezes on a cloned frame.
…the stale 9/9 entry Two follow-ups on the reshoot. cut-footage.py cuts a fixed length out of one continuous recording with no upper bound of its own, so a beat can silently run past the end of its phase. That only bites where the next thing on screen is a distinct event, which today is 04-rolling: the take reloads the tab immediately after it, and lengthening that narration by ~1.7s would put the reload at the end of beat 04 and again as the whole of beat 05, with nothing failing. New BOUNDS table asserts the clip fits, so that lands as a build error instead of a duplicated reload. PHASE_FLOOR in capture-live.py already guarded the other direction (a take too quick to fill a beat); this is the same invariant from the other side. Also marks the earlier STATE.md entry superseded. It asserted "9/9 checks passed" as a live claim about the video, which was true of the two-photo take and is not true of the five-photo one (12/12). The narration itself states no count, so it cannot go stale again.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The committed cut (2:34, 68.2s of footage) predated four changes that are now live, and contradicted all of them:
The old narration's "about five minutes a photo" described a sequential pipeline that no longer exists. That had stopped being a stale detail and become a misleading one.
What changed
Reshot as one unbroken take of a full five-photo run against the live service at the commit
/healthwas reporting (9fe2f24).New footage beat 05-link: the tab is reloaded mid-job and the same live reel is picked back up from the link.
Narration fixed where it was wrong
GET /reels/jobs/<id>asdemo/video-assets/usage.txt.21m00Tcm4TlvDq8ikWAM).One claim was cut because the picture could not back it
A first pass had beat 3 say "read the line beneath" about the derived estimate. That line sits below the fold behind the caption band and is not in frame. The claim moved to beat 4, where
5 photos usually take about 6 minutes.is plainly legible for the whole beat, and beat 3 went back to being about the occasions.Likewise, Playwright records the page viewport only, so
#reel/<job_id>in the address bar can never be in frame. Rather than fake an overlay, the reload beat is built on the app's own resume copy ("Picking this reel back up", "Already in progress"), which is real in-page evidence that the reload recovered a running job.Nothing freezes
The build pads short footage with
tpad=stop_mode=clone, so every beat was re-checked against its source clip after the final narration was measured:Cloud Run memory
deploy/deploy-cloudrun.shstill pinned--memory 512Mi. A 5-photo concurrent run OOM'd live (Memory limit of 512 MiB exceeded with 527 MiB used) and the service was raised to 2Gi by hand, so the next deploy would have put the OOM straight back. Now pinned to 2Gi with the reason written next to it.Gates
scripts/check_video.pygreen at 169.70s: under the 180s cap, H.264/yuv420p 1280x720 30fps, single AAC track (no music), 10 cues matched to 10 beats by order, timing and text.README.md,demo/SUBMISSION.md,demo/STATE.mdanddemo/video-script.mdreconciled to the new duration and footage share.