Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#4,060 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@CasbaL ya está trabajando en esto.

Desde el 9/10/2026.

  • #4061 de @CasbaL — cerrado sin fusionar
  • #5334 de @CasbaL — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend, performance

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
54.1k
Forks
4.9k
Merge medio
8 h 41 min
PR fusionados (30 d)
723

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de heygen-com/hyperframes

Todos los issues de heygen-com/hyperframes

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.