-
-
Notifications
You must be signed in to change notification settings - Fork 167
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
Colorspace appears to change frequently #3837
Comments
Does this also happen with the python client? |
@totaam I can't reproduce when streaming over a VNC connection, so I don't think the java application is relevant. Will try the python client. |
Launching the application using Not sure why there would be a bandwidth issue, as everything is running on localhost. Maybe it's related to docker? |
I tried running the html client from the host machine, but the color depth quality issue came back. |
Right, so the problem is with the html5 client
The bandwidth warnings show up when there are latency spikes - docker containers can end up introducing measurable latency. If connecting locally, you should be using
Not really, only indirectly. This sounds like the browser is decoding |
Might be onto something with the browser decoding. I was using chrome/edge. Firefox doesn't have the colorspace/range issue, but it shows a significantly reduced quality image for those renders. https://youtu.be/dKOlNEK-cEk |
Despite setting |
If it only happens with the |
@totaam ok, any tips to debugging further? I'll try playing around with the html5 client source. |
@EmanH run your server with |
@totaam Setting an encoding on the client-side has solved the issue. Previously I was just setting the encoding server-side. h264 and webp are both working well. |
@EmanH that is very much the wrong thing to do. |
@totaam I wonder why it doesn't have the effect when I set h264 or webp from the server, but it does when setting it in the client? |
@totaam Setting video encoders explicitly to
|
None of that helps, figuring out which specific encoding(s) display with colorspace issues would. |
@totaam Yeah fair enough. |
If it is Perhaps we need to give a hint when calling VideoDecoder.configure to enable full-range colorspace. |
@totaam The issue was only occuring with Have opened this PR: Xpra-org/xpra-html5#248 |
Is it the case that different browsers use different defaults or that |
My bad, I mean |
Firefox was still having an issue, but appears to handle it differently. Yeah, I'd guess |
It could also be related to the colorspace conversion module used on Debian, which only recently got a libyuv package, so xpra on Ubuntu 20.04 is probably using xpra info | grep client.window (look for |
I've merged the PR, but I am still hoping to enhance the draw packets with better information about colourspace so that the server can specify which type of range to use client-side. |
We still have work to do on colourspaces. |
I know what we're doing wrong, we're not populating "Annex E" data so the decoders are guessing what colorspace is used, some get it wrong. |
for backwards compatibility, the client must expose the ranges it supports for each encoding, if it does not, then we assume the old defaults
Much improved by the commit above. Still TODO:
|
keep it that way for now since I can't find how to get the range information in the decoder API
Not sure how I missed it before, but with my current test config I can see colourspace issues with webp (ie: running xpra control :6 request-update png all "*"
xpra control :6 request-update webp all "*" All the other encodings look OK, but webp is washed out. Like it's painting studio range colours without stretching them. |
it sems that img.range is not set by the decoder?
and does not care what the client can and cannot handle, just make sure we use the video compression as it is meant to be used and let the client figure it out
so we can just deal with the shader selection, metadata updates, etc - all in one place
somehow the images decoded seem to have 'studio' range
somehow the images decoded seem to have 'studio' range
Likely fixed in aaabd5b - feel free to re-open if I've missed something. |
I'm running a java app and launching/streaming it with xpra from within an Ubuntu 20.04/22.04 docker container (using the html5 client).
It works ok, except for a troublesome change of color depth every time we interact with the app.
See the example here: https://youtu.be/Yxq6-KH2AOc
Observe the light-blue flickering before changing to darker blue. This is something XPRA is doing. The darker blue is the true color, and the lighter blue seems to be a compressed image where some of the pixel depth information is lost maybe? It also effects light greys in other parts of the UI.
I've tried playing around with various encodings, compression settings, quality settings, with opengl, without opengl, pixel-depth settings, etc. Nothing I can try, changes this.
I've tried a couple different base docker images, current one is based on:
After trying every parameter I could think of that might be relevent, I've come to the conclusion it might be an XPRA Bug.
@totaam, we'd be stoked if you could comment on what you think this might be, and any ideas we could try to resolve it? Thanks so much!
The text was updated successfully, but these errors were encountered: