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 (https://www.sendspace.com/file/nxnbmm) 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]

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_keyframes_with_ffmpeg/

[Jamaika]

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]

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.

[Jamaika]

You are using versions VP9?

[BadFrame]

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]

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 (https://www.sendspace.com/file/hqozhb) 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 (https://www.sendspace.com/file/21aph5) 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.

[Jamaika]

Do you know, but every day there are some path (https://github.com/webmproject/libvpx/commits/master) 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. (http://wiki.webmproject.org/vp9/vp9-tips)

[xyzone]

The aspect ratio was a little off in the muxing, here it is, corrected, (https://www.sendspace.com/file/hqozhb) but it does nothing towards changing the video track size.

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.

[BadFrame]

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

Can you elaborate ?

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.

[xyzone]

Can you elaborate ?

As I said. I want 'constant quality' (not constrained quality).

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.

So 'constant quality' just something ffmpeg pulled out of the nether realms? (https://trac.ffmpeg.org/wiki/Encode/VP9) If not, why can't vpxenc do it?

[BadFrame]

As I said. I want 'constant quality' (not constrained quality).

And that's what you have when you (as I've shown) use '--end-usage=q', 'constrained quality' which you are confusing it with is enabled by '--end-usage=cq'

'--end-usage' has four options: vbr, cbr, cq, q

When you enable '--end-usage=q', the '--cq-level=' parameter works just like '--crf='

So 'constant quality' just something ffmpeg pulled out of the nether realms? (https://trac.ffmpeg.org/wiki/Encode/VP9) If not, why can't vpxenc do it?

See above

[xyzone]

And that's what you have when you (as I've shown) use '--end-usage=q', 'constrained quality' which you are confusing it with is enabled by '--end-usage=cq'

'--end-usage' has four options: vbr, cbr, cq, q

When you enable '--end-usage=q', the '--cq-level=' parameter works just like '--crf='



See above

That's not what the page says. It's clear about setting bitrate to 0. And that file is smaller despite being perceptually the same. You say the parameters are different, and that's obvious, given the file size, but that's not the point. The point is the ffmpeg files are smaller, and perceptually the same. And they might even encode faster on ffmpeg.

[BadFrame]

That's not what the page says.

What page ?

The point is the ffmpeg files are smaller, and perceptually the same. And they might even encode faster on ffmpeg.

FFMpeg is using the same library that is used in vpxenc, there's no magic at play here.

Again the files are smaller because the parameters you feed to ffmpeg are not the same you feed to vpxenc, the file size clearly shows this, that there is no 'perceptual difference' in your eyes is not particularly surprising giving that the files you uploaded had extremely low detail/color, you could likely drop it a lot further in file size without any 'perceptual' difference whatsoever.

I don't know what you are trying to say here, do you think ffmpeg has some magic options which makes the files smaller at the same quality, despite using the exact same encoding library ? Seriously ?

The problem here is, as so often before, that ffmpeg's ad-hoc parameter mapping is not 1:1 with the parameters of the official encoders, often leading to confusion.

Now I've told you how '--end-usage=q' works in vpxenc to mimic '--crf' functionality, I have no interest in figuring out how it works in ffmpeg because I don't use ffmpeg directly for encoding, I prefer using the actual upstream encoders (x264, x265, vpxenc, etc).

[xyzone]

I think my question was pretty clear, and you are dismissing it. The link is the one I posted twice.

And I don't care about what's "official". I care about what's better.

[BadFrame]

And I don't care about what's "official". I care about what's better.

I don't know what you are babbling about anymore, if you are convinced ffmpeg is somehow better at encoding vp9 despite using the exact same library as the upstream encoder, then just use it.

[xyzone]

The thread and links posted are there for any idiot with two eyes to take a look at.

if you are convinced ffmpeg is somehow better at encoding vp9 despite using the exact same library as the upstream encoder, then just use it.

What I am convinced of is that ffmpeg is not a haphazard little project, and that its docs have more merit than some random person on a forum. Not 100% certain that it's better, but I certainly got no definitive answers, here.

[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]

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]

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.

[nevcairiel]

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

Of course. For proper seeking you need more I frames, and I frames take up space.

[mustafa]

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 (https://www.sendspace.com/file/nxnbmm) 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?

This is a strange default for ffmpeg with libvpx, the max distance between key-frames is 9999, you should pass something like '-g 150' when encoding to make it about 5 seconds.
http://ffmpeg.org/ffmpeg-all.html#libvpx
https://github.com/Kagami/webm.py/wiki/Notes-on-encoding-settings#defaults
https://chromium.googlesource.com/webm/libvpx/+/c77b1f5acd09852aff1ba09d7f371728a60634d7/vp9/vp9_cx_iface.c#1440

Regards