[winswitch] encodings and compression [was: Terminal emulators with 0.12.19 update]

[Antoine Martin]

On 25/09/13 17:24, Nick Burrett wrote:
> In my experience, the encodings that I find to work the best are: PNG,
> PNG/P and PNG/L.  PNG I use on a local GigE LAN.
On a Gigabit LAN or better, isn't plain RGB+zlib better? Even playing an
HD video should not saturate the link, and PNG is unlikely to be able to
cope with 30fps.
>   PNG/L and PNG/P with
> compression level 9.
If you can tolerate the limited number of colours of PNG/L or PNG/P,
they will beat everything else which uses true colour encoding and
therefore has to work a lot harder.
Compression level 9 does absolutely nothing for picture compression
size, and only adds to the latency for the rest of the packets for very
little space saving. You should really avoid it.
FYI: trunk adds lz4 support for -z=1, it is faster than zlib (but
compresses a little less - which doesn't matter much)
>  I use for emacs/PyCharm/gnome-terminal where my
> client is in Ireland and the server is in North Sweden (50-60ms away).
>  x264 appears to have a higher encoding latency and tends to make
> screen updates jumpy.
If you care about latency, you should set the speed option high enough.
FYI: trunk is likely to get hardware assisted h264 encoding support soon
(using NVidia's NVENC), which should give us H264 HQ encoding with very
low latency on supported hardware.
>   My server has 24 CPUs and the client 4 CPUs, so
> there should be enough CPU capacity to encode at a decent rate, if
> threaded sufficiently.
The client CPU capacity rarely matters - unless you are on an embedded
CPU (ARM etc).
x264 is partially threaded (in recent versions at least), none of the
other are - and PNG is a CPU pig.
On top of that, PNG cannot be tuned, whereas x264 can (as per comment
about speed above).

It is possible for PNG to be faster (lower latency, but often lower
compression too) than x264 when used at a low enough framerate - but for
anything else, it is generally a poor option. (bar special case of PNG/L
and PNG/P)

To ascertain which encodings are the best for which application at which
resolution on which hardware, there are scripts in the source tree which
can run for hours and produce CSV output for analysis.
The comments above are based on weeks of testing (man-hours), but using
a limited set of applications and settings - it is possible, likely
even, that other workloads will behave differently. If you have specific
applications which behave poorly, we can look at them and try to improve
things.

Antoine

>
>
> On 22 September 2013 15:25, Antoine Martin <antoine at nagafix.co.uk> wrote:
>> On 22/09/13 11:31, Chris Hamilton wrote:
>>> Hi, sorry I am not in the mail list, so this will not be in the right
>>> thread.
>>>
>>>
>>>
>>> I followed directions in https://www.xpra.org/trac/ticket/429 however they
>>> did not seem to work.  I had similar issues manually setting
>>> XPRA_ALLOW_ALPHA as well as various command line parameters on xpra in
>>> Ubuntu, but nothing changed.  OpenGL on client or server didn't seem to
>>> change anything either.  I eventually set the xpra.conf encoding default to
>>> png in Windows and the terminals finally worked completely.
>> I don't really know what problem you are referring to... so the answer
>> below is just a guess:
>> If you use an encoding that does not use swscale (all except x264 and
>> vpx), then you may bypass problems with broken builds.
>> However, all the other encodings are also much much less efficient
>> (especially PNG), and xpra is now designed to run with the newer/better
>> encodings.
>> So, I still recommend that you resolve your swscale/x264 library issues.
>>
>> Antoine
>> _______________________________________________
>> shifter-users mailing list
>> shifter-users at lists.devloop.org.uk
>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users