remotion-dev/remotion · error · std::io::Error

Frame evicted from cache

Error message

Frame evicted from cache

What it means

Returned by the frame-fetch path in packages/compositor/rust/ffmpeg.rs when frame_cache_manager.get_item_from_id() returns Ok(None) - the frame's id was known (computed via get_frame_id) but the cached bytes have since been evicted under the configured max_cache_size. This is an internal LRU-eviction condition inside the native binary, surfaced as an io::Error of kind Other; the compositor normally retries by re-decoding the frame.

Source

Thrown at packages/compositor/rust/ffmpeg.rs:102

        one_frame_in_time_base,
        threshold,
        tone_mapped,
        frame_cache_manager,
        thread_index,
        max_cache_size,
    )?;

    let from_cache = frame_cache_manager.get_item_from_id(
        &src,
        &original_src,
        transparent,
        tone_mapped,
        frame_id,
    );

    match from_cache {
        Ok(Some(data)) => Ok(data),
        Ok(None) => Err(std::io::Error::new(
            ErrorKind::Other,
            "Frame evicted from cache",
        ))?,
        Err(err) => Err(err),
    }
}

View on GitHub (pinned to 78fe4bb3fd)

Solutions

  1. Raise the frame cache size / available memory so the working set fits and eviction stops.
  2. Reduce render concurrency so fewer frames compete for the cache.
  3. Retry the render - transient eviction-driven failures are normally recovered by the compositor's internal retry, so a persistent failure points to sustained memory pressure.
Defensive patterns

Strategy: retry

Try / catch

async function renderWithRetry(opts, attempts = 3) {
  for (let i = 0; i < attempts; i++) {
    try {
      return await renderMedia(opts);
    } catch (err) {
      if (i === attempts - 1 || !/Frame evicted from cache/.test(String(err))) throw err;
    }
  }
}

Prevention

When it happens

Trigger: A cache sized too small for the working set (max_cache_size smaller than the number of distinct frames in flight), high concurrency causing churn, or heavy memory pressure forcing aggressive eviction between the id lookup and the data retrieval.

Common situations: Rendering many videos concurrently on a machine with limited RAM; a long video whose random-access pattern exceeds the frame cache; a configured cache size that is too low for the resolution/length of the composition.

Related errors


AI-assisted analysis of remotion-dev/remotion@78fe4bb3fd (2026-08-12). Data as JSON: /api/errors/ce94567ff13acc8a. Report an issue: GitHub.