Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの 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 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@CasbaL がすでに取り組んでいます。

2026年10月9日 から。

  • #4061 @CasbaL による — マージされずにクローズ
  • #5334 @CasbaL による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
backend, performance

調査の方向性

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
平均マージ
8時間 32分
マージ済み PR（30日）
707

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

heygen-com/hyperframes のほかの issue

heygen-com/hyperframes の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。