Xpra: Ticket #97: vpx encoding support

the vpx api is almost identical to x264 so this is easy to add, the patch almost works but I must be doing something wrong with the packing/index of the channels

Sat, 31 Mar 2012 14:49:30 GMT - Antoine Martin: attachment set

attachment set to xpra-vpx.patch

vpx almost working

Sat, 31 Mar 2012 14:51:29 GMT - Antoine Martin: owner, status changed

owner changed from Antoine Martin to ahuillet
status changed from new to assigned

please take a look, I am sure you can figure out what I did wrong quickly

note: when merging the x264 and vpx codepaths can be merged (in server.py and window_backing.py), only the implementation class is different (and the dimensions rounding - but this can also be moved to a codec class attribute).

Sat, 31 Mar 2012 14:57:08 GMT - ahuillet:

Your mask for window size is incorrect - should be FFFE to ensure even dimensions, FFFF just truncates it to < 65535.
Are you sure that libvpx can do the RGB -> YUV420 colorspace conversion by itself? You're allocating an input picture in YUV420 format but filling it in with RGB packed data (hence a single plane)
Same on the decompress side: the codec probably works with YUV420 (or any other form of YUV), but your output should be RGB

Sun, 01 Apr 2012 09:55:47 GMT - Antoine Martin: status changed; resolution set

status changed from assigned to closed
resolution set to fixed

the mask is OK, vpx does not seem to mind odd dimensions, I left the mask code in to make it easier to merge the x264 and vpx code together
rgb-yuv: yes, obviously.. that did the trick

r677 fixes the colourspace and vpx is now supported (also refactored the x264 code to re-use as much code as possible)

Wed, 04 Apr 2012 13:24:21 GMT - Antoine Martin: milestone changed

milestone changed from 0.1 to 0.2

Sat, 23 Jan 2021 04:45:28 GMT - migration script:

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