Google VP9 "Next Generation Open Video" information posted

[borring]

I heard/read that decoding performance for VP9 was to be similar to h.264...

Nevertheless, I just hope that a 2.5GHz Brisbane and/or a 2GHz Conroe will be able decode 720p VP9! Otherwise I'm SOL, especially since I was hoping for VP9 in order to actually stream YouTube 720p. (My connection is just a bit too slow for it, unless the video has very minimal movement)

I don't think you need to worry with that hardware. I was having just a little trouble decoding youtube vp9 videos at 480p with my 1.9Ghz apu in chrome. Fortunately, the libvpx in git is way faster than the one currently shipped with Chrome. After compiling Chromium using the latest libvpx code, I can play 1080p.

[Nintendo Maniac 64]

I don't think you need to worry with that hardware. I was having just a little trouble decoding youtube vp9 videos at 480p with my 1.9Ghz apu in chrome. Fortunately, the libvpx in git is way faster than the one currently shipped with Chrome. After compiling Chromium using the latest libvpx code, I can play 1080p.

But all of the APUs that run at 1.9GHz have a turbo up to at least 2.4GHz. My Brisbane completely predates the concept of Turbo.

Also if that's a Llano rather than a Trinity, then it'll be even faster at 1.9GHz. (Llano is slower per GHz than Trinity, but Trinity clocks considerably higher per watt)

[borring]

Just found out my turbo core was actually working (2.35 Ghz). Just requires special tools to report the right frequencies.

It still has a harder time decoding than my Core 2 Duo though. It's a shame though that my APU isn't new enough to have all the popular instruction sets.

[Nintendo Maniac 64]

Here's something interesting, apparently new uploads to YouTube have at least their 480p and 1080p resolutions have the video stream seperate from the audio stream. This is relevent because, AFAIK, Opus isn't (yet) compatible with MKV (which WebM is a subset of). This woud mean that using Opus audio in an OGG container (which is all .opus is) and using VP9 in a WebM like usual, you could essentually have VP9 + Opus.

Source: https://github.com/YePpHa/YouTubeCenter/issues/98#issuecomment-26488263

[sneaker_ger]

This is relevent because, AFAIK, Opus isn't (yet) compatible with MKV

Opus in mkv has been finalized and is supported by mkvtoolnix.

[Nintendo Maniac 64]

Opus in mkv has been finalized and is supported by mkvtoolnix.

Well shoot, I need to update my version of mkvtoolnix then! I've been waiting on that functionality.

And just to clarify, ffdshow doesn't decode vp9 yet, correct? I'm also waiting to update for that functionality.

[vivan]

And just to clarify, ffdshow doesn't decode vp9 yet, correct? I'm also waiting to update for that functionality.ffdshow is dead

[zerowalker]

fddshow tryout is pretty dead too, atleast it´s been 4 months.

Not sure who will add it, only thing i can think of is MPC, and i sadly don´t use that as a Player.

[Rumbah]

MPC doesn't use ffdshow anymore, either. It is distributed with LAV filters.

[Keiyakusha]

MPC doesn't use ffdshow anymore, either. It is distributed with LAV filters.

MPC never used ffdshow... unless you installed both and made ffdshow preferred decoder.
Also not every MPC out there uses LAV. There is the one that does, there is the one that doesn't. Both of them will have vp9 support. (Plus there were lite builds that don't use anything, but not sure if they are still supported)

----
Anyway. When people here say "ffdshow is dead" they mean tryouts one. Original ffdshow is dead for sooo long, hardly anyone remembers it existed. And its not 4 months, its more than a year. If there were some small maintenance commits, it doesn't counts.

[sneaker_ger]

(Plus there were lite builds that don't use anything, but not sure if they are still supported)

The current official builds are basically MPC-HC lite, i.e. the filters are not integrated in the executable. They just ship with an extra folder that includes the LAV Filters.

[Nintendo Maniac 64]

I meant tryouts.

But uh, ok, perhaps I should reword the question then; both ffdshow tryouts and LAV filters do not support VP9 decoding currently, correct?

[nevcairiel]

LAV Filters will support VP9 soon, but not right now, thats correct.

[the_weirdo]

No, they don't support VP9 decoding yet. However, I suppose nevcairiel will update his filters to support VP9 soon after he's back from his vacation. Not sure about ffdshow-tryouts though.

[mandarinka]

Well, VP9 isn't exactly a "yesterday was too late" feature, is it. Encoding into the format is alpha, there is no content, etc.

[dapperdan]

you could essentually have VP9 + Opus.


I was under the impression that this was going to be the default on Youtube and for VP9 in WebM generally.

Two minor things though.

1) The WebM team proposed allowing mix-n-match so you could have VP8 and Opus and VP9 and Vorbis in WebM. Some of the Xiph team suggested that WebM should stick to VP8+Vorbis and have WebM2 defined for anything else.

