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. PNG/L and PNG/P with compression level 9. 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. 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.
On 22 September 2013 15:25, Antoine Martin <[email protected]> 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 > [email protected] > http://lists.devloop.org.uk/mailman/listinfo/shifter-users _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
