Google VP9 "Next Generation Open Video" information posted

[mandarinka]

I recall there being an actual limitation in the bitstream. The AQ has to be done via segmentation maps where you pick quants you can use and then you can assign one of those to blocks through assigning them to one or another segment. Roughly speaking. I recall that it was believed to be a hinder to AQ being useful.

[benwaggoner]

I recall there being an actual limitation in the bitstream. The AQ has to be done via segmentation maps where you pick quants you can use and then you can assign one of those to blocks through assigning them to one or another segment. Roughly speaking. I recall that it was believed to be a hinder to AQ being useful.
Oh, yeah. That would require weird loops where you'd encode the frame once, figure out the segments, and then reencode again. MPEG-4 part 2 had a similar issue in its adaptive quant which also was a huge hassle to tune.

[IgorC]

Is there a way to get libvpx not to "crush" flat or dark parts of the image so much? It is one of the major weak points it still has that can ruin certain parts of a stream and that x264 solved ages ago.
Both tune-content=film and aq-mode=1/2 do not seem to suffice to control this behaviour.
Is there another method like limited the quantizer range or such?
Thank you
If 10 bits is an option that would fix a major part of described issue.

[Beelzebubu]

Oh, yeah. That would require weird loops where you'd encode the frame once, figure out the segments, and then reencode again.

Why? For example, x264 heuristically assigns quant deltas before the frame encode. To fit this in a segment-ID design, all you need is a clustering algorithm (see e.g. webp).

[Blue_MiSfit]

Super interesting stuff. I totally agree that these types of issues are what disqualify VP9 for my use cases. It's better than AVC at low bitrates for sure, but when we go for high quality / transparency as required for premium OTT delivery of Hollywood content it's a bit lacking in exactly this way.

It's useful for UHD, but there we usually can use HEVC which just ends up looking better.

If we had good AQ I could totally see VP9 being incredibly useful, especially in cases where HEVC is off the table!

[benwaggoner]

Why? For example, x264 heuristically assigns quant deltas before the frame encode. To fit this in a segment-ID design, all you need is a clustering algorithm (see e.g. webp).
Oh, it would be possible, just a lot more finicky to do so optimally. x264 devs figured out how to do adaptive quant in xvid eventually, although it was slower and less optimal than in x264.

[Spyros]

Phoronix - Intel's Open-Source VP9 Video Encoder Just Scored A Massive ~3x Performance Boost (https://www.phoronix.com/scan.php?page=news_item&px=Intel-SVT-VP9-3x-AVX2-Boost)

SVT-VP9 is now a lot faster on AVX2 CPUs from both Intel and AMD.

[...]

The i7-7740X went from 30 FPS to 120 FPS, the E5-1680 v3 from 38 to 113 FPS, and the E5-2687W v3 from 46 to 150 FPS. Damn!

[benwaggoner]

Phoronix - Intel's Open-Source VP9 Video Encoder Just Scored A Massive ~3x Performance Boost (https://www.phoronix.com/scan.php?page=news_item&px=Intel-SVT-VP9-3x-AVX2-Boost)
Impressive, but not fundamentally surprising. Libvpx never received the sort of sustained high-touch optimization or tuning that the x24? series of encoders got. A really good encoder matters more than a bitstream with really good potential without encoders well tuned to use that potential.

[dapperdan]

That particular speed up isn't impressive, nor does it say much about libvpx.

Effectively they forgot to flick a switch to send the fast code to all platforms that could use it. Then they noticed and fixed it. The headline could just as easily been "vp9-svt pointlessly 3x slower on some platforms until now".

That all said, I'm intrigued to see how the SVT family of encoders turns out. They seem to be throwing a fair bit of engineering at it, though initially it seemed the VP9 team were redirected to work on the AV1 encoder, so good to see some work on it again, even if it's just basic stuff like that. Part of the SVT idea is that optimisations can be shared between codec families I believe, so VP9 should be benefitting even when not the focus.

