[X2Go-Dev] FYI, the SPICE devs are developing stuff with GStreamer for video

[Mike DePaulo]

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.

http://knowyourmeme.com/memes/i-must-go
-Mike