2) There was an obscure comment on one of Xiph's meeting logs for Daala that said "- jm: i keep getitng interrupted with issues like google dropping opus for complexity reasons." but I don't know the context of that.

[Beelzebubu]

I'd also guess that it is being primarily done by Ronald Bultje as I haven't seen any public commits from him in a long time and as far as I know he is one of the current lead developers of VP9.

Was, unfortunately. I no longer work at Google. I did write FFmpeg's native VP9 decoder (and am still working on optimizing it) together with Clement Boesch, though.

[BadFrame]

Was, unfortunately. I no longer work at Google. I did write FFmpeg's native VP9 decoder (and am still working on optimizing it) together with Clement Boesch, though.

Ah what a shame, you've certainly left a void with all the great commits you kept pumping out.

Good luck on whatever venture you are currently engaging!

[Kurtnoise]

The 1.3.0 release is under way...

2013-11-15 v1.3.0 "Forest"
This release introduces the VP9 codec in a backward-compatible way.
All existing users of VP8 can continue to use the library without
modification. However, some VP8 options do not map to VP9 in the same manner.

The VP9 encoder in this release is not feature complete. Users interested in
the encoder are advised to use the git master branch and discuss issues on
libvpx mailing lists.

- Upgrading:
This release is ABI and API compatible with Duclair (v1.0.0). Users
of older releases should refer to the Upgrading notes in this document
for that release.

- Enhancements:
Get rid of bashisms in the main build scripts
Added usage info on command line options
Add lossless compression mode
Dll build of libvpx
Add additional Mac OS X targets: 10.7, 10.8 and 10.9 (darwin11-13)
Add option to disable documentation
configure: add --enable-external-build support
make: support V=1 as short form of verbose=yes
configure: support mingw-w64
configure: support hardfloat armv7 CHOSTS
configure: add support for android x86
Add estimated completion time to vpxenc
Don't exit on decode errors in vpxenc
vpxenc: support scaling prior to encoding
vpxdec: support scaling output
vpxenc: improve progress indicators with --skip
msvs: Don't link to winmm.lib
Add a new script for producing vcxproj files
Produce Visual Studio 10 and 11 project files
Produce Windows Phone project files
msvs-build: use msbuild for vs >= 2005
configure: default configure log to config.log
Add encoding option --static-thresh

- Speed:
Miscellaneous speed optimizations for VP8 and VP9.

- Quality:
In general, quality is consistent with the Eider release.

- Bug Fixes:
This release represents approximately a year of engineering effort,
and contains multiple bug fixes. Please refer to git history for details.

[zerowalker]

Hope it will finally start to be used more, like in Youtube, as i don´t think it´s used there yet, except for some experiments.

[mzso]

Hope it will finally start to be used more, like in Youtube, as i don´t think it´s used there yet, except for some experiments.

Only chrome supports it so far. Converting all videos to VP9 feels premature to me.

[Nintendo Maniac 64]

VLC 2.1.1 now has experimental support for VP9 (and HEVC) decoding:
http://news.cnet.com/8301-11386_3-57612525-76/vlc-steps-into-next-gen-video-wars-with-vp9-hevc-support/

I tried it with the video on here, but it would only show a single frame before ending the video:
http://base-n.de/webm/VP9%20Sample.html

[BadFrame]

VLC 2.1.1 now has experimental support for VP9 (and HEVC) decoding:
http://news.cnet.com/8301-11386_3-57612525-76/vlc-steps-into-next-gen-video-wars-with-vp9-hevc-support/

I tried it with the video on here, but it would only show a single frame before ending the video:
http://base-n.de/webm/VP9%20Sample.html

Yes VLC 2.1.1 has been available on the Arch Linux repos for a couple of weeks, and while I haven't tried the sample you linked, it has played all the vp9 encodes I've made myself (using vpxenc built from git main branch).

Navigating (seeking) through the file during playback doesn't work for me though, it just keeps on playing from where it was.

Also I saw that they added a 'aq-mode' setting recently called 'variance', I should do some new tests to see what impact it has.

