#455 closed enhancement (fixed)
vpx improvements: vp9 support, zero copy, VBR, speed and quality
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 0.15 |
Component: | core | Version: | |
Keywords: | Cc: |
Description (last modified by )
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
Change History (8)
comment:1 Changed 9 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Antoine Martin to Antoine Martin |
Status: | new → assigned |
comment:2 Changed 9 years ago by
Description: | modified (diff) |
---|---|
Summary: | vpx improvements: vp9 support, VBR, speed and quality → vpx improvements: vp9 support, zero copy, VBR, speed and quality |
comment:3 Changed 8 years ago by
Description: | modified (diff) |
---|---|
Milestone: | future → 0.12 |
comment:4 Changed 8 years ago by
Milestone: | 0.12 → 0.13 |
---|
comment:5 Changed 8 years ago by
Milestone: | 0.13 → 0.14 |
---|
Some work got done in this release as part of #465..
comment:6 Changed 7 years ago by
Priority: | minor → major |
---|
comment:7 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
comment:8 Changed 17 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/455
re-scheduling vpx stuff