Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

[Windows] Disk-capture headroom gate rejects ordinary renders: uncompressed-RGBA estimate (~16 GB for ~1 min of 1080p) and no streaming fallback

未关闭
#4,060 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@CasbaL 已经在做这个了。

开始于 2026年9月18日。

  • #4061 来自 @CasbaL —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
52/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
typescript

调研方向

Start by locating estimateDiskCaptureBytes, executeRenderJob, and shouldUseStreamingEncode, then trace how the initial capture plan applies the disk-headroom gate. Confirm how JPEG and PNG formats are selected and where capture telemetry observes the plan. Done means compressed-format estimates use the stated safety margins and an eligible single-worker render degrades to streaming before capture; run the relevant render tests if present.

由索引模型根据 Issue 内容生成。

描述

triage/needs-triage
Describe the bug

On Windows (and any host with modest free disk), ordinary renders were rejected by the disk-capture headroom gate with a message like:

Disk capture may need ~16331.7 MB of temporary frame storage, but only 18092.4 MB is free at
C:\Users\...\AppData\Local\Temp\hf-render-xxxx\captured-frames. Re-run with --low-memory-mode ...

A few seconds of video "requiring 16 GB" looks alarming — and in our field case the machine had 18 GB free yet a ~1-minute 1080p30 export was refused only because the estimate crossed the 90% gate by 48 MB. Two compounding problems:

1. The estimate is an uncompressed RGBA ceiling, while disk frames are written compressed.
estimateDiskCaptureBytes bills totalFrames × width × height × 4 (raw RGBA), but the capture stage writes jpg (or png for alpha). Measured 1080p JPEG captures land at ~150–400 KB/frame — roughly 1/20–1/30 of the estimate. A 44 s 1080p30 composition estimated at ~11 GB against 11.4 GB free failed, with an actual JPEG footprint of a few hundred MB.

2. When the gate rejects, the render fails outright even when streaming was possible.
Auto-parallel renders always take the disk path (ordered streaming would stall later workers), and shouldUseStreamingEncode requires workerCount === 1 — so the only reason a render landed on the disk path was parallelism. The gate then runs as a hard error at capture time instead of a replan trigger. Long renders past the streaming duration cap (240 s) had no escape at all: 5 minutes of 1080p30 estimated at ~60 GB under the RGBA ceiling, rejecting effectively every machine.

Expected behavior
  • The estimate should reflect the actual (compressed) capture format with a safety margin, not a raw RGBA ceiling.
  • When disk headroom is insufficient but single-worker streaming is eligible for the render, the orchestrator should degrade the plan to single-worker streaming instead of failing.
Environment
  • Windows 11 x64, HyperFrames producer ~v0.8.40 (observed in an Electron integration; applies to CLI renders too)
  • C: drive with ~18 GB free; capture temp dir on the system drive (hf-render-*)
Proposed fix

Two-part (PR to follow):

  1. estimateDiskCaptureBytes bills by capture format: JPEG 0.5 B/px (keeps a ~5× safety margin, shrinks the estimate 8×) and PNG 2 B/px (lossless, half the RGBA ceiling). Gate message updated to the compressed-frame estimate basis.
  2. executeRenderJob checks the gate right after the initial capture plan is built; when headroom is insufficient and shouldUseStreamingEncode(cfg, format, 1, duration) is true, the plan degrades to single-worker streaming via a shouldDegradeDiskCaptureToStreaming predicate — before capture and telemetry observe it, so the degraded plan is indistinguishable from one the streaming gate chose up front.
主要语言
TypeScript
星标
54.1k
派生
4.9k
平均合并
7 小时 2 分钟
30 天内合并 PR
782

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

heygen-com/hyperframes 的其他 Issue

查看 heygen-com/hyperframes 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。