xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#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 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.

Attachments (1)

vpx-vp9.patch (5.5 KB) - added by Antoine Martin 6 years ago.
fixes "broken frame" errors when using vp9

Download all attachments as: .zip

Change History (9)

comment:1 Changed 6 years ago by Antoine Martin

Milestone: 0.110.12
Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

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.

comment:2 Changed 6 years ago by Antoine Martin

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

Changed 6 years ago by Antoine Martin

Attachment: vpx-vp9.patch added

fixes "broken frame" errors when using vp9

comment:3 Changed 6 years ago by 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
Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 6 years ago by Antoine Martin

Milestone: 0.120.13

re-scheduling vpx stuff

comment:5 Changed 6 years ago by Antoine Martin

Milestone: 0.13future

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
Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 5 years ago by Antoine Martin

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

comment:7 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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

comment:8 Changed 5 years ago by Antoine Martin

Milestone: future0.15

(setting milestone)

Note: See TracTickets for help on using tickets.