Use VP9 in place of VP8 for WebM videos

[kelson42]

It offers a better compression

[rgaudin]

What are the drawbacks? Can you please share documents/comparison on this?
I'd be happy if we could increase quality with the same target bitrate.

[kelson42]

I'm not aware about any big drawback (maybe a missing native support in older browsers/library). See https://bloggeek.me/vp8-vs-vp9-quality-or-bitrate/

[rgaudin]

https://caniuse.com/?search=vp9 is not clear about VP9 support in browsers. Something we should definitely know before hand.

If you thought VP8 is a resource hog, then expect VP9 to be a lot more voracious with its CPU requirements

Seems to refer to encoding though. Rest of drawbacks mentioned are probably obsolete.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

[danielzgtg]

VP9 could still be sent to browsers without VP9 support. We would just need a polyfill. However people using those browsers are unlikely to have the CPU speed to decode VP9 smoothly, and it's even slower in a polyfill. Zoom uses a WASM polyfill for either video and/or audio. H264 isn't good for open source because it's patented.

It's 2023. I used to transcode my videos to VP9, but I transcode them to AV1 now. The compression quality compared to H264 is insane, as AV1 is 10x smaller with my settings even at 1080p. The videos I upload to GitHub these days are all AV1 in mp4 container. Again, the CPU speed of your target audience is in question. My laptop without AV1 hardware decode can decode the 8-bit AV1 natively in the browser smoothly, but not 10-bit. My current desktop has AV1 hardware decode, but my previous desktop can't keep up with its slow CPU.

[rgaudin]

@danielzgtg that's very interesting.

