From Libvpx 1.3.0 "Forest" Supports VP9. New Enhancements, it sounds like it is worth trying to upgrade - at least the static builds (OSX, win32 and old centos)
We should deal with a number of issues from #455 to bring vpx closer to feature parity with h264.
Tarballs aren't there yet and judging from the source code, it isn't quite ready yet. ie:
#if CONFIG_VP9_ENCODER // Make default VP9 passes = 2 until there is a better quality 1-pass // encoder
Re-scheduling.
r5103 + r5104 + r5105 add most of the code needed for vp9 support and compiles ok against a libvpx-1.3 git snapshot. Unfortunately, the decoder barfs:
Exception: paint_with_video_decoder: \ wid=1, vp9 decompression error on 5119 bytes of picture data for 499x316 pixels using \ <xpra.codecs.vpx.decoder.Decoder object at 0x3ae27e0>, options={'frame': 1, 'csc': 'YUV420P'}
fixes "broken frame" errors when using vp9
r5130 + r5131 + r5132 + r5133 make vp9 work as well as it can... which is slow, terribly slow, making it completely unusable. A simple VGA picture can take half a second to compress!
webm ticket 553 echoes the same findings: VP8 is 36 ms/f on same machine/file. 54x faster.
vp9-vs-h264 says: However there is a thing I have not mentioned Encoding Vp9 takes ages I thought encoding vp8 was slow but this is a new league in slowness.
Until google focuses on latency rather than compression ratio, or until we can find hardware that does compression fast enough, we should stay away from vp9.
Some sample data:
2014-01-06 18:57:38,346 1272.5ms to compress 499x316 pixels using vp9 with ratio=0.7%, delta=-1 2014-01-06 18:57:41,355 1266.1ms to compress 499x316 pixels using vp9 with ratio=0.6%, delta=-1 2014-01-06 18:57:44,412 1301.5ms to compress 499x316 pixels using vp9 with ratio=0.8%, delta=-1
vpx_codec_encode for vp9 took 279.4ms
re-scheduling vpx stuff
From The world’s fastest VP9 decoder: ffvp9:
See also: #832 (libvpx 1.4 support), which should improve the performance.
Good enough, will follow up in #832 and #455.
(setting milestone)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/464