vpx improvements: vp9 support, zero copy, VBR, speed and quality

[Antoine Martin]

Pointers:

• ​vp9 support
• ​vpx_img_wrap: Open a descriptor, using existing storage for the underlying image. (zero copy)
• ​rc_end_usage Rate control algorithm to use.
• ​VP8E_SET_CPUUSED Changes in this value influences, among others, the encoder's selection of motion estimation methods. Values greater than 0 will increase encoder speed at the expense of quality. The full set of adjustments can be found in onyx_if.c:vp8_set_speed_features().
• alpha channel support
• ​vpx_img_fmt: more supported image formats

etc.
Related to #464

[Antoine Martin]

re-scheduling vpx stuff

[Antoine Martin]

Some work got done in this release as part of #465..

[Antoine Martin]

See #464 and #832 for:

• vp9
• more image formats (YUV444)

Only leaves: ​vpx_img_wrap (and #465)

[Antoine Martin]

Not going to deal with zero copy, it is just too hard to do with the libvpx API. Closing as fixed since most points were addressed (see #832 mostly).

Encoder side, vpx_img_wrap is not useful, we already do zero copy using an image wrapper that points to the pixel data (generally the X11 shm pixels).
The documentation does not state if we are free to dispose of this pixel buffer or if we have to keep it around for some time (to be used as a reference frame?), but since I have not seen any crashes or visual corruption... I'll assume we can do what we want.

The decoder function ​vpx_codec_get_frame returns a ​vpx_image_t already made and says: The list of available frames becomes valid upon completion of the vpx_codec_decode call, and remains valid until the next call to vpx_codec_decode..
The problem is that since we don't control the allocation, we don't know if another thread (ie: the paint thread) is going to use the pointer to this memory. Simply copying the pixels before calling vpx_codec_decode again would not protect us against those forms of races.
To be able to use this, we would need to add locking in the image wrapper object, and this would delay decoding.

Final note, we could support ​vpx_codec_get_global_headers but since everything works OK without, not going to bother.

[migration script]

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