VP9 can't seek properly?

[xyzone]

Is there a way to get VP9 video to seek properly? I only have mpv to work with, and the version of VLC I'm using can't play VP9. But I also try playing on chrome and the same thing happens. On firefox, too, and there the colors in the video are all messed up, but that's another issue.

Here is a short sample that I encoded with ffmpeg (libvpx-vp9). When you try to seek forward, which is 10 seconds on mpv, it goes to 00:02:46. Is there supposed to be some encoding option to get around this issue?

[vivan]

That sample instacrashes mpc-hc o_O
(latest nightly too)

[vood007]

Huh? Works fine here with MPC-HC nightly, SW decode, EVRCP. Seeking is a bit slow(1-3 sec) but works fine. Same with MPC-BE.

[xyzone]

Originally Posted by vood007

Huh? Works fine here with MPC-HC nightly, SW decode, EVRCP. Seeking is a bit slow(1-3 sec) but works fine. Same with MPC-BE.

I didn't say it didn't work. I said not properly. I just tried mpc-hc nightly and the same thing happens there. It only seeks in increments of 2:46, not whatever your player is configured to. At least that's what happens when I tried with the progress widget or the keyboard arrows.

[vood007]

Its key-frame related. Try turning off "Fast-Seek" under "Tweaks" in MPC. For ffmpeg encoding you may read this : http://paulherron.com/blog/forcing_k...s_with_ffmpeg/

[Jamaika]

Originally Posted by xyzone

Is there a way to get VP9 video to seek properly? I only have mpv to work with, and the version of VLC I'm using can't play VP9. But I also try playing on chrome and the same thing happens.

Until I cann't believe? What was the original? What set the parameters?

[xyzone]

I tried encoding with those ffmpeg options and it's only half a solution. Now mpv is forced to seek to the keyframes I specified. But this only half-fixes my own files, not others. And messing around with keyframes at encoding time might even affect encoding efficiency, which will defeat the purpose of vp9.

I tested a file on chrome with more patience and it does seek, but it is delayed. Same as turning off 'quick seek' in mpc, I guess seeking of vp9 is just slow and there is no way around it, for the time being. 1-3 seconds is bad enough for my uses, but you need a fast machine for even that. It took much longer to seek on a chromebook, for example. I guess I won't be using vp9 for this, and it takes forever to encode, anyway.

[xyzone]

Originally Posted by Jamaika

Until I cann't believe? What was the original? What set the parameters?

I'm not sure I understand the question. The ffmpeg parameters I used were:

ffmpeg -i output.avi -c:v libvpx-vp9 -crf 33 -b:v 0 -an -threads 4 output.webm

[Jamaika]

OK. Add "output.avi".

ffmpeg.exe -loglevel warning -y -i "output.avi" -s 544x144 -r 60.000 -an -sn -f rawvideo -pix_fmt yuv420p - | 
vpxenc.exe -v --bit-depth=8 --input-bit-depth=8 --i420 -w 544 -h 144 --profile=0 --threads=4 --codec=vp9 --fps=60000/1000 --good --cpu-used=3 --target-bitrate=320 --kf-min-dist=0 --kf-max-dist=30 --drop-frame=0 --aq-mode=1 
--color-space=bt709 --passes=1 --pass=1 - -o "output.webm"

[xyzone]

That doesn't look like it produces constant quality encodes, which is what I am after in vp9. I don't want a bitrate of 320, and I don't want constrained quality, either.

I tried

--cq-level=33 --target-bitrate=0

with pretty horrible results.

Then I tried with

--cq-level=33 --target-bitrate=0 --end-usage=3

and the encoder crashed.

[BadFrame]

Originally Posted by xyzone

That doesn't look like it produces constant quality encodes, which is what I am after in vp9.

If I am understanding you correctly you want the same functionality as '--crf' on x264/x265 ?

To get that for vp9 (or vp8/vp10) you use '--end-usage=q' together with '--cq-level=X' where X is the quality you want across the encode, like with crf, 0 is best higher values decrease quality.

In this mode '--target-bitrate' works as a upper bitrate limit (IIRC), so you should certainly not set it to zero, in fact I don't set it at all and only use the two aforementioned parameters.

example:

vpxenc --codec=vp9 --good --cpu-used=1 --end-usage=q --cq-level=20 --aq-mode=1 -o out.webm source.y4m

[xyzone]

Originally Posted by BadFrame

If I am understanding you correctly you want the same functionality as '--crf' on x264/x265 ?

I guess it's roughly equivalent, but vp9 has it's own scheme.

The parameters you mention are the same ones I already used, as mentioned above. --end-usage=3 is the same as --end-usage=q, and that seems like constrained quality when bitrate is not specified as 0, according to this page. https://trac.ffmpeg.org/wiki/Encode/VP9 It also mentions how to achieve constant quality.

Here is a small comparison between the two encodings. Both from the same input file, and all else is the same. The only difference is the video track.

vpxenc file encoding settings:

ffmpeg -loglevel warning -y -i "output.avi" -sws_flags bitexact -s 512x112 -r 60.000 -an -sn -f rawvideo -pix_fmt yuv420p - | vpxenc -v --i420 -w 512 -h 112 --profile=0 --threads=4 --codec=vp9 --fps=60000/1000 --kf-min-dist=0 --kf-max-dist=30 --drop-frame=0 --aq-mode=1 --color-space=bt709 --end-usage=q --cq-level=33 --passes=1 --pass=1 - -o "output.webm"

ffmpeg file encoding settings:

