Skip to content

docs(aws-lambda): explain long-video planning limits - #5263

Open
user-github-me wants to merge 8 commits into
heygen-com:mainfrom
user-github-me:docs/lambda-long-video-planning-limits
Open

user-github-me wants to merge 8 commits into
heygen-com:mainfrom
user-github-me:docs/lambda-long-video-planning-limits

Conversation

@user-github-me

@user-github-me user-github-me commented Oct 8, 2026 •

Copy link
Copy Markdown
Contributor

Long videos can still spend too much time in Lambda planning when their sources cannot defer extraction to chunk workers. Document how to identify the failed phase, configure the deployed function, and split jobs that exceed an invocation's time or temporary-storage budget.

The guidance now matches current main: ordinary CFR and VFR extraction runs in segments of up to two minutes, and FFMPEG_PROCESS_TIMEOUT_MS limits time without a new frame rather than total extraction time. It also distinguishes eligible Plan v2 deferral from extraction that still occurs during Plan, preserves the current byte-range input reads, and identifies the arm64 video function used by default deployments. This incorporates the earlier review request and the subsequent extraction changes in #5921, which supersede the old VFR-only deadline advice.

Validation: current implementation traced for extraction, stall detection, Lambda routing, and CDK configuration; 27 existing FFmpeg process tests passed; full workspace build, Mint validation/link checks, normal commit hooks, and both comment checks passed. No AWS deployment was performed.

The timeout example now identifies render as the HyperframesRenderStack instance created in the CDK example above. This prose-only follow-up passed documentation validation, broken-link checks, normal commit hooks and both comment checks.

@jrusso1020 jrusso1020 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.

Thanks for writing this up. Several parts are accurate and useful:

  • the Plan step description;
  • the point that smaller chunks don't reduce Plan's extraction work;
  • setting the variable on the deployed function rather than in the local shell;
  • splitting oversized jobs.

However, #5280 changes extraction so that ranges longer than two minutes run as two-minute segments, each with its own process timeout, and it adds a bullet in the same place under Current limits. Once it lands, the troubleshooting text saying the 300,000 ms timeout covers the whole extraction, and the advice to raise it for long clips, will be out of date. That advice still applies to variable-frame-rate sources, which are extracted in one pass.

Could you rebase after #5280 merges, reword the timeout guidance for per-segment timeouts (scoped to the variable-frame-rate case), and fold your Current limits bullet into the one #5280 adds?

— Rames

@user-github-me
user-github-me force-pushed the docs/lambda-long-video-planning-limits branch from 3602253 to 6a1c596 Compare October 8, 2026 19:52
@jrusso1020

Copy link
Copy Markdown
Collaborator

Thanks for this, @user-github-me. This PR now has merge conflicts with main. Could you rebase it onto the latest main? Once it's conflict-free we'll review it and get it into the merge queue.

@mintlify

mintlify Bot commented Oct 24, 2026 •

Copy link
Copy Markdown

Preview approval required

This pull request comes from a fork, so Mintlify won't build a preview until someone with write access approves commit 24a9ba2.

Approve preview

@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.

Thanks for the rebase and the rework. I checked the new text against current main, and it holds up:

  • ffmpeg_timeout is now a no-new-frame timer (videoFrameExtractor.ts, the inactivity branch that reports "no new frame for N ms"), so "frame progress resets that timer" is right.
  • Extraction runs in segments of up to 120 seconds, including VFR sources.
  • Plan v2's deferral skips VFR sources and HDR conversions and probes the last second of the source, which matches "after a short timing probe".
  • HyperframesRenderStack exposes renderFunction, so the CDK snippet works.

The earlier asks are covered: the timeout advice is about stalls rather than total time, and there's one Current limits bullet instead of two.

One optional nit: the snippet's render isn't defined anywhere. A comment such as // render = new HyperframesRenderStack(app, "Render", …) would save readers a lookup.

Reviewed head 16b6238a. It merges cleanly with main, and the docs checks are green.

Verdict: APPROVE
Reasoning: A docs-only change whose technical claims all match current main; the earlier change requests are addressed and CI is green.

@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.

Thanks for picking up the nit. The new sentence points at the right thing: the CDK example above creates render as the HyperframesRenderStack instance. Nothing else changed since my last review, so that approval stands at this head.

Reviewed head 24a9ba2d. Docs checks are green.

Verdict: APPROVE
Reasoning: The only change since the last approval is a one-sentence clarification that matches the CDK example in the same page.

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.

3 participants