Their effective use of all a available cores seems like their secret weapon. In many real world situations that might give them an edge that other encoders would have to work hard to match if coming from the libvpx codebase.

[Adonisds]

Has anyone done a comparison of the quality of youtube VP9 vs Stadia VP9?

[LigH]

YouTube will use ffmpeg with a streaming focused bitrate control. Easy to beat with constant quality focus. What is the main target of Stadia?

[soresu]

YouTube will use ffmpeg with a streaming focused bitrate control. Easy to beat with constant quality focus. What is the main target of Stadia?

FFMPEG is still using libvpx though isn't it?

It's a good sign that we are seeing so much competition so soon with AV1 encoders - the dearth of VP9 encoder competition until very recently stifled its chances of market penetration somewhat.

[osgZach]

FFMPEG is still using libvpx though isn't it?

It's a good sign that we are seeing so much competition so soon with AV1 encoders - the dearth of VP9 encoder competition until very recently stifled its chances of market penetration somewhat.

Just sucks because we're always playing leapfrog with CPU power. I got a ryzen 7 3800x with a nice upgrade path to a Ryzen 9 3950X in the future, but how fast is AV1 going to realistically get within that time before something -else- comes along, etc.

H.264 had a great run for sure, HEVC was hampered with all the political/patent BS and we've been stuck with marginally slow encoding VP9. H.265 browser support would have been nice.


it all gets so tiring :cool: I actually wish consumers had affordable FPGA options for encoders. There has to be a market somewhere out there worth tapping.

[Blue_MiSfit]

HEVC works perfectly in the primary browsers of macOS (Safari) and Windows (Edge).

Google chose not to implement HEVC decoding in Chrome, unfortunately. I'm not aware of exactly why (since hardware decoders exist for all modern systems that they could just hook into), but it may be theological reasons. Maybe it was the unknown liability for licensing a software fallback decoder.

They DID do this in Android.

[benwaggoner]

HEVC works perfectly in the primary browsers of macOS (Safari) and Windows (Edge).

Google chose not to implement HEVC decoding in Chrome, unfortunately. I'm not aware of exactly why (since hardware decoders exist for all modern systems that they could just hook into), but it may be theological reasons. Maybe it was the unknown liability for licensing a software fallback decoder.

They DID do this in Android.Actually HEVC did work in Firefox and Chrome initially, using the same passthrough-to-OS logic that enabled H.264. They later specifically blocked HEVC playback, even if an OS decoder was available.

It'd be a trival patch to remove the block. The net effect of the block is that there isn't any premium content HDR in browsers, since there is no broadly available HW with DRM 10-bit decoder in modern browsers.

Sent from my SM-T837V using Tapatalk

[benwaggoner]

Just sucks because we're always playing leapfrog with CPU power. I got a ryzen 7 3800x with a nice upgrade path to a Ryzen 9 3950X in the future, but how fast is AV1 going to realistically get within that time before something -else- comes along, etc.



H.264 had a great run for sure, HEVC was hampered with all the political/patent BS and we've been stuck with marginally slow encoding VP9. H.265 browser support would have been nice.





it all gets so tiring :cool: I actually wish consumers had affordable FPGA options for encoders. There has to be a market somewhere out there worth tapping.Using F1 instances is a lot cheaper than buying a FPGA for experimentation.

https://aws.amazon.com/ec2/instance-types/f1/

Sent from my SM-T837V using Tapatalk

[Blue_MiSfit]

Indeed ^^

I've been looking forward to trying out Socionext's FPGA AV1 encoder :)

[osgZach]

Using F1 instances is a lot cheaper than buying a FPGA for experimentation.

https://aws.amazon.com/ec2/instance-types/f1/

Sent from my SM-T837V using Tapatalk

It's neat to know something like this exist, however it's not really feasible for my usage case due to a processing time / bandwidth required point of view. I need local hardware, ahh... beggars can't be choosers and all that :cool:

[osgZach]

And a bit of a rando question, not sure whether this is ffmpeg specific or VPX/VP9 specific.