ffmpeg -i input.avi -c:v libvpx-vp9 -crf 33 -b:v 0 -an -threads 4 -pix_fmt yuv420p -profile:v 0 output.webm

The former file does easily seek, but the thing to notice is the file size. Also, I would think the same result as the vpxenc file could be achieve on ffmpeg by omitting the bitrate of 0, or setting it to the vpxenc default of 256. And lastly, it could be my imagination, and I'd have to benchmark, but ffmpeg seems to encode a little faster.

To answer Jamaika's question, I'm using vp9 v1.4.0. This is on a Debian Linux, so both ffmpeg and vpxenc use the same library.

[BadFrame]

Originally Posted by xyzone

I guess it's roughly equivalent, but vp9 has it's own scheme.

Can you elaborate ?

Originally Posted by xyzone

The former file does easily seek, but the thing to notice is the file size.

No mystery here, it's obvious that the ffmpeg parameters does not map equally to the vpxenc parameters so you have two encodes with different parameters, personally I've always avoided using ffmpeg's ad-hoc translation of parameters and instead use ffmpeg to pipe video to the 'real' encoders, same goes for x264/x265.

[Jamaika]

You are using versions VP9?

[Jamaika]

Do you know, but every day there are some path to libvpx. I don't know how old codec uses ffmpeg. I use v1.4.0-1351.
I see some inconsistencies.

Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv), 512x112, SAR 1:2 DAR 16:7, 60 fps, 60 tbr, 1k tbn, 1k tbc (default) <-- ffmpeg

Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709/unknown/unknown), 512x112, SAR 28:57 DAR 128:57, 60 fps, 60 tbr, 1k tbn, 1k tbc (default) <-- vpxenc

Stream #0:0: Video: vp9 (Profile 1), yuv444p(tv), 544x144, SAR 1:2 DAR 17:9, 60 fps, 60 tbr, 1k tbn, 1k tbc (default) <-- vp9_opus.webm

What is the input file parameters output.avi? YUV or RGBA
Can codec VP9 seek properly now?

For vpxenc I don't need to set bitrate zero.

[xyzone]

The aspect ratio was a little off in the muxing, here it is, corrected, but it does nothing towards changing the video track size.

Originally Posted by Jamaika

What is the input file parameters output.avi? YUV or RGBA

It's bgr0, ffv1. This is what I use to work with video. The first encode I linked was 444. The other two are 420, both from same source video.

But all this is unrelated to the issue at hand.

[foxyshadis]

vp9, on the other hand, is a haphazard little project that seems more poorly managed than a lot of community projects. Google only seems to care about it as far as it can be used to reduce Youtube's bandwidth bills, and any attempt to mimic x264's and x265's excellent command line, multicore use, rate control, and exhaustive documentation are basically ignored.

I gave the new release a shot, but I didn't bother with a full test suite, it wasn't noticeably faster than 1.4 nor any better quality in the first (although some artifacts changed). They haven't updated the rate control, so what's the point in testing two-pass, it'll still be just as wildly off. Maybe it's just ARM optimizations.

Edit: Missed that this was a splinter thread, not the main VP9 thread.

[xyzone]

I found a compromise to get some kind of quick seeking (in most cases). 2-pass with '-auto-alt-ref 1' on pass 2. Overall, this is how I'm getting better results on low resolution content, especially flat pixels video:

ffmpeg -i [input] -c:v libvpx-vp9 -b:v 0 -crf 28 -threads 4 -speed 1 -f webm -pix_fmt yuv420p -profile:v 0 -an -sn -pass 1 /dev/null
ffmpeg -i [input] -c:v libvpx-vp9 -b:v 0 -crf 28 -threads 4 -speed 1 -f webm -pix_fmt yuv420p -profile:v 0 -an -sn -pass 2 -auto-alt-ref 1 -lag-in-frames 25 [output].webm

In a way, that's even more desirable, because it tends to seek where the scene changes. But if the pixels on screen never completely swap out, still no fast seek with ffmpeg vp9 constant quality.

[MoSal]

Originally Posted by xyzone

I found a compromise to get some kind of quick seeking (in most cases). 2-pass with '-auto-alt-ref 1' on pass 2. Overall, this is how I'm getting better results on low resolution content, especially flat pixels video:

ffmpeg -i [input] -c:v libvpx-vp9 -b:v 0 -crf 28 -threads 4 -speed 1 -f webm -pix_fmt yuv420p -profile:v 0 -an -sn -pass 1 /dev/null
ffmpeg -i [input] -c:v libvpx-vp9 -b:v 0 -crf 28 -threads 4 -speed 1 -f webm -pix_fmt yuv420p -profile:v 0 -an -sn -pass 2 -auto-alt-ref 1 -lag-in-frames 25 [output].webm

In a way, that's even more desirable, because it tends to seek where the scene changes. But if the pixels on screen never completely swap out, still no fast seek with ffmpeg vp9 constant quality.

You need to explicitly set the GOP. Try passing '-g 250'.

[xyzone]

Originally Posted by MoSal

You need to explicitly set the GOP. Try passing '-g 250'.

The problem with that is that it tends to add size to some encodes.

I encoded a 3 minute sample of content I knew would produce the seeking issue, despite auto-alt-ref. First with -g 250, then without. All else the same.

The gop set file is 30,979,544 bytes.
The file without gop set is 28,246,134 bytes.

Not much, but there's still a difference. So I guess bigger file size is the price for guaranteeing some kind of quick seek.

Be that as it may, with or without gop, auto-alt-ref still helps a lot in most videos, and this makes vp9 more usable for my purposes.