Skip to content

trimEnd fallback of 999999 seconds causes FFmpeg to scan entire file for trim end point - severe slowdown on long videos #1706

Description

@anshul23102

Problem

In src/lib/ffmpeg.ts, the buildVideoFilter function uses a fallback of
999999 when trimEnd is null:

const end = recipe.trimEnd !== null ? recipe.trimEnd : 999999;
filters.push(`trim=start=${recipe.trimStart}:end=${end}`);

The FFmpeg trim filter with an explicit end timestamp must decode the video
up to that timestamp to find the end point. When trimEnd is null (meaning
no trim is needed), the filter is still applied with end=999999, forcing
FFmpeg to decode and scan through the entire video duration rather than
treating it as pass-through.

For a 2-hour video (7,200 seconds), this is harmless for the content but
wastes processing time. For unusual container formats that require full seek
to determine duration, this can add significant overhead.

Additionally, if a user sets trimEnd to a value beyond the actual video
duration, FFmpeg silently outputs a shorter video with no warning to the user.

Suggested Fix

  1. Only add the trim filter when trimStart > 0 or trimEnd !== null:
    if (recipe.trimStart > 0 || recipe.trimEnd !== null) {
      const endVal = recipe.trimEnd ?? Number.MAX_SAFE_INTEGER;
      filters.push(`trim=start=${recipe.trimStart}:end=${endVal}`);
      filters.push("setpts=PTS-STARTPTS");
    }
    Or better, use FFmpeg's -ss and -to input/output flags for faster
    seeking instead of the trim video filter.
  2. When trimEnd exceeds the video duration, clamp it to the actual duration
    and show a warning in the UI.

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions