Skip to content

fix(render): let streaming capture span 25-90% so progress tracks frames done - #7722

Open
sx4im wants to merge 2 commits into
heygen-com:mainfrom
sx4im:fix-7713-render-progress-lag
Open

sx4im wants to merge 2 commits into
heygen-com:mainfrom
sx4im:fix-7713-render-progress-lag

Conversation

@sx4im

@sx4im sx4im commented Nov 14, 2026

Copy link
Copy Markdown

Summary

Fixes #7713. On the streaming render path the progress bar sat at 77% when 95% of the frames were done, because streaming capture only got the 25-80 band while encoding kept the 80-90 band for a drain that lasts under a second. Encoding is fused into capture on this path, so the 80-90 band was nearly empty by construction.

Change and scope

  • New streamingCaptureProgress helper in packages/producer/src/services/render/shared.ts: streaming capture now spans 25-90, leaving 90-99 to assemble.
  • All 8 call sites use it: captureStreamingStage.ts (4), captureSegmentedStage.ts (2), and the two HDR loops (1 each).
  • Out of scope: the disk path keeps its 25-70 band plus a separate encode phase, which is honest there.

Evidence and regression coverage

  • New tests in shared.test.ts: 2856/3000 now reads 87% (was 77%), 14912/15723 reads 87%, full capture reads 90%.
  • bun test on shared.test.ts + captureStreamingStage.test.ts: 61 pass; captureSegmentedStage.test.ts: 40 pass.
  • tsc --noEmit clean; oxlint 0 errors; oxfmt --check clean.

Fixes #7713

…mes done

On the streaming path the bar sat at 77% when 95% of frames were done:
streaming capture only got the 25-80 band while encoding kept 80-90 for
a drain that lasts under a second, because encoding is fused into capture
on this path. Streaming capture now spans 25-90 via a shared helper,
leaving 90-99 to assemble. The disk path keeps its 25-70 band plus a
separate encode phase, which is honest there.

@miguel-heygen miguel-heygen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change looks right: all 8 streaming capture call sites move to the 25-90 band, none are left on the old 55-point band, and since the encode drain starts from job.progress the bar never steps back.

One thing before it can merge: the Comments check fails on the comment ratchet. The new doc comment raises shared.ts from 17.9% (128/715) to 18.4% (134/729) comment lines, and a file's share may only go down. A one-line version keeps it under the base:

/** Streaming paths only: encoding happens inside capture, so capture spans 25-90 and assemble takes 90-99 (the disk path keeps 25-70 plus encode). */

Push that and I'll approve.

….ts comment share down

The Comments workflow ratchet fails when a changed source file gains
comment lines and its comment share rises: shared.ts went 17.9% (128/715)
to 18.4% (134/729) on the 7-line doc block for the new helper. Condense
it to one line keeping the why (encoding is fused into capture); share
returns to 17.9% (129/722), under the base.

@miguel-heygen miguel-heygen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified at f72b2d4 (comment trimmed to one line): all 8 streaming capture call sites move to the 25-90 band, none left on the old 55-point band; the encode drain starts from job.progress so the bar never moves back, and assemble keeps 90-99. Disk path untouched. CI green.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Render progress bar sits at 77% when 95% of a long streaming render is done

2 participants