VP9 Progress Update (11/20)

[Paul Wilkins]

VP9 Progress Update.

Encoder

As well as some further general encoder speed improvements we have made some changes to make future comparisons easier. To do this we have rebalance the speed settings so that each represents approximately a 5% quality step relative to good quality speed 0. This varies somewhat from clip to clip but for each of our test sets the quality differentials relative to speed 0 for speeds 1,2 and 3 are now ~ -5%, -10% and -15%. Higher speed settings are still experimental.

We have also reset the baseline against which comparisons are made to a build from June 17th (after the bitstream was frozen), and extended the set of clips used for encode speed testing (now run as a nightly build on a stand alone machine). This means that the encode speed results going forward are not directly comparable with previously numbers. However, the new speed 2 is similar in quality to the previous speed 1 (as measured on the 9th of October) and ~40% faster.

Encode speed ratio 11/20 vs 6/17 baseline, speed 0

Speed 1 - 20:1 (360p), 33:1 (HD)

Speed 2 - 40:1 (360p), 53:1 (HD)

Work has started to implement a 1 pass encoder and this does now produce valid output. However, it is still in the very early stages and broken from a quality / rate trade off perspective with many bitstream features not yet supported.

Decoder

There have been some further across-the-board performance improvements and an initial release of VP9 has shipped with KitKat.

For Chrome the improvements in decode speed mentioned in the previous update are shipping in M31. This also includes some multi thread support in regard to the loop filtering phase of decode.

For M32 we are targeting support for tile based multi-threading of HD content, which in tests on Nexus 4 and Nexus 7 devices currently improves decode frame rate by ~60% on average. A lot of testing has also been carried out to assess the visual quality impact of using tiles and so far the results seem promising.

General.

Code clean-up patches and work to fix security issues and crashes relating to decode of non conforming streams.

HW progress

VP9 hardware decoder RTL is in final optimization phase and will soon be launched in the WebM project.

Bug fixes

I draw your attention to the following patches since the last update that were flagged for special attention.

Change-Id: I10feb6ad2fcb1c2e14e51f550d1a8869aeaf6488

BITSTREAM - RESTORING BILINEAR INTERPOLATION FILTER SUPPORT

Change-Id: Ia0cac28249f587d8f8882205228fa480263ab313

BITSTREAM - CLARIFICATION OF MV SIZE RANGE

Change-Id: Iba730f433c30ed7f5e5449d6768049cbf9a2b2c5

BITSTREAM - "update_map" SEMANTICS BROKEN IN 398ddafb629b7f49cf255bf09d3e38b4abd0bb95

Our attention was also drawn to a residual dependency that impacts decode efficiency of motion vectors in hardware. If this had been noticed earlier I think we would have made the changes necessary to eliminate this dependency. Unfortunately, at this stage, with code already having shipped for KitKat and many hardware designs already in an advanced state, it was felt on balance that the negative impact of making the change outweighed the benefit.

Paul Wilkins

[Brendan Bolles]

Thanks for the update, Paul.

Any word on support for lossless compression and alpha channels, which I believe are features of VP9? As part of that I suppose you'll need to let us create and hand off images in VPX_IMG_FMT_I444 and VPX_IMG_FMT_444A formats.

Brendan

[Yu Liu]

Any update about VP9 specification document?

Yu

[impr...@gmail.com]

Hi Paul,

Thanks for the update, I have been playing with the VP9 software encoder libvpx for quite a long time, just wanted to check if there is any plan to release an RTL for the VP9 encoder just like the G2 Decoder ?

Thanks,
Pragnesh