(..) > I much prefer to use base system packages wherever possible. Me too, normally. Unfortunately, it's just painful to use xpra with the system packages.
>>> 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 ? The xpra server needs more encodings enabled to be able to send screen updates. For example, it is not always possible to send screen updates using `h264". There are size constraints, rounding errors, etc. > 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. Without knowing exactly what application you are testing with, I can't be certain, but forcing "h264" is almost always a bad idea. > I assume from what you say it is possible to define multiple encodings > that xpra can choose from somehow ? I have updated the manual to try to clarify : https://github.com/Xpra-org/xpra/commit/174056958a44d25d95bc5f8d659a5e916016620c --encodings vs --encoding (..) > xpra now works with me when "--encodings=h264" is set. Generally the > latancy/flickering is better than in auto. That's odd. Using "h264" alone will waste a lot of CPU and bandwidth. (assuming that it is actually used) The latency really depends on a large number of factors so I can't comment without knowing more. But there should be no flickering no matter which encoding is used. > 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% Do you have audio forwarding running? If there are no screen updates, the server CPU usage should be very close to zero. > after than or sometimes 100% or 200% and then sticks at > those values even though the page looks static after that. You can turn on "damage" and "compress" debugging on your server to see if it is receiving / sending screen updates: xpra start -d damage,compress * "damage" corresponds to application paint events * "compress" logs the type of picture compression used You can also see which encoding is used for each screen update using the colour coded client debug switch: xpra attach --no-mmap --env=XPRA_PAINT_BOX=1 The color codes are defined here: https://github.com/Xpra-org/xpra/blob/master/xpra/client/paint_colors.py > I assume that my xpra server here is using software h264 from those > figures. Assuming that it is actually using "h264" for all the screen updates - which is not guaranteed. > Is there anyway to determine if xpra is using hardware h264 if > I have managed to configure for that ? In theory, hardware acceleration should be used automatically if it is available. The only acceleration that is well tested is with NVENC. You can see which encoders are available on your system with: xpra encoding xpra video Again, just because hardware acceleration is available on your system does not mean that it should be used for every screen updates. In many cases, the server engine will prefer software encoding because it is more suitable. Cheers, Antoine > > >> >> Cheers, >> Antoine >> >> >>> Terry >>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users@lists.devloop.org.uk >>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users >> _______________________________________________ >> shifter-users mailing list >> shifter-users@lists.devloop.org.uk >> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > > _______________________________________________ > shifter-users mailing list > shifter-users@lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users _______________________________________________ shifter-users mailing list shifter-users@lists.devloop.org.uk https://lists.devloop.org.uk/mailman/listinfo/shifter-users
