VP9 seek problem

[Kagami]

Hi. I have problem with default (non exact) seek in this VP9 video: http://a.pomf.se/ychsdg.webm (mirror: http://dump.bitcheese.net/files/evenaja/neko.webm)

When I press LEFT or RIGHT keys only audio position changes, video freezes till the end. Probably because there are too few keyframes in this video, but is that intended behavior? Exact seek with Shift+LEFT/Shift+RIGHT works as expected.

Video was encoded with:

ffmpeg -i neko_source.mp4 -an \
  -c:v libvpx-vp9 -pass 1 -b:v 1432k -threads 8 -speed 4 \
  -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 \
  -f webm -y /dev/null

ffmpeg -i neko_source.mp4 -i neko_source.m4a -map 0:0 -map 1:0 \
  -c:v libvpx-vp9 -pass 2 -b:v 1432k -threads 8 -speed 1 \
  -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 \
  -c:a libopus -b:a 128k \
  -y neko.webm

I also have problems with similar short VP9 videos.

Software versions:

mpv git-2896afa (C) 2000-2015 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
ffmpeg library versions:
   libavutil       54.22.101
   libavcodec      56.34.100
   libavformat     56.30.100
   libswscale      3.1.101
   libavfilter     5.14.100
   libswresample   1.1.100

ffmpeg version N-71459-g0842df2 

    vp8    - WebM Project VP8 Encoder v1.4.0-145-g004b9d8
    vp9    - WebM Project VP9 Encoder v1.4.0-145-g004b9d8

(latest git commits)

[ghost]

The file you linked has only 1 video key frame (for 42 seconds of video...). The seek index contains only 1 entry pointing to the start of the file. Each audio frame is marked as key frame, though (like it should be).

So what the demuxer does is this:

• it gets a seek request that goes past the index entry
• it discards the video frame, because it's past the seek target
• it discards audio frames before the seek target too
• but because audio frames are marked as key frames, it successfully seeks to the right audio position
• the seek succeeds, but no new video can be decoded, so it just keeps showing the frame that was there before the seek

Seeking forward within a file always causes EOF, because it's a forward seek, and a forward seek won't use the same index entry as the previous seek, basically. (This is so that when doing a forward seek close to the end of a file, it will actually end playback, instead of jumping backwards.) This is probably strange, but I'm not sure if this can be avoided without breaking this and other things.

All of this can be avoided by doing a precise seek. For example, you can do a single click on the OSC seek bar, or use --hr-seek=always. This will be slower, because it has to decode all video and audio from the start.

[Kagami]

Thanks for the explanation.

From the user point of view: what if mpv will detect such cases (there are no other key frames but video hasn't reached the end yet) and fall back to precise seek? I don't know how hard it would be to implement though.

Also, little documentation nit: always value is not listed at man page for this option:

       --hr-seek=<no|absolute|yes>
              Select when to use precise seeks that are not limited to keyframes. Such seeks
              require decoding video from the previous keyframe up to  the  target  position
              and  so  can  take some time depending on decoding performance. For some video
              formats, precise seeks are disabled. This option selects the default choice to
              use for seeks; it is possible to explicitly override that default in the defi‐
              nition of key bindings and in slave mode commands.

              no     Never use precise seeks.

              absolute
                     Use precise seeks if the seek is to an absolute position in  the  file,
                     such  as  a  chapter  seek, but not for relative seeks like the default
                     behavior of arrow keys (default).

              yes    Use precise seeks whenever possible.

[ghost]

I adjusted the manpage.