Set VP9 as default

[darkred3]

Since 4chan finally supports VP9, it should be set as the default. Additionally, the encoding settings should probably be optimized. When I tried to encode to VP9 it had a few problems. First couple of frames were corrupted/pixelated, size was larger than VP8 with same or worse quality, max-size setting was ignored, two-pass was (probably) ignored too, and encoding speed was extremely slow.

[OrangeChannel]

Afaik there's not much optimizing in the settings that can improve encoding speed. vp9 is significantly slower than vp8 at equivalent presets and is not worth it for I assume what most people are using this script for: take quick recordings of anime/TV/youtube vids to upload to streamable discord or 4chan.

[darkred3]

Maybe speed can't be improved much, but the other stuff is still kinda broken so making VP9 webm using this script is currently kinda useless. Also I don't agree that VP8 should remain the default just because it's faster. There's a good reason why people have been asking mods to allow VP9 for years. Well, you can still easily change the default back to VP8 by editing the lua script anyway.

[ghost]

You can set the default encoder to vp9 by simply changing the output-format value in webm.conf

[darkred3]

Well, if people really are against it I don't mind keeping VP8 as the default. @ekisu at least seemed interested in the codec but didn't do anything with it since it wasn't accepted on 4chan back then #3 Improving the VP9 encoding was the main reason why I opened this issue. In regards to the increased encoding time I did a little testing: VP8 encoding using mpv-webm, no two-pass, strict-filesize constraint 3000: Encode time 26sec Size 3.09 MiB VP9 encoding using ffmpeg, no two-pass, -fs 3000000: Encode time 42sec Size 3.09 MiB VP9 with additional settings -row-mt 1 -tile-columns 5 -threads 10 -speed 2: Encode time 19sec Size 3.16 MiB Here's the results: https://slow.pics/c/rDfmjpaJ

I dunno much about encoding settings so I just used what I found online, but the results are already pretty darn good.

[OrangeChannel]

If you can do some more tests and show that vp9 with those params is actually able to match vp8 speeds with what looks like better quality from your comparison I'd gladly change my mind 😁. Maybe the encoder ffmpeg uses (i assume its the reference spec) has gotten faster in the last few years or cpu's have gotten better.

Edit: last I recall, the vp9 grey frames at the start was an issue on mpv's side and I doubt it's been fixed. Does your test files still look like grey blobs in discord previews etc?

[DonKatsu]

Throwing in some issues with vp9 selected that I encountered: Mine's not using more than four threads even if I set libvpx_threads to anything higher. twopass isn't used when set to yes. The first 5 frames or so of the output is noticably low quality but quickly sharpens. (But I guess that's an mpv issue? vp8 is fine.) For me, vp9 tends to overshoot the target size much easier than with vp8.

[ghost]

But I guess that's an mpv issue? vp8 is fine.

The compression artifacts at the very beginning are noticeable when file is played in the browser as well (ex: uploaded somewhere and then played). This is not an mpv playback issue

[OrangeChannel]

This is not an mpv playback issue

It's an issue with mpv's vp9 encoder.

[darkred3]

Is mpv not using ffmpeg?

[OrangeChannel]

Kind of? It doesn't actually call ffmpeg directly to do the encoding but mpv's encoding mode uses ffmpeg/libavc encoders (libvpx in this case but last i checked the issue didn't happen when encoding a clip directly through ffmpeg with vp9). I can try to replicate the issue with just ffmpeg soon.

[noodles0999]

It's an issue with mpv's vp9 encoder.

does mpv have an open issue for this?

I can try to replicate the issue with just ffmpeg soon.

did you ever get around to this, and if so same question as above; does ffmpeg have an open issue for this? @OrangeChannel

[yutsuku]

Well, if people really are against it I don't mind keeping VP8 as the default. @ekisu at least seemed interested in the codec but didn't do anything with it since it wasn't accepted on 4chan back then #3 Improving the VP9 encoding was the main reason why I opened this issue. In regards to the increased encoding time I did a little testing: VP8 encoding using mpv-webm, no two-pass, strict-filesize constraint 3000: Encode time 26sec Size 3.09 MiB VP9 encoding using ffmpeg, no two-pass, -fs 3000000: Encode time 42sec Size 3.09 MiB VP9 with additional settings -row-mt 1 -tile-columns 5 -threads 10 -speed 2: Encode time 19sec Size 3.16 MiB Here's the results: https://slow.pics/c/rDfmjpaJ

I dunno much about encoding settings so I just used what I found online, but the results are already pretty darn good.

In case anyone wants to benefit from faster encoding speed without patching or compiling the script itself: add the following to your script-opts/webm.conf file:

output_format=webm-vp9
libvpx_threads=12
additional_flags=--ovcopts-add=row-mt=1 --ovcopts-add=tile-columns=5 --ovcopts-add=speed=2

play with values as needed

[DonKatsu]

Discovered this fork recently. Something they did lets it encode VP9 without the blocky initial frames. Two-pass works as well. Not sure how though.

[9Pierre]

Discovered this fork recently. Something they did lets it encode VP9 without the blocky initial frames. Two-pass works as well. Not sure how though.

Very interesting fork, the automatic multiple attempts with different CRF values to reach the target size was promising but it doesn't work with me no matter what I do.