NOTE: I am sending this email to x2go-dev, the 1 QVD dev I know best, and the 2 lead devs on Arctica. I do not want to exclude anyone from the convo, but I do not know who else to CC.
This email is just an FYI: food for thought.
http://lists.freedesktop.org/archives/spice-devel/2015-August/021279.html http://lists.freedesktop.org/archives/spice-devel/2015-August/ Search for "GStreamer"
Introduction to SPICE for people only familiar with X2Go/nx-libs:
SPICE is a remote desktop protocol/solution, whose server is typically is implemented in the qemu-kvm hypervisor. The guest OS (Windows or Linux/X.org) is expected to use it via their QXL graphics driver and various guest agents (for things like clipboard sharing.)
The above paragraph is what Red Hat's RHEV product and their upstream oVirt project ships. Their interaction with eachother, other upstream projects (qemu especially) and Linux distros (Fedora, CentOS) is complex, but perhaps a good model for X2Go, Arctica, etc. (Even though we do not and should not "sell" access to our binaries like Red Hat does with RHEV.) (I intend to blog about and/or discuss the RHEV-oVirt-upstream-projects model.)
X.org (xfree86 DDX) can also use the qxl driver directly and implement the SPICE server in its own process, rather than in the host's qemu-kvm process. The python script for making it run as as drivers for X.org is called XSpice, which sounds like a DDX, but technically isn't. XSpice is part of the qxl (SPICE driver) package for Linux. http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/
So the XSpice python script is roughly comparable to x2goserver's scripts. It event starts those guest agents, but for use without the hypervisor.
SPICE uses multiple channels (graphics, audio, clipboard sharing) over a single TCP connection, similar to Microsoft RDP. This is in contrast to X2Go using separate TCP connections over SSH.
SPICE typically uses SSL/TLS, but can be used over SSH. Authentication and encryption is purposely not implemented in the SPICE protocol itself, so that it can be handled by things like TLS (or SSH) instead.
SPICE uses client-side rendering for 2D drawing (like nx-libs does), but has traditionally decoded videos via the guest OS, and then let SPICE re-encode them as MJPEG. I tried this on a VM running on qemu-kvm with SPICE with a youtube video, and it had the effect of taxing 1 CPU core on the host, but making the video decently smooth across my home LAN. I forget if I did this with oVirt (complex to setup) or with virt-manager (far easier to setup), but either way, it was qemu-kvm via libvirt. This was months ago.
So their use of GStreamer is interesting.
Also, note that nx-libs does have certain advantages over SPICE, such as support for RemoteApp mode, lower bandwidth usage and better WAN performance. I am NOT suggesting we "jump ship."
BTW, if you think that Red Hat / SPICE is evil, watch this: https://youtu.be/hb3zTQMJggo?list=PL0x39xti0_64fA6uRtcfoJPkHfZdeVTRC&t=834 The rest of the video is amazing too, even though the slides are blurry in the video.
If you wish to have a separate convo about SPICE that is unrelated to GStreamer, start a new thread. This wall-of-text was just my intro to SPICE, which I really should have put on a wiki page or something.