2-pass CRF is nice, I like it, and it actually seems to run a tad bit faster than a traditional 2pass, which bringing potentially better compression. However I'm also interesting in vbv/constained buffer values. I have found examples of how to do such in a regular 2-pass encode, but I cannot find anything that says whether it will/won't work if you try it with a 2pass CRF encode.

Can anyone elaborate on whether this would work, or how I could at least verify it with some test cases ? I'm worried if I specify anything other than b:v 0 it will fall back to some other mode, or not generally drop the bitrate below b:v X even if it can go lower than X

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.1.0):

VPx v1.8.2-184-gf80e88872 (https://www.mediafire.com/file/hqrzja1kltm2yjs/vpx_v1.8.2-184-gf80e88872.7z/file)

[Sagittaire]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.1.0):

VPx v1.8.2-184-gf80e88872 (https://www.mediafire.com/file/hqrzja1kltm2yjs/vpx_v1.8.2-184-gf80e88872.7z/file)

thx ... ;-)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.1.0):

VPx v1.8.2-219-g8c7142d77 (https://www.mediafire.com/file/ze44955w1p2l6i9/vpx_v1.8.2-219-g8c7142d77.7z/file)

[kerry7]

It's neat to know something like this exist, however it's not really feasible for my usage case due to a processing time / bandwidth required point of view. I need local hardware, ahh... beggars can't be choosers and all that :cool:

Also you can considere to use GCP Cloud computing. It is an alternative to EC2, but with the huge advantage that most likely google offers a better integration with VP9

[Blue_MiSfit]

Also you can considere to use GCP Cloud computing. It is an alternative to EC2, but with the huge advantage that most likely google offers a better integration with VP9


Nope. EC2 is just renting VM time. Google Cloud's Compute Engine is the same thing. You get an instance, typically with some Linux distro on it. The rest is up to you.

If you want video transcoding as a service you have a lot of options, but that's separate from any conversation about EC2 vs the equivalent on GCP.

[dapperdan]

Apple appear to be rolling out VP9 suppprt across iOS, tvOS and MacOS/Safari.

Most of the news stories just say "4K Youtube support" but it appears to be via VP9.2 and hardware accelerated where the hardware supports it.

https://webkit.org/blog/11183/release-notes-for-safari-technology-preview-112/

[Blue_MiSfit]

Very exciting. I've had my Apple TV on the beta for awhile, but YouTube is still HD-only there. I wonder what Apple devices actually offer hardware VP9 decoding under the hood that's just been disabled all this time?

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.2.0):

