Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-06T02:46:43.110Z
Answers.LastActivityDate: 2024-05-14T07:55:50.637Z
Answers.LastEditDate: 2024-05-14T07:55:50.637Z
Answers.UserDisplayName: veppy
Body: <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>
  
Tags: <ffmpeg><codec>
Title: Best ffmpeg compression settings for fast seeking of long 4 hour clip
UserDisplayName: Benjamin H
ThreadText: # 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.
  
  
  ---
  
  