ffmpeg encoded video - seeking is "quantised" in VLC

Question

I'm running the following command to convert an mp4 video into the VP8/Webm format:

ffmpeg -y -i lists.mp4 -f webm -vcodec libvpx -vb 600k -r 20 -acodec libvorbis -ab 64k -ac 1 lists.webm

When I open it in VLC and try to seek to different points in the video, the seeking is "quantised". By that I mean there are 3 or 4 points in the video that the seeker "snaps to", e.g. if I click anything from 06:30 to 10:30 it will seek to 06:30

I'm sure the problem is something related to the way ffmpeg is compiled. Miro Video Converter under Windows, which comes with ffmpeg, uses the command:

ffmpeg -y -i lists.mp4 -f webm -vcodec libvpx -acodec libvorbis -crf lists.webm

The output of Miro doesn't quantise in VLC, but the same command on my linux installation does. Therefore it must be something to with ffmpeg versions or the way it was compiled.

Anyone know anything about this? Debug output follows

---

Debug info for linux ffmpeg:

ffmpeg version N-35110-g0b9a69f, Copyright (c) 2000-2011 the FFmpeg developers
  built on Nov 23 2011 12:51:56 with gcc 4.6.2


configuration: --prefix=/usr --enable-libmp3lame --enable-libvorbis --enable-libxvid --enable-libx264 --enable-libvpx
--enable-libtheora --enable-libgsm --enable-libspeex --enable-postproc --enable-shared --enable-x11grab
--enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libschroedinger --enable-libopenjpeg --enable-librtmp
--enable-gpl --enable-version3 --enable-runtime-cpudetect --disable-debug --disable-static

  libavutil    51. 26. 0 / 51. 26. 0
  libavcodec   53. 37. 0 / 53. 37. 0
  libavformat  53. 21. 0 / 53. 21. 0
  libavdevice  53.  4. 0 / 53.  4. 0
  libavfilter   2. 49. 0 /  2. 49. 0
  libswscale    2.  1. 0 /  2.  1. 0    
  libpostproc  51.  2. 0 / 51.  2. 0

For Windows (Miro video converter):

    FFmpeg version SVN-r25762, Copyright (c) 2000-2010 the FFmpeg developers
      built on Nov 18 2010 04:07:17 with gcc 4.4.2
      configuration: --enable-gpl --enable-version3 --enable-libgsm
--enable-pthreads --enable-libvorbis --enable-libtheora --enable-libspeex 
--enable-libmp3lame --enable-libopenjpeg --enable-libschroedinger
--enable-libopencore_amrwb --enable-libopencore_amrnb --enable-libvpx
--disable-decoder=libvpx --arch=x86 --enable-runtime-cpudetect --enable-libxvid
--enable-libx264 --extra-libs='-lx264 -lpthread' --enable-librtmp
--extra-libs='-lrtmp -lpolarssl -lws2_32 -lwinmm' --target-os=mingw32
--enable-avisynth --cross-prefix=i686-mingw32- --cc='ccache i686-mingw32-gcc'
--enable-memalign-hack
      libavutil     50.33. 0 / 50.33. 0
      libavcore      0.13. 0 /  0.13. 0
      libavcodec    52.96. 0 / 52.96. 0
      libavformat   52.84. 0 / 52.84. 0
      libavdevice   52. 2. 2 / 52. 2. 2
      libavfilter    1.62. 0 /  1.62. 0
      libswscale     0.12. 0 /  0.12. 0

Answer 1

I don't know anything about the VP8 encoding in particular, but in general ffmpeg refers to key frames in terms of the "group of pictures" size.

Pass the -g option with a number to use as the maximum size of the group of pictures in frames; this will be the maximum number of frames between key frames (including the key frame).

It's possible that different ffmpeg / codec versions have different defaults for it; nevertheless you can probably override it to be whatever you want.

Background:

Compressed video formats often don't store the full data for every frame of video, instead storing most frames as a description of how to build the frame from pieces of past frames (and in more modern systems, pieces of near-future frames). In order to be able to quickly seek and start playing, video player software often only lets you jump to frames that do have the full data stored, which are called "key frames" or I-frames.

You can generally tell the encoder how often you want it to put in key frame. More key frames allow more flexibility for seeking and editing, but make the video compression less efficient.