VPx v1.9.0-61-gc413c8f18 (http://www.mediafire.com/file/65po2ws983ucna9/vpx_v1.9.0-61-gc413c8f18.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.2.0):

VPx v1.9.0-103-g3f7fee29e (https://www.mediafire.com/file/u4xi09wcxbtz17h/vpx_v1.9.0-103-g3f7fee29e.7z/file)

[utack]

Is Google now actively killing 8k VP9?
A lot of videos only have AV1 as 8k option available, and I found reference to one a year back in a forum that clearly showed VP9 was still available at the time.

[Blue_MiSfit]

Good luck "forcing" Apple to do anything :D

[benwaggoner]

Is Google now actively killing 8k VP9?
A lot of videos only have AV1 as 8k option available, and I found reference to one a year back in a forum that clearly showed VP9 was still available at the time.
The bigger challenge is that reality is killing 8K video because of the limits of human perception. I challenge you to find video content that looks better encoded at native 8K than downscaled to 4K at the same bitrate when viewed at enough distances that the edges of the screen are at a minimally acceptable viewing angle. No one in Hollywood is doing any post production in 8K. Heck, most visual effects are still being done in 2K for cost/speed reasons, and because 2K looks just fine if there's some motion blur and/or grain.

And with everyone working from home, even experimenting in 8K is nigh impossible. There literally aren't any monitors that are 8K, HDR, and have DisplayPort. Monitoring 8K HDR means using a (WAY too big for a desk) TV and a $3K AJA Kona 5 with experimental and finicky HDMI 2.1 firmware.

[takla]

With libvpx-vp9 v1.9.0 auto-alt-ref only works in 2pass. was this changed or was this always the case?

[Beelzebubu]

With libvpx-vp9 v1.9.0 auto-alt-ref only works in 2pass. was this changed or was this always the case?

Yes (sadly).

[edit]
At --cpu-used=4 using VBR, it works also in one-pass mode in some cases. But at other speeds or in CRF, it works in 2-pass only.

See this (https://chromium.googlesource.com/webm/libvpx/+/refs/heads/master/vp9/encoder/vp9_encoder.c#7707) code.

[takla]

Yes (sadly).

[edit]
At --cpu-used=4 using VBR, it works also in one-pass mode in some cases. But at other speeds or in CRF, it works in 2-pass only.

See this (https://chromium.googlesource.com/webm/libvpx/+/refs/heads/master/vp9/encoder/vp9_encoder.c#7707) code.

Thanks for clarifying. But I'm confused. Why was it changed? Was it not working correctly before?

[Beelzebubu]

Thanks for clarifying. But I'm confused. Why was it changed? Was it not working correctly before?

I meant: yes, it was always the case. Sorry for the confusing answer.

[takla]

I meant: yes, it was always the case. Sorry for the confusing answer.

Ah alright then. Thanks.

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.2.0):

VPx v1.9.0-156-g24bd0733e (http://www.mediafire.com/file/3gkr2zeiyqgub7g/vpx_v1.9.0-156-g24bd0733e.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.3.0):

VPx v1.10.0-61-g4808d831d (https://www.mediafire.com/file/jab9n85wxbkoljl/vpx_v1.10.0-61-g4808d831d.7z/file)

[takla]

2021-09-27
v1.11.0 "Smew Duck"

This maintenance release adds support for VBR mode in VP9 rate control
interface, new codec controls to get quantization parameters and loop filter
levels, and includes several improvements to NEON and numerous bug fixes.

- Upgrading:
New codec control is added to get quantization parameters and loop filter
levels.

VBR mode is supported in VP9 rate control library.

- Enhancement:
Numerous improvements for Neon optimizations.
Code clean-up and refactoring.
Calculation of rd multiplier is changed with BDRATE gains.

- Bug fixes:
Fix to overflow on duration.
Fix to several instances of -Wunused-but-set-variable.
Fix to avoid chroma resampling for 420mpeg2 input.
Fix to overflow in calc_iframe_target_size.
Fix to disallow skipping transform and quantization.
Fix some -Wsign-compare warnings in simple_encode.
Fix input file path in simple_encode_test.
Fix valid range for under/over_shoot pct.


Source (https://github.com/webmproject/libvpx/blob/16837ae1680bbc73381570cc783439b0ea121ba6/CHANGELOG)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 12.1.0):

VPx v1.11.0-218-g9f1329f8a (https://www.mediafire.com/file/o441fgsk2acws5e/vpx_v1.11.0-218-g9f1329f8a.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 12.1.0):

VPx v1.12.0-72-g59acf6739 (https://www.mediafire.com/file/o52kl32cr9xm1k6/vpx_v1.12.0-72-g59acf6739.7z/file)

SVT-VP9 0.3.0-d9ef3cc (https://www.mediafire.com/file/mkpxvw2qzkd7g0w/SVT-VP9_0.3.0-d9ef3cc.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 12.2.0):

VPx v1.12.0-153-ga46ca4b6b (https://www.mediafire.com/file/rc9hzzp8kbmvjmf/vpx_v1.12.0-153-ga46ca4b6b.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 12.2.0):

VPx v1.12.0-214-gddca3dec3 (https://www.mediafire.com/file/idslbndhyldqyt5/vpx_v1.12.0-214-gddca3dec3.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 12.2.0):

VPx v1.12.0-228-gd998bd823 (https://www.mediafire.com/file/ph7xc2hmzku0vip/vpx_v1.12.0-228-gd998bd823.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 13.1.0):

VPx v1.13.0-398-g9ad950a9c (https://www.mediafire.com/file/vdyafg7ftotfir1/vpx_v1.13.0-398-g9ad950a9c.7z/file)

[oibaf]

Some (not so) recent news:


2023-09-29 v1.13.1 "Ugly Duckling"
This release contains two security related fixes. One each for VP8 and VP9.
- Upgrading:
This release is ABI compatible with the previous release.
- Bug fixes:
https://crbug.com/1486441 (CVE-2023-5217)
Fix to a crash related to VP9 encoding (#1642)

2023-01-31 v1.13.0 "Ugly Duckling"
This release includes more Neon and AVX2 optimizations, adds a new codec
control to set per frame QP, upgrades GoogleTest to v1.12.1, and includes
numerous bug fixes.
- Upgrading:
This release is ABI incompatible with the previous release.
New codec control VP9E_SET_QUANTIZER_ONE_PASS to set per frame QP.
GoogleTest is upgraded to v1.12.1.
.clang-format is upgraded to clang-format-11.
VPX_EXT_RATECTRL_ABI_VERSION was bumped due to incompatible changes to the
feature of using external rate control models for vp9.
- Enhancement:
Numerous improvements on Neon optimizations.
Numerous improvements on AVX2 optimizations.
Additional ARM targets added for Visual Studio.
- Bug fixes:
Fix to calculating internal stats when frame dropped.
Fix to segfault for external resize test in vp9.
Fix to build system with replacing egrep with grep -E.
Fix to a few bugs with external RTC rate control library.
Fix to make SVC work with VBR.
Fix to key frame setting in VP9 external RC.
Fix to -Wimplicit-int (Clang 16).
Fix to VP8 external RC for buffer levels.
Fix to VP8 external RC for dynamic update of layers.
Fix to VP9 auto level.
Fix to off-by-one error of max w/h in validate_config.
Fix to make SVC work for Profile 1.

2022-06-17 v1.12.0 "Torrent Duck"
This release adds optimizations for Loongarch, adds support for vp8 in the
real-time rate control library, upgrades GoogleTest to v1.11.0, updates
libwebm to libwebm-1.0.0.28-20-g206d268, and includes numerous bug fixes.
- Upgrading:
This release is ABI compatible with the previous release.
vp8 support in the real-time rate control library.
New codec control VP8E_SET_RTC_EXTERNAL_RATECTRL is added.
Configure support for darwin21 is added.
GoogleTest is upgraded to v1.11.0.
libwebm is updated to libwebm-1.0.0.28-20-g206d268.
Allow SimpleEncode environment to take target level as input to match
the level conformance in vp9.
- Enhancement:
Numerous improvements on checking memory allocations.
Optimizations for Loongarch.
Code clean-up.
- Bug fixes:
Fix to a crash related to {vp8/vp9}_set_roi_map.
Fix to compiling failure with -Wformat-nonliteral.
Fix to integer overflow with vp9 with high resolution content.
Fix to AddNoiseTest failure with ARMv7.
Fix to libvpx Null-dereference READ in vp8.

[benwaggoner]

Sounds like meaningful development wrapped up around January? I wonder if many of the contributors moved on to SVT-AV1.

Kind of funny that per-frame QP control took that long to implement.

[oibaf]

Sounds like meaningful development wrapped up around January? I wonder if many of the contributors moved on to SVT-AV1.

Kind of funny that per-frame QP control took that long to implement.

There are still lot of commits in libvpx after 1.13: https://chromium.googlesource.com/webm/libvpx/+log

Also for classic AV1 libaom: https://aomedia.googlesource.com/aom/+log

Much more than on SVT-AV1 https://gitlab.com/AOMediaCodec/SVT-AV1/-/commits/master/?ref_type=HEADS

[benwaggoner]

There are still lot of commits in libvpx after 1.13: https://chromium.googlesource.com/webm/libvpx/+log

Also for classic AV1 libaom: https://aomedia.googlesource.com/aom/+log

Much more than on SVT-AV1 https://gitlab.com/AOMediaCodec/SVT-AV1/-/commits/master/?ref_type=HEADS
Yeah, no doubt that work continues apace on AV1 encoders, open source and proprietary.

[takla]

https://chromium.googlesource.com/webm/libvpx/+/refs/tags/v1.14.0

Release v1.14.0 Venetian Duck

2024-01-18 v1.14.0 "Venetian Duck"

This release drops support for old C compilers, such as Visual Studio 2012
and older, that disallow mixing variable declarations and statements (a C99
feature). It adds support for run-time CPU feature detection for Arm
platforms, as well as support for darwin23 (macOS 14).

- Upgrading:
This release is ABI incompatible with the previous release.

Various new features for rate control library for real-time: SVC parallel
encoding, loopfilter level, support for frame dropping, and screen content.

New callback function send_tpl_gop_stats for vp9 external rate control
library, which can be used to transmit TPL stats for a group of pictures. A
public header vpx_tpl.h is added for the definition of TPL stats used in
this callback.

libwebm is upgraded to libwebm-1.0.0.29-9-g1930e3c.

- Enhancement:
Improvements on Neon optimizations: VoD: 12-35% speed up for bitdepth 8,
68%-151% speed up for high bitdepth.
Improvements on AVX2 and SSE optimizations.
Improvements on LSX optimizations for LoongArch.
42-49% speedup on speed 0 VoD encoding.
Android API level predicates.

- Bug fixes:
Fix to missing prototypes from the rtcd header.
Fix to segfault when total size is enlarged but width is smaller.
Fix to the build for arm64ec using MSVC.
Fix to copy BLOCK_8X8's mi to PICK_MODE_CONTEXT::mic.
Fix to -Wshadow warnings.
Fix to heap overflow in vpx_get4x4sse_cs_neon.
Fix to buffer overrun in highbd Neon subpel variance filters.
Added bitexact encode test script.
Fix to -Wl,-z,defs with Clang's sanitizers.
Fix to decoder stability after error & continued decoding.
Fix to mismatch of VP9 encode with NEON intrinsics with C only version.
Fix to Arm64 MSVC compile vpx_highbd_fdct4x4_neon.
Fix to fragments count before use.
Fix to a case where target bandwidth is 0 for SVC.
Fix mask in vp9_quantize_avx2,highbd_get_max_lane_eob.
Fix to int overflow in vp9_calc_pframe_target_size_one_pass_cbr.
Fix to integer overflow in vp8,ratectrl.c.
Fix to interger overflow in vp9 svc.
Fix to avg_frame_bandwidth overflow.
Fix to per frame qp for temporal layers.
Fix to unsigned integer overflow in sse computation.
Fix to uninitialized mesh feature for BEST mode.
Fix to overflow in highbd temporal_filter.
Fix to unaligned loads w/w==4 in vpx_convolve_copy_neon.
Skip arm64_neon.h workaround w/VS >= 2019.
Fix to c vs avx mismatch of diamond_search_sad().
Fix to c vs intrinsic mismatch of vpx_hadamard_32x32() function.
Fix to a bug in vpx_hadamard_32x32_neon().
Fix to Clang -Wunreachable-code-aggressive warnings.
Fix to a bug in vpx_highbd_hadamard_32x32_neon().
Fix to -Wunreachable-code in mfqe_partition.
Force mode search on 64x64 if no mode is selected.
Fix to ubsan failure caused by left shift of negative.
Fix to integer overflow in calc_pframe_target_size.
Fix to float-cast-overflow in vp8_change_config().
Fix to a null ptr before use.
Conditionally skip using inter frames in speed features.
Remove invalid reference frames.
Disable intra mode search speed features conditionally.
Set nonrd keyframe under dynamic change of deadline for rtc.
Fix to scaled reference offsets.
Set skip_recode=0 in nonrd_pick_sb_modes.
Fix to an edge case when downsizing to one.
Fix to a bug in frame scaling.
Fix to pred buffer stride.
Fix to a bug in simple motion search.
Update frame size in actual encoding.