#464 closed enhancement (fixed)
libvpx 1.3: vp9, scaling, lossless modes..
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | minor | Milestone: | 0.15 |
Component: | core | Version: | |
Keywords: | Cc: |
Description (last modified by )
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.
Attachments (1)
Change History (10)
comment:1 Changed 8 years ago by
Milestone: | 0.11 → 0.12 |
---|---|
Owner: | changed from Antoine Martin to Antoine Martin |
Status: | new → assigned |
comment:2 Changed 8 years ago by
Description: | modified (diff) |
---|
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'}
comment:3 Changed 8 years ago by
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
comment:5 Changed 8 years ago by
Milestone: | 0.13 → future |
---|
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
comment:6 Changed 7 years ago by
See also: #832 (libvpx 1.4 support), which should improve the performance.
comment:7 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:9 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/464
Tarballs aren't there yet and judging from the source code, it isn't quite ready yet. ie:
Re-scheduling.