xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 5 years ago

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

Change History (7)

comment:1 Changed 6 years ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

comment:2 Changed 6 years ago by Antoine Martin

Description: modified (diff)
Summary: vpx improvements: vp9 support, VBR, speed and qualityvpx improvements: vp9 support, zero copy, VBR, speed and quality

comment:3 Changed 6 years ago by Antoine Martin

Description: modified (diff)
Milestone: future0.12

comment:4 Changed 6 years ago by Antoine Martin

Milestone: 0.120.13

re-scheduling vpx stuff

comment:5 Changed 5 years ago by Antoine Martin

Milestone: 0.130.14

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

comment:6 Changed 5 years ago by Antoine Martin

Priority: minormajor

See #464 and #832 for:

  • vp9
  • more image formats (YUV444)

Only leaves: vpx_img_wrap (and #465)

comment:7 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.