Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x264 10-bit support #1462

Closed
totaam opened this issue Mar 9, 2017 · 8 comments
Closed

x264 10-bit support #1462

totaam opened this issue Mar 9, 2017 · 8 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Mar 9, 2017

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.

@totaam
Copy link
Collaborator Author

totaam commented May 14, 2020

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.

@totaam
Copy link
Collaborator Author

totaam commented Jul 6, 2020

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?

@totaam
Copy link
Collaborator Author

totaam commented Jul 6, 2020

Related changes:

Updated patch will follow.

@totaam
Copy link
Collaborator Author

totaam commented Jul 6, 2020

2020-07-06 17:27:01: antoine uploaded file x264-10bit.patch (14.8 KiB)

work in progress

@totaam
Copy link
Collaborator Author

totaam commented Jul 7, 2020

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:

@totaam
Copy link
Collaborator Author

totaam commented Jul 9, 2020

2020-07-09 11:38:55: antoine uploaded file csc-cython-r210.patch (14.5 KiB)

restore csc_cython so we have a r210 csc module

@totaam
Copy link
Collaborator Author

totaam commented Jul 10, 2020

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

This will do for this ticket.

@totaam totaam closed this as completed Jul 10, 2020
@totaam
Copy link
Collaborator Author

totaam commented Jul 12, 2020

Fixed for csc in r26960.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant