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.