Many thanks for the reply, notes below.
On 21/05/2021 13:10, Antoine Martin via shifter-users wrote:
On 21/05/2021 16:09, Terry Barnaby via shifter-users wrote:
Hi,
I am testing the usage of xpra between two Intel Fedora33 systems. It
functions fine with default encoding (whatever is used) but I cannot
enable h264 encoding to test with this.
I have tried using the default Fedora RPM's "dnf install xpra
xpra-codecs-freeworld xpra-html5 xpra-udev" as well as the
https://github.com/Xpra-org/xpra RPM's.
Do not mix downstream packages like 'xpra-codecs-freeworld' and xpra's
packages.
And avoid downstream packages altogether:
https://github.com/Xpra-org/xpra/wiki/Distribution-Packages
Yes, I was not mixing xpra packages, just trying each set of xpra
packages separately.
I much prefer to use base system packages wherever possible.
Both show the same issue.
If I use "--encodings=h264" on a manually started server and client, the
server messages have the error listed:
This is the wrong switch to use.
You need more than one 'encodings' enabled to be able to run correctly.
Not sure what you mean by this ?
I am just experimenting to see what the capabilities/performance options
are and so was trying to force full h264 encoding to try this out.
I assume from what you say it is possible to define multiple encodings
that xpra can choose from somehow ?
That said, with the xpra.org packages installed correctly, this doesn't
cause the problems you report below.
This was my fault. I had "--csc-modules=none" set on the server from
previous tests.
Sorry for the noise.
"no common encodings found (server: rgb24, rgb32, grayscale, h264, auto
vs client: h264, excluding: h264, vp8, vp9, h264+mp4, mpeg4+mp4, mpeg1,
mpeg2, hevc)"
So something is setting the "excluding:" part for some reason. I cannot
find any information on why this would be.
Any ideas on what may be happening ?
As per the documentation:
https://github.com/Xpra-org/xpra/blob/master/docs/Usage/Encodings.md
*Do not* second guess the server engine by specifying encoding(s), as
you will get it wrong and the behaviour is very likely to be sub-optimal.
If you really want to use 'h264' and not the other video encoders, you
can just use --video-encoders=x264,nvenc on the server side. Nothing
else is needed, server side or client side.
As I said, it's a bad idea but it does work and will use 'h264' whenever
it is suitable - which if far from always being the case. ie: if the
xpra server detects that the application in use is plain text (ie: a
terminal) then it will still not use a video encoding like h264. Which
is one of the reasons why you still need other encodings enabled.
Yes, I understand that using a video stream for a static window is not a
good idea. As I was saying I am just testing the capabilities to see
what is possible.
xpra now works with me when "--encodings=h264" is set. Generally the
latancy/flickering is better than in auto. One thing that is interesting
is the CPU usage on the server side. Using firefox as a test client and
clicking on different web pages and waiting the server's CPU usage can
be around 15% after than or sometimes 100% or 200% and then sticks at
those values even though the page looks static after that.
I assume that my xpra server here is using software h264 from those
figures. Is there anyway to determine if xpra is using hardware h264 if
I have managed to configure for that ?
Cheers,
Antoine
Terry
_______________________________________________
shifter-users mailing list
[email protected]
https://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
[email protected]
https://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
[email protected]
https://lists.devloop.org.uk/mailman/listinfo/shifter-users
