xpra.org
Replies: 9 comments 19 replies
-
The problem seems to come from
Yes.
No. This should be automatic. |
Beta Was this translation helpful? Give feedback.
-
Yes, seems like there is nothing I can do on the client side. Maybe just use WebP or JPEG as an alternative option. FYI, I also tried use 5.0.9 Client to connect with 6.1.2 Server, since FFMPEG available in it, here are the error in H264: And H265 |
Beta Was this translation helpful? Give feedback.
-
|
Oh, what a mess! Unfortunately, the openh264 decoder still seems to choke on it, not sure why yet - though I have seen this error before: openh264 frame decoding error I thought I would use the ffmpeg decoder still present in v5 to compare with, unfortunately this one also broke: #4344 |
Beta Was this translation helpful? Give feedback.
-
|
@Simba98 as per #4344, where do you get your ffmpeg libraries from? |
Beta Was this translation helpful? Give feedback.
-
|
Never mind, I'm seeing the same problem now too. |
Beta Was this translation helpful? Give feedback.
-
FYI, the ffmpeg comes with the official Windows Xpra 5.0.9 build (Xpra-x86_64_5.0.9-r0). By the way, would you mind briefly give me some hints on how to line-by-line debugging Xpra on Windows? I hope you could introduce what is your choice. Visual Studio? Copy your setting would be good for a starter. I still remember the #4003 . :( I even not successfully debug Xpra yet. |
Beta Was this translation helpful? Give feedback.
-
|
@Simba98 the fixes have been applied (see #4345 for details) but it will take some time before a new release is out - 5.0.10 will probably come first. You can find MS Windows "Light" beta build (6.2-r36606 / 5.0.10-r120 or later) with the fixes here: https://xpra.org/beta/windows/ As for debugging xpra, I never use a debugger - as this breaks in all sorts of interesting ways by breaking the UI thread. Timing is everything. |
Beta Was this translation helpful? Give feedback.
-
FYI, if needed, I really update the nvidia driver minor version from 535.129.0x to 535.183.01. The issue is with 535.183.01 NVENC 12.2 SDK on Rocky Linux 8.
Will test it now.
Wow, really an expert way to do so. Thanks for the information, hope that I can complete it. Thank you again for your rapid fixing the NVENC issue. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
See also caf91e2 |
Beta Was this translation helpful? Give feedback.
-
Thanks for the notification, still trying to manually patch the Xpra Server by modify the code in-place. |
Beta Was this translation helpful? Give feedback.
-
Looks good, the bellowing is just for recording. The following bash code is applied from the stable release install v6.1.2. After the bash code, then close xpra server then restart. Seems like openh264 decoder is not related on server, so only Using Light build from Windows: And looks good. |
Beta Was this translation helpful? Give feedback.
-
|
It may be easier for you to just install the latest beta, which will have all these fixes. (6.2-r36610 or later) |
Beta Was this translation helpful? Give feedback.
-
Yes, for sure; I just want to modify the code in place, :P. Thank you for your reminder. And the H264 encoding on NVENC is not satisfied if the quality is lower than "Average" For your reference, this is while the quality is "lossless" (we know it is actually 100% quality factor for H264, :P) |
Beta Was this translation helpful? Give feedback.
-
I'm not sure I understand. Are you saying that the server uses another encoder / encoding?
So the bottom line is missing? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the nearest neighbour could have this effect. |
Beta Was this translation helpful? Give feedback.
-
|
Nearest neighbour is only used when subsampling, that is when the quality is lower than 85%: YUV444_THRESHOLD = envint("XPRA_NVENC_YUV444_THRESHOLD", 85) |
Beta Was this translation helpful? Give feedback.
-
This is not only due to 85%, but since Xpra 6.x client removed ffmpeg, YUV420P is forced. So for this application jpega would be preferred before ffmpeg comes back. (Thanks to added nvjpeg on Issue 2984) I suggest closing this discussion since everything is good now. |
Beta Was this translation helpful? Give feedback.
-
Comes back? What does this mean?
What am I looking at? |
Beta Was this translation helpful? Give feedback.
-
I mean, since openh264 decoder on Windows only support YUV420P, for the app has some one pixel wide seletion box, users should use jpeg/jpega/webp for avoiding YUV420P space.
It is on official Windows 6.1.2 Xpra build. I can not figure out why this is csc module compatible with jpeg but not with jpega. |
Beta Was this translation helpful? Give feedback.
-
Users should increase the quality and let the server engine decide what is best - never select encodings manually.
OK, but there is no context, I have no idea where this text comes from.
Which csc module? |
Beta Was this translation helpful? Give feedback.
-
|
I should refer the context, which is on the first of this discussion. Xpra 6.1.2 on Windows 11. (Copied from the top) As you can see for jpeg there are two, but for jpega there are none.
Emmmm, sometimes it will not, let me try to reproduce it. |
Beta Was this translation helpful? Give feedback.
-
That's because your window doesn't use transparency (no |
Beta Was this translation helpful? Give feedback.
-
|
I encounter a issue in Xpra 6.1.3 which is not reproduceable in 6.1.2. Maybe related to some changes in this thread. Both Xpra client and server are updated to 6.1.3. The phenomenon is if a GUI software update a large of area (e.g. Zoom-in / re-fresh in the software), Xpra can not update drawing respectively. If I forcely use WebP/PNG encoding in Xpra Client, Xpra works well, if I forcely use H264 Xpra, then the phenomenon is as same as 'automatic' encoding. NVENC is enabled and works well (at least in 6.1.2) in server and no error message from the log with '-d video' option in client. |
Beta Was this translation helpful? Give feedback.
-
respectively - What does this mean?
Any errors in the server log? This sounds like a different issue from the one in this ticket. |
Beta Was this translation helpful? Give feedback.
-
I mean the region that the software updated has not been updated in Xpra Client Drawing, but I am familiar with the software so I know some regions should be updated (e.g. Zoom-in).
No, nothing abnormal was found, trying to test with different versions of client/server combination to narrowing the scope of the problem.
OK, if I find some more clear clues I will create a new thread. |
Beta Was this translation helpful? Give feedback.
-
|
You are right, not related here. |
Beta Was this translation helpful? Give feedback.
-
Server and Client: Xpra 6.1.2
Server: Rocky Linux 8 with NVENC enabled checked with
xpra encodingClient, MS Windows 11 with Intel iGPU of 12th Gen CPU (UHD 770).
Client command:
.\Xpra_cmd.exe attach ssh://SRV/DISPLAY --desktop-scaling=off -d videoAnd while these errors are printed on the terminal, the windows will be a little blurred for seconds, and automatically return to normal (maybe some fallback mechanism?)
It does not matter if H264 does not work with BGRX; is it possible to force the server not to use the combination of H264 and BRGX?
As a result, if I manually pick either WebP or JPEG or JPEG with alpha, there is no error message from the terminal and Xpra runs well.
Select "Automatic, or Video" from the Xpra Tray Icon -> Picture menu will return the above error and blur rendered windows.
Other information may have change related:
Run xpra.exe will give me a pop message:
But no error message from Xpra_cmd.exe, and the above window blurred phenomenon can be observed on both Xpra.exe and Xpra_cmd.exe. FYI.
Beta Was this translation helpful? Give feedback.
All reactions