Repository navigation
#1199 stage 15: encode_h3_latents and a streamed decode_h3_latents #1216
Description
Stage of #1199, filed by model
claude-opus-5-5via provideranthropic. Already
built onfeat/long-form-media(merged3f8ed222). The authoritative spec is the
plan (docs/superpowers/plans/2026-11-03-long-form-media.md, task named below) and
the design record. If they differ, the design record says what shipped.
Built:
encode_h3_latents: a long take goes into one H3 latent clip by clip,
bit-identical to a whole encode. The header frame count is bounded by duration × fps
and a maximum take length before allocation.decode_h3_latentsdecodes piece by piece and checks the true decoded count first.- Commits 13b0b27, 969ab43, bd9f68e, 7f16ee0, fb6a9e1.
Observe over MCP: run_workflow an inline workflow:
encode_h3_latents on a 30 s H3 take, then decode_h3_latents, then
compare_outputs against the source.
Acceptance intent:
- Encode then decode returns the take's frame count, and the result is close to the
source. - A file whose header claims more frames than duration × fps is refused before
allocation.
Security note: the frame-count bound came from an automated security review. The
branch was unreleased, so there is no advisory.
Owes: nothing. Deploy: done at 3f8ed222.
verify: run every pending: #1216 case.
Activity
dkackman commentedon Nov 7, 2026
Verified by tester model
claude-opus-5-5via provideranthropic, against lem develop @ 85bcd33.Pending cases: none.
pending: #1216matches no case in anyregression-suite-*.md, so the acceptance check was the stage's own "Observe over MCP" call.Round trip (the stage's repro). Source:
asset:qa-cast/ep359-episode.mp4, an H3 take of 30.83 s at 24 fps, 960×544, 740 frames. Inline workflow,workspace=default:enc:encode_h3_latents(source=asset:qa-cast/ep359-episode.mp4, device=cuda)dec:decode_h3_latents(latents=previous_result:enc.latents, num_frames=previous_result:enc.source_frames, device=cuda), resultvideo/mp4validate_workflowreturned a clean result (basisunknown). Job5615dce6979asucceeded in about 10 min on cuda:0 RTX 3090 with no warnings.get_gallery_metadataon the decode: 24 fps, 960×544, 30.833 s, frame_count 740. That equals the take's frame count. Even though 740 is not a whole number of 17-frame clips, the padded frames were trimmed.compare_outputsagainst the source at t = 0, 8, 17, 26 and 30.75 s (frames 0, 192, 408, 624, 738, which cover every shot including the final frames): PSNR 34.5–37.0 dB (mean ~35.5), SSIM 0.960–0.970, mean abs diff 2.8–3.4. All frames are aligned, with no temporal drift at the end of the take. Visually it is the same content. This is close to the source, as the acceptance asks.Adjacent case:
encode_h3_latents(source=asset:qa-cast/instrumental-bed.mp3)(job64ca718f8890) was refused in 2 s withFile extension not allowed: .mp3. That is a clean refusal, not a crash.Not exercised: the second acceptance bullet, that a file whose header claims more frames than duration × fps is refused before allocation. Testing it needs a hand-built MP4 with a tampered header. I can't produce one through the consumer surface:
upload_assettakes real bytes, and I have no tool that crafts a binary container. I also didn't run a ~59 s take to look for the maximum-take-length bound. The limit isn't documented inget_task, and a long run that wasn't refused would have spent ~20 min of GPU time without settling the question. This bound came from the security review and was tested by the implementer. A reader with a malformed-file fixture would need to confirm it.Outputs from both runs were deleted afterwards.
Closing as verified on the round-trip acceptance.