As per this test report. x264 performs very well with 10 bit data.
The big difficulty is that this is a compile time switch so we would need a different build of the x264 libraries with 10-bit support... And the symbols would likely clash with the 8-bit ones. So we would need to choose which one to load early.
This is no longer a compile time switch: x264 supports both 8-bit and 10-bit outputs, and you don't have to do anything special: Previously you had to compile x264 with --bit-depth=10, and then link your ffmpeg to either an 8-bit or 10-bit libx264, but that is now unnecessary
Now found in
The only colorspace type that explicitly mentions 10-bit is
So maybe we'll have to upsample and use the
X264_CSP_HIGH_DEPTH bit: the csp has a depth of 16 bits per pixel component.
RGB should be trivial to convert to 48 / 64-bit, though it's not clear what sort of bit layout it will be expecting for
The patch attached seems to do something: we convert the r210 image to 48-bit per pixel (via
r210_to_rgb48) and x264 accepts it.
enc_x264(slow: just cython argb code), needs to be moved to
dec_avcodecmay need a CSC step (what is the bit layout of
YUV422P10LE?) and also changes to the texture upload code (can't use
BYTE..) - hopefully no changes to the shaders?
Updated patch will follow.
work in progress
Done in r26908. Verified that the 10-bit h264 stream we generate is correct using:
XPRA_SAVE_TO_FILE=test10bit xpra start --start=xterm --pixel-depth=30
And then attaching a client with:
xpra attach --no-mmap --pixel-depth=30 --encodings=h264 --opengl=force
r210_to_bgr48hack call with a proper csc step (swscale?)
restore csc_cython so we have a r210 csc module
This will do for this ticket.
Fixed for csc in r26960.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1462