<p>I'd recommend considering these workarounds in this order, until it seeks fast enough:</p>
<ol>
<li>Make sure hardware video decoding is turned on</li>
<li>Switch to a faster video player</li>
<li>Decrease the GOP to one second</li>
<li>Encode the video with the &quot;fastdecode&quot; tuning</li>
<li>Use an intra-only format</li>
</ol>
<p>Ok here is the detailed answer explanation:</p>
<p><strong>Hardware decoding</strong></p>
<p>Most GPUs have hardware-accelerated video decoding for H.264. Make sure that's turned on in your video player. If it isn't then it will fall back to software decoding which is significantly slower.</p>
<p><strong>Faster video player</strong></p>
<p>Even for pretty slow computers, you should be able to seek anywhere within a low-resolution H.264 video in well under a second. But some video players are more efficient than others. When I use Totem (GNOME video player based on gstreamer) seeking is so much slower than when I use MPV (lightweight player based on ffmpeg).</p>
<p><strong>Shorter GOP</strong></p>
<p>A smaller, closed GOP will improve seek times. H.264 is often encoded with x264 which has a default GOP length of 250 frames (and it is closed by default, which means inter-frames cannot pick reference frames outside of the GOP they reside in). At 25fps this means that skipping to a random frame may require up to 10 seconds worth of video being decoded if you happen to hit a frame at the very end of a GOP. Try decreasing the GOP to only one second. Compression ratio will be worse but average case and worst case seek latency will go down.</p>
<p><strong>Tune for fast decoding</strong></p>
<p>Encode the video while tuning for fast decoding (<code>-tune fastdecode</code>). This turns off features that can be a bottleneck on decoders, specifically the in-loop deblocker (a feature which reduces blocking artifacts), weighted P and B frames (a frame type that improves efficiency a lot when brightness changes), and the CABAC entropy coder (a slower but more efficient entropy coder than constrained baseline's CAVLC).</p>
<p><strong>Intra-only format</strong></p>
<p>The fastest seeking would be in an intra-only codec, either a mezzanine like FFV1 or ProRes, or a popular codec like H.264 in an intra-only mode. Most people only do this during the editing process for ultra-high resolution and bitrate videos where seeking would be too slow otherwise.</p>

CC BY-SA 4.0
2024-05-06T02:46:43.110Z
2024-05-14T07:55:50.637Z
2024-05-14T07:55:50.637Z
veppy
<p>I've got a low-resolution 4 hour clip, and need to do a lot of seeking in the video to write down when stuff happens.</p>
<p>Do you have any suggestions for what format/settings would be the most &quot;seek-friendly?&quot;  Right now it is a H264 mp4, ~200mb on disk, and every time I move the playback bar to a new part, it stops and thinks for a few seconds - especially if I have to back up 20 seconds.  I'm looking to be able to move backwards and forwards as fast as possible.  Maybe throwing in more keyframes?  A different video format that is less compressed, but more skip-around optimized?</p>

<ffmpeg><codec>
Best ffmpeg compression settings for fast seeking of long 4 hour clip
Benjamin H
# Best ffmpeg compression settings for fast seeking of long 4 hour clip

(Asked by: username_0 on 2023-10-26)

I've got a low-resolution 4 hour clip, and need to do a lot of seeking in the video to write down when stuff happens.

Do you have any suggestions for what format/settings would be the most "seek-friendly?" Right now it is a H264 mp4, ~200mb on disk, and every time I move the playback bar to a new part, it stops and thinks for a few seconds - especially if I have to back up 20 seconds. I'm looking to be able to move backwards and forwards as fast as possible. Maybe throwing in more keyframes? A different video format that is less compressed, but more skip-around optimized?

**Tags:** ffmpeg, codec


---

## 1 answers

### Answer by username_1 on 2024-05-06. Score: 1

I'd recommend considering these workarounds in this order, until it seeks fast enough:

1. Make sure hardware video decoding is turned on
2. Switch to a faster video player
3. Decrease the GOP to one second
4. Encode the video with the "fastdecode" tuning
5. Use an intra-only format

Ok here is the detailed answer explanation:

**Hardware decoding**

Most GPUs have hardware-accelerated video decoding for H.264. Make sure that's turned on in your video player. If it isn't then it will fall back to software decoding which is significantly slower.

**Faster video player**

Even for pretty slow computers, you should be able to seek anywhere within a low-resolution H.264 video in well under a second. But some video players are more efficient than others. When I use Totem (GNOME video player based on gstreamer) seeking is so much slower than when I use MPV (lightweight player based on ffmpeg).

**Shorter GOP**

A smaller, closed GOP will improve seek times. H.264 is often encoded with x264 which has a default GOP length of 250 frames (and it is closed by default, which means inter-frames cannot pick reference frames outside of the GOP they reside in). At 25fps this means that skipping to a random frame may require up to 10 seconds worth of video being decoded if you happen to hit a frame at the very end of a GOP. Try decreasing the GOP to only one second. Compression ratio will be worse but average case and worst case seek latency will go down.

**Tune for fast decoding**

Encode the video while tuning for fast decoding (`-tune fastdecode`). This turns off features that can be a bottleneck on decoders, specifically the in-loop deblocker (a feature which reduces blocking artifacts), weighted P and B frames (a frame type that improves efficiency a lot when brightness changes), and the CABAC entropy coder (a slower but more efficient entropy coder than constrained baseline's CAVLC).

**Intra-only format**

The fastest seeking would be in an intra-only codec, either a mezzanine like FFV1 or ProRes, or a popular codec like H.264 in an intra-only mode. Most people only do this during the editing process for ultra-high resolution and bitrate videos where seeking would be too slow otherwise.


---

