Xpra: Ticket #455: vpx improvements: vp9 support, zero copy, VBR, speed and quality


etc. Related to #464

Wed, 06 Nov 2013 11:31:09 GMT - Antoine Martin: owner, status, description changed

Wed, 06 Nov 2013 11:39:24 GMT - Antoine Martin: description, summary changed

Fri, 03 Jan 2014 15:42:44 GMT - Antoine Martin: description, milestone changed

Sun, 09 Feb 2014 08:27:01 GMT - Antoine Martin: milestone changed

re-scheduling vpx stuff

Fri, 09 May 2014 14:18:12 GMT - Antoine Martin: milestone changed

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

Tue, 14 Apr 2015 16:36:10 GMT - Antoine Martin: priority changed

See #464 and #832 for:

Only leaves: vpx_img_wrap (and #465)

Wed, 15 Apr 2015 09:54:02 GMT - Antoine Martin: status changed; resolution set

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

Sat, 23 Jan 2021 04:56:02 GMT - migration script:

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