new h264 codec implementation causes virtual screen tearing

[oldwizard1010]

version from aur
xpra-git

(4.4.r3230.g402c9173e-1 => 4.4.r3624.g05f6559850-1)

xpra v6.0-r35166 (g402c9173e) beta => xpra v6.0-r35559 (g4429944651) beta

caused screen tearing with encodings:
avif, h264, scroll

(others were not tested, because they were laggy on previous versions as well)

rolling back to previous build fixed the issue

[totaam]

4.4.r3230.g402c9173e-1 => 4.4.r3624.g05f6559850-1

These do not look like any valid versions.

[oldwizard1010]

fixed versions

[totaam]

caused screen tearing with encodings: avif, h264, scroll

How do you configure that?
You need more than these for xpra to work properly.

Does it go away if you turn off opengl?

[oldwizard1010]

Server has version xpra v6.0-r35166 (g402c9173e) beta installed

Client has either the same or updated version
same version works kind of fine, updated version on the client causes tearing

Connection established either on local Lan via 5g wifi, or via wireguard vpn, both are working without big difference

xpra attach ssh://user@hostname/:0 --encoding=avif

I force specific encoding, because otherwise picture quality is very unstable and laggy

[totaam]

Forcing an encoding is not how you fix whatever issues you are having, please refer to the documentation, which is plentiful. Try quality and speed first.
--encoding=avif is not a good option in any case, and does not use avif exclusively.

Does it go away if you turn off opengl?

[oldwizard1010]

UPD.:
yes, adding --opengl=no fixes tearing

[totaam]

yes, adding --opengl=no fixes tearing

So I fail to see how this can have anything to do with new h264 codec implementation in this ticket summary.
There is no new h264 implementation in v6, though the decoder has changed and no longer uses ffmpeg.

[oldwizard1010]

yeah, i know, that forcing encoding is not intended way of fixing, but that's what works in practice

fixing according to documentation did not provide me the result i was satisfied with, so i went the path of try&error

also rdp protocol uses h264 and it had awesome quality, so i decided to just force something similar in the end

---

if you're interested, my setup is not following documentation either, i have server nvidia tesla gpu and i'm using xpra with GPU acceleration not with vglrun, but with custom xorg.conf and it works much better))

[totaam]

Maybe the encoder side is having an effect on the openh264 decoder.
Are you using nvenc? (and you absolutely should)
Use -d compress to verify.

[oldwizard1010]

should

-d compress

be used on server side or the client?

client side usually has either integrated amd gpu or some other random one

p.s.: i removed my testing setup for now, so i'll not be able to test it for now

[totaam]

-d compress

be used on server side or the client?

server.

[oldwizard1010]

 xpra --video-encoders=help
       the following video-encoders are defined: x264, openh264, vpx, nvenc, nvjpeg, jpeg, webp, gstreamer

CUDA initialization (this may take a few seconds)
GStreamer version 1.22.10
CUDA 12.2.0 / PyCUDA 2022.2.2, found 1 devices:
  + Tesla P40 @ 0000:01:00.0 (memory: 11% free, compute: 6.1)
xpra is ready.
xpra X11 seamless server version 6.0-r35166 (g402c9173e) beta

well, it has nvenc as availible one, but

using
xpra start :0 --video-encoders=nvenc -d compress
limiting server to nvenc only causes slower refresh rate, than just xpra start :0

[oldwizard1010]

I suppose, it would be kinda useful if i share my full configuration with you
It's hacky and is a mix of xpra, xrdp and xrdp_nvidia patch
And uses full Xorg instead of xvfb / xpra_Xdummy

[totaam]

the following video-encoders are defined

Defined is not necessarily the same as available, but it usually is.
Especially if the GPU is found.

xpra start :0 --video-encoders=nvenc -d compress

Yes, that's expected.
It's a almost never a good idea to second guess the xpra server engine.
nvenc is slow to start so xpra needs vpx or x264 to help with that.

And uses full Xorg instead of xvfb / xpra_Xdummy

Sounds like: https://github.com/Xpra-org/xpra/blob/master/docs/Usage/OpenGL.md#taking-over-an-existing-display

[oldwizard1010]

Sounds like: https://github.com/Xpra-org/xpra/blob/master/docs/Usage/OpenGL.md#taking-over-an-existing-display

kind of, but it's created directly by xpra

[totaam]

Could be related to #4201, as it seems to be somehow worse with OpenGL enabled and with newer versions.

[totaam]

I assume that this is #4201