xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 days ago

Last modified 24 hours ago

#1462 closed task (fixed)

x264 10-bit support

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 4.1
Component: encodings Version: trunk
Keywords: Cc:

Description

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.

Attachments (2)

x264-10bit.patch (14.8 KB) - added by Antoine Martin 7 days ago.
work in progress
csc-cython-r210.patch (14.5 KB) - added by Antoine Martin 4 days ago.
restore csc_cython so we have a r210 csc module

Download all attachments as: .zip

Change History (12)

comment:1 Changed 2 years ago by Antoine Martin

Milestone: future3.1
Status: newassigned

comment:2 Changed 16 months ago by Antoine Martin

Milestone: 3.14.0

Milestone renamed

comment:3 Changed 10 months ago by Antoine Martin

Milestone: 4.04.1

comment:4 Changed 2 months ago by Antoine Martin

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 x264_param_t: i_bitdepth.

The only colorspace type that explicitly mentions 10-bit is X264_CSP_V210: X264_CSP_V210.
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. BGR(A) and 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 I420 (aka YUV420P) or I444.

Last edited 2 months ago by Antoine Martin (previous) (diff)

comment:5 Changed 7 days ago by Antoine Martin

Some preliminary / related changes and minor tweaks in r26894, r26895, r26896, r26897, r26898.

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.

Still TODO:

  • the CSC is inlined into enc_x264 (slow: just cython argb code), needs to be moved to csc_swscale
  • client side will need CSC no matter what: non-opengl case will need downsampling to 24-bit, opengl can handle higher bit depths but the data from dec_avcodec may 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?

comment:6 Changed 7 days ago by Antoine Martin

Related changes:

  • #2826 more bit depths with opengl
  • #2827 x264 and ffmpeg RPM conflicts
  • r26900 better decoder assert message

Updated patch will follow.

Changed 7 days ago by Antoine Martin

Attachment: x264-10bit.patch added

work in progress

comment:7 Changed 6 days ago by Antoine Martin

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

TODO:

  • decode and render in opengl: #2828
  • replace r210_to_bgr48 hack call with a proper csc step (swscale?)
Last edited 6 days ago by Antoine Martin (previous) (diff)

Changed 4 days ago by Antoine Martin

Attachment: csc-cython-r210.patch added

restore csc_cython so we have a r210 csc module

comment:8 Changed 3 days ago by Antoine Martin

r26940 + r26941 + r26943: do the csc step via csc_cython

This will do for this ticket.

Last edited 3 days ago by Antoine Martin (previous) (diff)

comment:9 Changed 3 days ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

comment:10 Changed 24 hours ago by Antoine Martin

Fixed for csc in r26960.

Note: See TracTickets for help on using tickets.