FFmpeg Input vs Output Seeking Performance

When transcoding video with FFmpeg, the placement of the seek parameter (-ss) dramatically affects processing speed and resource consumption. Input seeking (placing -ss before -i) is exponentially faster because it jumps directly to the target timestamp at the container level without decoding preceding frames. In contrast, output seeking (placing -ss after -i) forces FFmpeg to fully decode every frame from the beginning of the file up to the specified timestamp before discarding them, resulting in high CPU usage and severe processing delays.

Input Seeking (-ss before -i)

Input seeking instructs the demuxer to seek through the file using keyframes (I-frames) before the decoding pipeline starts:

ffmpeg -ss 00:10:00 -i input.mp4 -c:v libx264 output.mp4
  • Mechanism: The demuxer reads file metadata and jumps directly to the nearest keyframe preceding the 10-minute mark. In modern FFmpeg releases, it decodes only the few frames between that keyframe and the target timestamp to maintain frame accuracy, completely bypassing the first ten minutes of media.
  • CPU and Memory Impact: Minimal. FFmpeg performs no decoding or filtering on the skipped segment.
  • Execution Time: Virtually instantaneous seeking. A transcode targeting the 1-hour mark begins encoding within fractions of a second.

Output Seeking (-ss after -i)

Output seeking processes the entire file from the start and applies the seek point after decoding:

ffmpeg -i input.mp4 -ss 00:10:00 -c:v libx264 output.mp4
  • Mechanism: FFmpeg reads, demuxes, and fully decodes every single audio and video frame from 00:00:00 to 00:10:00. Once decoded, these frames pass through any configured filters and are discarded immediately before the encoding stage.
  • CPU and Memory Impact: Extremely high. Your CPU or GPU runs at full capacity decoding media that will never be used in the output file.
  • Execution Time: Proportional to the seek duration. Seeking two hours into a 4K file using output seeking can take tens of minutes just to reach the first encoded frame.

Performance Breakdown

Metric Input Seeking (-ss before -i) Output Seeking (-ss after -i)
Decode Overhead Negligible (only frames from nearest keyframe) Massive (100% of skipped duration)
Time to First Output Frame Milliseconds Seconds to hours (depends on duration)
CPU/GPU Resource Utilization Low during seek 100% during seek
Scaling with Seek Offset Constant time, regardless of timestamp Linear degradation as timestamp increases

Best Practice

For maximum performance, always place -ss before -i. Modern versions of FFmpeg enable frame-accurate seeking by default with input seeking, rendering output seeking obsolete for standard transcoding workflows. If frame-accurate precision down to the exact presentation timestamp (PTS) is required on older builds, use combined seeking: place an input seek slightly before the target timestamp to skip the bulk of the file, followed by a short output seek to trim the exact frames.