[winswitch] Fedora33 xpra h264 encoding support not working

[Terry Barnaby]

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
>> shifter-users at lists.devloop.org.uk
>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> https://lists.devloop.org.uk/mailman/listinfo/shifter-users