[nakTT]

Yes VLC 2.1.1 has been available on the Arch Linux repos for a couple of weeks, and while I haven't tried the sample you linked, it has played all the vp9 encodes I've made myself (using vpxenc built from git main branch).

Navigating (seeking) through the file during playback doesn't work for me though, it just keeps on playing from where it was.

Also I saw that they added a 'aq-mode' setting recently called 'variance', I should do some new tests to see what impact it has.
I have exactly the same issue as you, but that I encounter while using the latest MPC-HC. With the latest VLC Player, I can do the seeking but once I did, the video will turn ugly with broken video image.

[dapperdan]

Another update on VP9 progress from the mailing list:

https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/webm-discuss/alfjBJLIA3g

Notable stuff: faster en/decode, initial implementation of a 1-pass encoding mode that currently produces valid but not very nice to look at output, VP9 decode ships with Android KitKat, hardware decoder RTL (which I believe is like source-code for hardware manufacturers) about to be released.

[Selur]

Small question: How to use VP9s lossless mode?
I though using:
for decoding:
mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi"
and for encoding:
vpxenc --codec=vp9 --lossless=1 --good --threads=16 --width=640 --height=352 -o "H:\Output\test_07_56_58_0010_01.vp9" -
but that ended with:
Error: Tried to set control 27 = 1
Failed to control codec: Invalid parameter
rc_max_quantizer out of range [..0]
using:
mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi" | vpxenc --codec=vp9 --lossless=1 --min-q=0 --max-q=0 --threads=16 --width=640 --height=352 -o "H:\Output\test_07_56_58_0010_01.vp9" -
aborts with:
Warning: Bad quantizer values. Quantizer values should not be equal, and should
differ by at least 8.
1 encoder configuration warning(s). Continue? (y to continue) (it also only writes 'Continue? (y to continue)', but doesn't wait for an answer, it simply aborts)

-> Can someone post an vpxenc-example of a VP9 lossless encoding call?
(sadly the webm documentation is lacking in so many regards,..)

Cu Selur

[Kurtnoise]

You have to use a recent build (at least a build using the latest commits from the master branch).

Then,

--passes=1 --pass=1 --fpf=logfile.log --codec=vp9 --lossless=1 --min-q=0 --max-q=0 --end-usage=q --width=640 --height=352 -o output.webm -

[Selur]

vpxenc I used is: (build on 4th of december)
vp8 - WebM Project VP8 Encoder v1.2.0-5319-g584c729
vp9 - WebM Project VP9 Encoder v1.2.0-5319-g584c729

and calling:
mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi" | vpxenc --passes=1 --pass=1 --fpf=logfile.log --codec=vp9 --lossless=1 --min-q=0 --max-q=0 --end-usage=q --width=640 --height=352 -o output.wem -
still gives me:
Warning: Bad quantizer values. Quantizer values should not be equal, and should differ by at least 8.
1 encoder configuration warning(s). Continue? (y to continue)

Will make a clean rebuild a bit later and test again.

[Kurtnoise]

Like I told you, you have to use a more recent build (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=2341747805d1a829cb9140a4f391bdf2534cdf70)...

[Selur]

Ah, okay didn't know it had to be that recent. :)

[oibaf]

1.3.0 was tagged (http://git.chromium.org/gitweb/?p=webm/libvpx.git). :)

But is there an official announcement somewhere other than the git tag? Download section still only has 1.2.0 (http://code.google.com/p/webm/downloads/list). :confused:

[Kurtnoise]

From the changelog (http://forum.doom9.org/showthread.php?p=1653611#post1653611) file...

[Selur]

Compiled vpxenc&vpxdec using https://github.com/jb-alvarado/media-autobuild_suite
but either something is wrong with that build script or vpx is simply broken.

lossless creates a 1byte file
normal vp9 and vp9 encoding produces an output where it looks like that the color space got totally mixed up.

-> Can someone compile and upload current vpxenc so I can check with that and contact jb-alvarado or the vpxenc devs depending on where the problem is.

mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi" | vpxenc --codec=vp9 --passes=1 --pass=1 --target-bitrate=1500 --end-usage=vbr --profile=0 --good --cpu-used=3 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=640 --height=352 -o "H:\Temp\test_16_23_09_2810_01.vp9" -
works fine with the old 1.2 release, but produces 'broken' output with this release. :(

Cu Selur

[Nintendo Maniac 64]

Firefox apparently now supports VP9 playback in its development branches:
http://www.phoronix.com/scan.php?page=news_item&px=MTUzODA

[Selur]

attached my broken vpxenc versions I build with media-autobuild_suite to a post over at videohelp (http://forum.videohelp.com/threads/360831-Looking-for-up-to-date-working-and-static-vpxenc-version?p=2287227#post2287227)


Cu Selur

[Selur]

LoadCPlugin("G:\avsiynth\avisynthPlugins\ffms2.dll")
# loading source
FFVideoSource("H:\TESTCL~1\test.avi",cachefile="H:\Output\21437943319_16_52_0110.ffindex",fpsnum=25000,fpsden=1000)avs2yuv "H:\Output\encodingTempAvisynthSkript_19_16_52_0110.avs" - | vpxenc --codec=vp9 --passes=2 --pass=1 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Output\test_19_16_52_0110_03.stats" --profile=0 --good --cpu-used=3 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --min-q=0 --max-q=63 --lag-in-frames=25 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=640 --height=352 -o NUL -

avs2yuv "H:\Output\encodingTempAvisynthSkript_19_16_52_0110.avs" - | vpxenc --codec=vp9 --good --cpu-used=2 --psnr --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --cq-level=20 --end-usage=0 --auto-alt-ref=1 --passes=2 --pass=2 --fpf=file.fpf --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --aq-mode=2 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --psnr --target-bitrate=275 --width=640 --height=352 - -o "h:\Output\try1.webm"WORKS!!
avs2yuv -raw "H:\Output\encodingTempAvisynthSkript_19_16_52_0110.avs" - | vpxenc --codec=vp9 --passes=2 --pass=1 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Output\test_19_16_52_0110_03.stats" --profile=0 --good --cpu-used=3 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --min-q=0 --max-q=63 --lag-in-frames=25 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=640 --height=352 -o NUL -

avs2yuv -raw "H:\Output\encodingTempAvisynthSkript_19_16_52_0110.avs" - | vpxenc --codec=vp9 --good --cpu-used=2 --psnr --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --cq-level=20 --end-usage=0 --auto-alt-ref=1 --passes=2 --pass=2 --fpf=file.fpf --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --aq-mode=2 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --psnr --target-bitrate=275 --width=640 --height=352 - -o "h:\Output\try1.webm"doesn't.

-> seems like vpxenc now only supports y4m input, despite the fact that the help only states:

--yv12 Input file is YV12
--i420 Input file is I420 (default)-> WTF?!?
(didn't consider testing y4m since the help doesn't mention it)

btw. ffmpeg as decoder works fine too as long as yuv4mpegpipe is used. (using raw i420 or yv12 produces the above problems.)
-> filed a bug report: http://code.google.com/p/webm/issues/detail?id=678

[Selur]

using:
vp8 - WebM Project VP8 Encoder v1.3.0-290-ge18eb77
vp9 - WebM Project VP9 Encoder v1.3.0-290-ge18eb77
and
ffmpeg -v -10 -i "H:\TestClips&Co\test.avi" -an -sn -threads 8 -vsync 0 -r 25 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --lossless=1 --end-usage=q --min-q=0 --max-q=0 --width=640 --height=352 -o "H:\Output\test.webm" -
lossless encoding still doesn't work. :( (only creates a 1kByte file)

Cu Selur

[Leeloo Minaï]

I got valid 2-pass encoding but also lossless with this command line and your "broken" 32-bit vpxenc from your videohelp post :

ffmpeg -i input.avi -an -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=1 --pass=1 --fpf="test.stats" --lossless=1 --min-q=0 --max-q=0 --end-usage=q --width=224 --height=384 - -o test.webm


Note : your 64-bit "broken" build is really... broken, it does 1st pass but encounters an error at start of 2nd pass.

[Selur]

Compiled a new version (v1.3.0-290-ge18eb77) (https://drive.google.com/folderview?id=0B_WxUS1XGCPASUZibG5XZkRfeTg&usp=sharing) which works fine with 2pass here.
Seems like the missing '--passes=1 --pass=1' was the problem. :D
(I even got dvd->vpxenc working by doing a double-pipe: mencoder ... | ffmpeg ... | vpxenc ... )

[o-l-a-v]

When will they make WebP with VP9, does anyone know? So far I haven't found much on that topic

[Hyral]

Here's something interesting, apparently new uploads to YouTube have at least their 480p and 1080p resolutions have the video stream seperate from the audio stream.

This might be related to Youtube now using MPEG-DASH, which separates resources down to the streams.

[Nintendo Maniac 64]

This might be related to Youtube now using MPEG-DASH, which separates resources down to the streams.

It is. That post was made before I knew about DASH. :P

[xooyoozoo]

Two semi-recent papers on VP9 efficiency.

VP9 intra performance vs HM/JM/VP8 (http://m-hikari.com/ams/ams-2013/ams-137-140-2013/sharabaykoAMS137-140-2013.pdf). TLDR: VP9 needs 20% less bitrate than VP8. HEVC needs 30% less than JM, 15% less than VP9. Authors suggest 2/3 of HEVC's gains over VP9 due to having more prediction angles + SAO, the rest due to slightly better entropy coding.

VP9 vs HM vs x264 in playback/random-access config (http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf). TLDR: The paper found that VP9 needs 80% more bitrate than HEVC, 8% more than x264. Unfortunately, VP9 was ran with min-q=max-q=$QP. If that's what that sounds like, their results for VP9 are almost certainly invalid.

For both papers, I wouldn't expect VP9's results to change more than 1-2% with a recent build. I recall almost all quality commits being for the higher speed presets.

VP9 also now has adaptive quant. Aq-mode 1 seems to improve MS-SSIM bdrate by several percent on a couple 1080p clips I've tried. I'm not particularly sure what aq-mode 2 does, and on testing with crowdrun seq, both subjective viewing and MS-SSIM bdrate showed worse performance compared to aq1.

It'd be nice to do a subjective comparison against x265+AQ, but VP9's wildly off its 2pass target bitrates when AQ is on. That along with how encoding is single-threaded and how cpu-used=0 is roughly as fast as the HM mean I'm not too keen on trial-and-error encodes. ;)

[mzso]

Looks like now VP9 works in the main ffmpeg builds (except with x64 where it just crashes). Anyone knows a good guide for VP9 options?
Rather liked x264's profile preset features.

[dapperdan]

Quote from the mailing list (in the context of encoding):

"Right now VP9 is a lot slower than VP8. We are working hard to correct that. Watch for big speed increases in the couple of months."

Obviously easier said than done, but thought I'd note it anyway.

[Selur]

hopefully, after that they fix 2pass encoding in a way that it actually hits (near) a specified bitrate.

[BadFrame]

Anyone knows a good guide for VP9 options?
Rather liked x264's profile preset features.

I don't have a guide but the best settings (quality wise) I've gotten from my own tests are as follows:

VBR:

vpxenc --good --end-usage=vbr --target-bitrate=X --cq-level=0 --aq-mode=1 --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=15 --arnr-strength=6 --arnr-type=3 --sharpness=0 --codec=vp9

I noted in VBR that it's best to set the cq-level to 0, else the encoder will be eager to try to save a lot bits in flat areas leading to macro-blocks, of course you may want this and if so increase the cq-level value accordingly.

CQ:

vpxenc --good --end-usage=3 --cq-level=X --aq-mode=1 --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=15 --arnr-strength=6 --arnr-type=3 --sharpness=0 --codec=vp9

The only change in the CQ encode is the -end-usage parameter, you could also experiment with aq-mode=2 which I haven't yet examined. Also I'm using --good here, for the best quality you should use --best but it is REALLY slow so unless you have a lot of time or are doing a comparison between encoders I would use --good

It's been a bunch of weeks since I last did some tests so I hope these settings are still valid.

[xooyoozoo]

Some months ago, VP9 defaults in libvpx were changed to match the high-quality suggestions. In the same commit, the developers also recommended against using --best over --good.

IIRC, the only thing you'd need to worry about now is cpu-used, end-usage, aq-mode, kf-max-dist.

[x265_Project]

MulticoreWare, the company behind the x265 project, is working with Google and semiconductor companies to accelerate VP9.

http://www.prweb.com/releases/2014/02/prweb11612574.htm

[dapperdan]

There was also a similar project from ittiam for the ARM MALI GPU.

http://malideveloper.arm.com/demo-showroom/computer-vision/ittiam-vp9-decoder-using-opencl/

Both seem to have involved collaboration with Google and the use of OpenCL, but I don't know if that means we should expect other chips to have similar solutions.

Also, ffmpeg's VP9 decoder had a blog post from one of the authors, which has some stuff about decoder speed, decoder threading and encoder quality:

http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/