We already uses ogv.js and encode in VP9. From what I've read following your comment, AV1 hardware support is till fairly recent and would probably be difficult on most of our user's HW (although we have no numbers on our user's environment).

The AV1 bitrate quality is WOW and I'd love for us to switch. If you get a chance, I'd love an AV1 equivalent FFMPEG params list of our WebMLow preset so we could run some actual tests.

python-scraperlib/src/zimscraperlib/video/presets.py

Lines 30 to 55 in 6f93bcc

	class VideoWebmLow(Config):
	"""Low Quality webm video
	480:h format with height adjusted to keep aspect ratio
	300k video bitrate
	48k audio bitrate
	highly degraded quality (30, 42)"""
	VERSION = 1
	ext = "webm"
	mimetype = f"{preset_type}/webm"
	options = {
	"-codec:v": "libvpx", # video codec
	"-quality": "best", # codec preset
	"-b:v": "300k", # target video bitrate
	"-maxrate": "300k", # max video bitrate
	"-minrate": "300k", # min video bitrate
	"-qmin": "30", # min quantizer scale
	"-qmax": "42", # max quantizer scale
	"-vf": "scale='480:trunc(ow/a/2)*2'", # frame size
	"-codec:a": "libvorbis", # audio codec
	"-ar": "44100", # audio sampling rate
	"-b:a": "48k", # target audio bitrate
	}

[danielzgtg]

I reconstructed your ffmpeg command to be ffmpeg -hide_banner -i in.mp4 -vf "scale='480:trunc(ow/a/2)*2'" -c:v libvpx -quality best -b:v 300k -maxrate 300k -minrate 300k -qmin 30 -qmax 42 -r 24 -g 240 -codec:a libvorbis -ar 44100 -b:a 48k out.webm. That gives frame=18296 fps=104 q=33.0 Lsize= 57615kB time=00:12:42.29 bitrate= 619.2kbits/s dup=0 drop=4549 speed=4.31x video:29417kB audio:27908kB subtitle:0kB other streams:0kB global headers:3kB muxing overhead: 0.505121%. I'm testing on a video mixing live action and animated with lots of special effects.

hardware support
"-vf": "scale='480:trunc(ow/a/2)*2'", # frame size

480p? Should be able to decode that on CPU, especially at low bitrates. Some browsers don't even use hardware decoding for low-resolution videos.

Also thank you for that trunc part. I had to do the same thing for my scripts, and not knowing that command I complicated things with a Python wrapper.

"-codec:a": "libvorbis", # audio codec

Have you tried upgrading to libopus? The resulting audio sounds better. The Safari support for both Opus and Vorbis have the same warnings on caniuse.com.

"-maxrate": "300k", # max video bitrate

This doesn't look right. The webm command gave me 619.2kbits/s, way over 300k. I doubt that's all because of audio. Wow, copying using -c:v copy and -an gives 317.5kbits/s. The minrate cap also seems to be wasting space. That together with qmin and qmax seem to be imposing contradictory or unsatisfied constraints.

I'd love an AV1 equivalent FFMPEG params list

I matched the quality and speed to ffmpeg -hide_banner -i in.mp4 -vf "scale='480:trunc(ow/a/2)*2',format=yuv420p10le" -c:v libsvtav1 -preset 7 -crf 35 -r 24 -g 240 -c:a libopus -b:a 48k out.mp4. It resulted in frame=18296 fps=123 q=35.0 Lsize= 29291kB time=00:12:42.29 bitrate= 314.8kbits/s dup=0 drop=4549 speed=5.11x video:24698kB audio:4211kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.324344%. Of that, 265.8kbits/s was video.

A lot of the artifacts I saw in the webm are gone. This alone shouldn't be used to measure AV1 because AV1 encoders like to smooth things out. The colors are sharper, but that might just be from the 10-bit. The definitive evidence for AV1 is that I can see faces clearly when I couldn't see some before.

Flag	Effect
scale=	AV1 is better than other codecs at compressing high resolutions. This reduces file size and users' screen sizes should be considered if it's desired to increase this.
format=yuv420p10le	Improves compression and color quality. Remove to speed up encode and decode on some computers at the risk of introducing artifacts and increasing file size.
-preset 6	Matched to webm encoding speed. It's still faster and higher quality. Without it, I got 30.5 MiB instead of 28.6MiB but speed=24.5x instead of speed=5.11x. I use -preset 4 which is the limit for multithreading, but that is very slow.
-crf 35	Sets compression quality. libsvtav1 hasn't implemented bitrate properly yet, so I had to match the crf. 35 is actually the default setting. I use 60 for PowerPoints, and you could try 40 to see if that's acceptable. With 40, it still looked better than webm and I got 237.5kbits/s and 21.6 MiB.
-r 24	Reduces framerate to movies' 24FPS. Assuming your input is 24+ FPS, else add a check to reduce this further.
-g 240	Keyframe every 10s. libsvtav1 doesn't have scene change detection. This is specified to have the keyframe interval consistent for now. Keyframes affect video seek times.
-b:a 48k	A common value for audio quality, and I can't hear a difference. With the upgrade to Opus, try lowering this.

Encode times may be a concern without a fast CPU with 16+ cores. Removing the -preset 6 makes the encode both faster and still look better than webm. I think that decode performance is tied to bitrate, so improving compression may make it easier to decode. The encoded webm, with vaapi disabled so an AVX2 CPU only, was at 5.6%. The 21.6MiB AV1 was at 6.5% CPU, and the 28.6 MiB one was at 7.2% CPU. So we achieved the goal of improving compression. If users' computers heat up more, we can tell them that it's because we improved the video quality.

[kevinmcmurtrie]

The commands should only set narrow min/max limits on the quantizer quality or bitrate, but not both. I'm seeing high failure rates in transcoding and I bet it's because it can't always match two constraints at once.

[rgaudin]

Have you tried upgrading to libopus? The resulting audio sounds better. The Safari support for both Opus and Vorbis have the same warnings on caniuse.com.

Didn't realize ogv.js supported Opus. We shall switch indeed.

Thanks for all the details ; it's a great time and quality gain for me. I will run a couple tests and try this on an actual recipe and if it turns out fine, we'll make it the default.

[danielzgtg]

min/max limits on the quantizer quality or bitrate, but not both
I'm seeing high failure rates in transcoding

I think the encoder will just ignore contradictory options if they are supplied. At least, this is what some encoders do. If the transcoding jobs fail, it must be because of disk/network failures or running out of RAM. You could also try to remux with '-c:v copy -c:a copy' before transcoding as that fixes some files for me. Further remux options are regenerating the timestamps, or extracting into separate files then recombining the tracks.

ogv.js supported Opus

Didn't realize ogv.js supported AV1 either. With the previous 480p 8-bit encoded video, it was 35% CPU on an AVX512 CPU and 60% CPU on AVX2-only CPU.

10-bit is not supported (bvibber/ogv.js#626). mp4 container is not supported, only webm (bvibber/ogv.js#443).

[rgaudin]

Indeed ffmpeg doesn't fail. I've manually tested numerous of the failing ffmpeg commands and they all succeeded so the failures are probably resources related.

That said, it's important to fix because as you indicated options are ignored and we are thus creating larger files than we expect to.

I subscribed to those two tickets. 10b seems like the most important for us. bvibber/ogv.js@eef47bf shows there is no support and the compilation support is not the root cause.