`OffthreadVideo` is pathologically slow / hangs on sources with sparse keyframes

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

Nadie ha tomado este issue todavía.

Evaluación

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

Línea de trabajo

Start from the OffthreadVideo component and the ffmpeg call that seeks and decodes each frame; the issue names no file paths, so locate them by searching for OffthreadVideo and the ffmpeg invocation. Reproduce with a sparse-keyframe source such as a 60-fps video encoded with a large GOP. The issue offers three options (probe and warn, re-mux, frame cache) with no decision, so confirm the maintainers' preferred approach before coding. Done means the chosen option either warns or renders the sparse-keyframe source without stalling.

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

Descripción

Summary

OffthreadVideo performs a per-frame ffmpeg seek+decode. When the source video has a large GOP (sparse keyframes — common in screen recordings, OBS captures, and re-encodes that didn't override default x264 settings), each seek has to decode from the previous keyframe forward, which is slow and can hang the render entirely on some sources.

Reproduction

  1. Take any 60-fps screen recording (OBS, QuickTime, ffmpeg with defaults). These typically have keyframes every 250 frames (~4s).
  2. Wrap it in <OffthreadVideo src={...} /> and render a composition that plays it.
  3. Render hangs or crawls at ~1 frame/sec when the shot is on-screen. Sometimes hangs indefinitely.

In our project, an 1140-frame <OffthreadVideo> over ubatch_glm.mp4 (20s @ 60fps, ~7 keyframes total) stalled the MyVideo render at the exact frame where that video started playing. Re-encoding the source with -g 30 -keyint_min 30 (keyframe every 0.5s) — going from 7 → 41 keyframes — fully resolved it.

Repro one-liner for the fix

ffmpeg -i input.mp4 -c:v libx264 -crf 20 -preset medium -pix_fmt yuv420p \
       -g 30 -keyint_min 30 -movflags +faststart output.mp4

Expected / suggested behavior

Any one of the following would prevent users from hitting this:

  1. Probe + warn at first use. When OffthreadVideo loads a source, count keyframes vs total frames. If keyframes / total_frames < 1 / fps (i.e. less than 1 keyframe per second of content), log a warning:

    OffthreadVideo: \"video.mp4\" has only N keyframes in M frames (1 every X seconds). Per-frame seek cost will be high. Re-encode with -g <fps> -keyint_min <fps> for fast scrub.

  2. Internal re-mux on first use. Auto-generate a sidecar *.optimized.mp4 with -g 30 and use that for rendering. Cache it next to the source. (Remotion does effectively this by extracting frames to a temp directory.)

  3. Frame cache. Extract all source frames upfront to a temp directory on the first render, then read frames from the cache. Eliminates seek cost entirely after the first pass.

(3) is the cleanest but most invasive. (1) is a one-screen probe at media-load time and prevents the surprise.

Impact

This is the kind of bug where the framework looks broken but the source is at fault — and there's no diagnostic to point users at the source. The render just stalls.

Environment

  • `@rendiv/core`: ^0.1.0
  • `@rendiv/cli`: ^0.1.0
  • ffmpeg: 7.0.2-static
  • OS: Debian inside Docker container (headless)
Lenguaje dominante
TypeScript
Estrellas
159
Forks
32
Sin PR fusionados en 30 d

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 thecodacus/rendiv

Todos los issues de thecodacus/rendiv

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.