Open a descriptor, using existing storage for the underlying image.(zero copy)
Rate control algorithm to use.
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().
etc. Related to #464
re-scheduling vpx stuff
Some work got done in this release as part of #465..
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).
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_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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/455