Strange artifacts after enabling nvenc #3761
Comments
|
Oh, I forgot to include client logs in my initial report: |
|
First, never do this:
Then later on:
So, don't do that.
That's probably a transient error that happens during initialization. This looks like a bug in the html5 client's rendering code. Perhaps it is using the unscaled size for painting? |
|
Thanks for the quick feedback! I'll disable the --video-encoders flag. I was desperately bludgeoning things by the time I filed this issue :)
This one's actually pretty load-bearing and given your suspicion about the client rendering code, may be another hint? When I disable this flag, everything turns to a blurry mess and jumps around all over the screen even with nvenc disabled. I'll try to get a screencap to show what I'm talking about.
Right, that does seem like a recipe for problems. Do you have any idea why it believes the maximum supported resolution is 1024x768? From nvidia's docs, it looks like a T4 should be able to do h264 @ 4096x4096. Maybe I'm still misconfiguring something? I'll give it another go with the Thanks again! |
|
Oh, and as I mentioned above I have xpra sitting behind an authenticating proxy, so it'll take a bit of work to get the native python client pointed at it for comparison. |
|
Okay, I've done another go of this with the This is behaving differently from how I remember it. The quality and performance are significantly below what they are with hardware encoding support removed entirely. Occasionally, the entire display will freeze and won't recover until I disconnect the session and reconnect. I am, however, no longer seeing those green regions -- I assume that's from turning off Here's a snippet of that session. Around second 8, the entire display becomes unresponsive: Here's the logs that came out whole doing the screen recording: |
This means that the server is deciding to downscale the pixel data.
It's not the server that is setting this limit, it is the client.
Newer versions of the html5 client will allow for higher video resolutions when offscreen decoding is enabled: Less scaling for offscreen decoding
The python client in xpra attach wss://username:password@host:port/display?extra=whatever
This may happen because the server is hung waiting for its cuda context or because the HTML5 client somehow fails to report its failure to decode a screen update. |
Ah, nice! Looks like pulling from your apt repo still doesn't include that change. Fiddling with things today, I've found that the nvjpeg encoder has been giving me pretty great results without the quirks I was seeing with nvenc. Is there a best practice for telling xpra to strongly prefer that encoder? I've forced it with I'll try to update to the html5 client including your linked changes in the next day or two and give the python wss client a go as well. With the nvjpeg approach giving me acceptable results, I'm probably not going to be able to focus on this full-time for the next few days. Thanks! |
I'll try to make some beta
Yes, it is much easier to handle, both on the server side and client side.
That's an invalid value and should have triggered a warning. Generally speaking, it is best to not use the |
Scaling from 1946x600 to1024x768 does make the video look artifacted. |
|
This could be related to #3837 (comment) |
Describe the bug
I have an xpra server & html5 client connecting to it. When I have nvenc disabled, I can connect and everything looks similar to a local desktop session. When I enable nvenc and interact with the xpra session, entire regions of the display jump up and to the left by like ~50px, leaving a large green negative space. Here's a recording of an example:
nvenc_artifacts.webm
To Reproduce
Steps to reproduce the behavior:
System Information (please complete the following information):
Additional context
xpra encodingyeilds:The docker command to kick off XPRA is basically this:
docker run --gpus=all $IMAGE_ID $LAUNCH_COMMANDI am doing a funny trick with socket forwarding, but I don't think it relates to this problem. I have a web server that kicks off xpra in docker, having xpra bind to a unix socket. My web server auth & client session management, forwarding requests to the unix socket xpra is bound to. This setup works very reliably with nvenc disabled.
I'm happy to provide any additional details to help with troubleshooting.
The text was updated successfully, but these errors were encountered: