Apr 212014
 

First of all, remove xpra and cython if you had them installed:

aptitude purge xpra cython

Update your package lists, as we are going to install a lot of packages:

aptitude update

Prepare required prerequisites

Then follow the instructions on the xpra Wiki for building Ubuntu / Debian style:

apt-get install libx11-dev libxtst-dev libxcomposite-dev libxdamage-dev \ python-all-dev python-gobject-dev python-gtk2-dev

apt-get install xvfb xauth x11-xkb-utils
apt-get install libx264-dev libvpx-dev libswscale-dev libavcodec-dev

The file mentioned in the how-to, vpx.pc should exist:

cat /usr/lib/pkgconfig/vpx.pc

You will need to install and compile Cython from sources, as the version in the Raspbian repository is too old (0.15.1 vs. 0.16 minimum needed).

wget http://www.cython.org/release/Cython-0.20.1.tar.gz
tar -xzf Cython-0.20.1.tar.gz

change into the newly extracted directory. Install cython:

python setup.py install

This will take quite a while. Test that you have the correct cython version:

cython --version

should yield Cython version 0.20.1

Download and extract source

wget https://www.xpra.org/src/xpra-0.12.3.tar.bz2
tar -xjf xpra-0.12.3.tar.bz2

Note: there may be a newer package, check, please.

Change into the extracted directory. We need to apply a patch:

patch < patches/old-libav.patch

Enter xpra/codecs/dec_avcodec/decoder.pyx as the file to patch

Next patch (several files in one go):

patch < patches/old-libav-pixfmtconsts.patch

Simply copy and paste the “Index file” the patcher asks for, for example xpra/codecs/csc_swscale/colorspace_converter.pyx

Next patch (also several files):

patch < patches/old-libav-no0RGB.patch

Act like above (copy & paste file name, without leading / ).

It also contains a useful README, which tells you the next step is:

./setup.py install --home=install

After the compilation is done, you should either (always) set the Pythonpath to include the install subdirectory, like this:

export PYTHONPATH=$PWD/install/lib/python:$PYTHONPATH

or install the “finished” files to the appropriate targets. From the install directory do:

cp bin/* /usr/bin/.
cp -R lib/* /usr/lib/.
cp -R share/* /usr/share/.

xpra will now be the newest version:

xpra –version

xpra v0.12.3

You will still have to set the PYTHONPATH to the new files in /usr/lib/python, though:

The PYTHONPATH environment variable needs to be set:

export PYTHONPATH=/var/lib/python:$PYTHONPATH

 

Test & Test results

OK, here’s how to set up a test session:

Set up a test server, which has xpra installed (you can install it through the winswitch packages, will get you the newest xpra version on Ubuntu & Debian)

Start X Windows, open LXTerminal, run the following commands.

export PYTHONPATH=/var/lib/python:$PYTHONPATH

Start an xpra session via SSH (can be killed using Ctrl-C, and reconnected to using the same command):

xpra start ssh:maxcs@192.168.1.61:122 –start-child=xterm –encoding=h264

Read the manpage (man xpra) to have a look at some other options

Test results

xpra-raspberry-h264

rgb, png encodings are too high-latency.

jpeg is barely usable, even when resizing the application (for instance Abiword) to not full-screen usage.

webm encoding delivers worse quality, but seems a bit more usable

h264 decoding is NOT done in hardware in the default code (we’ll look into this). Surprisingly it is still the “most fluid to use” one.

I suspect that no decoding in H.264 is taking place, and server side xpra falls back to a different encoder (webm?) Anyways, one can even “watch” videos (a couple of frames each second with heavy artifacts) with this.

For very light administration / checking of remote contents, etc. xpra can be used as is. We will need to enable hardware decoding of h264, though, for it to yield real benefits.

Please note: our interests solely rest in streaming TO the Raspberry Pi, not FROM the Raspberry Pi – we will not test / patch in order to speed up administration of the Pi at this point.

 

Notes & Further reading

Dependencies of xpra package:

(you can show this using “apt-cache showpkg xpra” on a machine which has the package in the newer version, e.g. Ubuntu AMD64):

Dependencies:
0.12.3-1 – python2.7 (0 (null)) python (2 2.7.1-0ubuntu2) python (3 2.8) libavcodec53 (18 4:0.8-1~) libavcodec-extra-53 (2 4:0.8-1~) libavutil51 (18 4:0.8-1~) libavutil-extra-51 (2 4:0.8-1~) libc6 (2 2.14) libgtk2.0-0 (2 2.24.0) libswscale2 (18 4:0.8-1~) libswscale-extra-2 (2 4:0.8-1~) libvpx1 (2 1.0.0) libx11-6 (0 (null)) libx264-120 (0 (null)) libxcomposite1 (2 1:0.3-1) libxdamage1 (2 1:1.1) libxext6 (0 (null)) libxfixes3 (0 (null)) libxrandr2 (2 4.3) libxtst6 (0 (null)) python-gtk2 (0 (null)) x11-xserver-utils (0 (null)) xvfb (0 (null)) python-gtkglext1 (0 (null)) python-opengl (0 (null)) python-numpy (0 (null)) python-imaging (0 (null)) python-appindicator (0 (null)) openssh-server (0 (null)) python-pyopencl (0 (null)) pulseaudio (0 (null)) pulseaudio-utils (0 (null)) python-dbus (0 (null)) gstreamer0.10-plugins-base (0 (null)) gstreamer0.10-plugins-good (0 (null)) gstreamer0.10-plugins-ugly (0 (null)) python-gst0.10 (0 (null)) openssh-client (0 (null)) ssh-askpass (0 (null)) python-numeric (0 (null)) python-lz4 (0 (null)) keyboard-configuration (0 (null)) xpra:i386 (0 (null))

CheckInstall

Optional: install checkinstall, to create a package which you can easily remove or re-deploy to other computers:

aptitude install checkinstall

 

Troubleshooting

Patches

error: implicit declaration of function ‘avcodec_free_frame’

you need to apply the patch patches/old-libav.patch

error: ‘AV_PIX_FMT_YUV420P’ undeclared

you need to apply the patch patches/old-libav-pixfmtconsts.patch

error: ‘PIX_FMT_0RGB’ undeclared

you need to apply the patch patches/old-libav-no0RGB.patch

The other patches were NOT needed in my experimental compilation.

 

ImportError: No module named xpra.platform

Once you try to execute xpra (from LXTerminal preferably), you may get this message. The PYTHONPATH environment variable needs to be set:

export PYTHONPATH=/var/lib/python:$PYTHONPATH

Apr 202014
 

We’re working on streaming a multimedia remote desktop to the Raspberry Pi.

In the future we envision, you shall be able to use a webbrowser on the Pi at normal speeds – including YouTube videos, etc. – operate with CPU / GPU intensive applications – as all the processing is done on a server, and just the H.264 stream rendering on the Raspberry Pi.

First steps

A very interesting application stack to serve this purpose is already available: WinSwitch & xpra

Look at the WinSwitch homepage for installation instructions – it is really quite easy.

WinSwitch bundles several remote clients (VNC / xpra / RDP) with an easy-to-use interface, and broadcasts servers / clients (via Avahi / Bonjour).

A very first demonstration of the capabilities of this stack can be obtained installing WinSwitch on your “normal” desktop machine, and on a server.

Server

As a server we currently use the “fastest available” Intel Atom processor currently on the market –  Intel(R) Atom(TM) CPU  C2750. We are looking into using AMD’s ARM 64 bit processor as server hardware in the future (power-efficiency!), and the performance should be roughly comparable.

Client

As a client we use a Dell Inspiron notebook (with Windows 8.1), Core i7 processor, FullHD resolution.

There is a xpra package available for the Raspberry Pi, which is based on a quite old version of xpra, and will not connect to our server. This may be related to the huge version difference between the two packages, wrong setup, or special tweaking done by winswitch to xpra.

Test results

YouTube videos

We can stream a webbrowser running YouTube fullscreen in FullHD, which will use about 50 % of the server’s total resources (decoding one or several videos in FullHD, encoding one FullHD stream). This is possible in low-latency, at about 30fps and high quality. Yes, this does include an audio stream, too.

The stream uses about 40 Mbp/s of bandwidth, and is much more reliable (less choppy) if streamed over LAN, instead of WLAN. In fast-moving scenes video will still be a bit choppy, but tolerably.

The encoding is done in software, using x264.

Streaming ONE browser window is possible with our server hardware in good quality (for video content) from either the host directly, or from a virtual Ubuntu machine (KVM-virtualized) inside it.

TWO browser windows will start to degrade the quality, even if trying to force best quality and lowest latency.

image

This screenshot shows the YouTube video in the browser being streamed on the client.

Application streaming

Winswitch allows you to stream single applications. Performance / latency is very good on a local network, keyboard / mouse delay is barely noticeable.

In general, applications will be quite useable and seem responsive.

Applications requiring precise mouse / screen cordination, like graphics software will not be usable (at least with our hardware setup).

image

This screenshot shows Firefox being streamed through xpra.

image

VLC media player being streamed – sound works

image

GIMP: barely usable (too much delays)

image

word processing with AbiWord: OK performance (could be better, but it’s usable)

 

Desktop streaming

Streaming a desktop with xnest / Xephyr / xpra from inside a virtualised Ubuntu container on the base hardware is NOT possible at low-latency (30 fps) with high-quality. (With our server hardware)

In order to test it, you have to install additional packages on the server:

aptitude install xnest xserver-xephyr

and set the desktop default to xpra, possibly after restarting the server / client:

image

Apparently frame-grabbing / mirroring the desktop / going through the X layer uses up much more processor resources.

image

Gameplay is quite smooth – but full screen video playback would be a problem.

Some hints

  • authentication with private/public key pairs may be problematic without additional configuration, for first tests I recommend to re-enable password login for SSH.
  • audio for the browser may require alsa and pulseaudio
  • This does not work on the Raspberry Pi yet, this is our next step (compiling a package for it).

 

Outlook

  • encoding performance and latency may be enhanced significantly using NVidia’s NVENC hardware encoding / framegrab API – which xpra supports.
Optimization WordPress Plugins & Solutions by W3 EDGE