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.

[Jamaika]

You are using versions VP9?

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

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

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

[xyzone]

Originally Posted by BadFrame

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? If not, why can't vpxenc do it?

[BadFrame]

Originally Posted by xyzone

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='

Originally Posted by xyzone

So 'constant quality' just something ffmpeg pulled out of the nether realms? If not, why can't vpxenc do it?

See above

[xyzone]

Originally Posted by BadFrame

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]

Originally Posted by xyzone

That's not what the page says.

What page ?

Originally Posted by xyzone

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).