libvpx 1.3: vp9, scaling, lossless modes..

[Antoine Martin]

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.

[Antoine Martin]

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.

[Antoine Martin]

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'}

[Antoine Martin]

fixes "broken frame" errors when using vp9

[Antoine Martin]

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:

• simple xterm window:

  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
  

• empty VGA image: vpx_codec_encode for vp9 took 279.4ms

[Antoine Martin]

re-scheduling vpx stuff

[Antoine Martin]

From ​The world’s fastest VP9 decoder: ffvp9:

• However, the encoder is slow, very slow.
• the 800-pound gorilla issue for VP9 adoption - at this point - is encoder performance (i.e. speed)
• VP9 encoding (using libvpx) is horrendously slow – like, 50x slower than VP8/x264 encoding
• ​vp9 issue 553: vp9 encoder is slow (and Vp9 does not support threads)
• ​VP9 Known Issues: Expect slow performance

[Antoine Martin]

See also: #832 (libvpx 1.4 support), which should improve the performance.

[Antoine Martin]

Good enough, will follow up in #832 and #455.

[Antoine Martin]

(setting milestone)

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/464