This patch implements support in LibVNCClient for framebuffer updates
encoded as H.264 frames. Hardware accelerated decoding is performed
using VA API.
This is experimental support to let the community explore the possibilities
offered by the potential bandwidth and latency reductions that H.264 encoding
allows. This may be particularly useful for use cases such as online gaming,
hosted desktops, hosted set top boxes...
This patch only provides the client side support and is meant to be used
with corresponding server-side support, as provided by an upcoming patch for
qemu ui/vnc module (to view the display of a virtual machine executing under
QEMU).
With this H.264-based encoding, if multiple framebuffer update messages
are generated for a single server framebuffer modification, the H.264
frame data is sent only with the first update message. Subsequent update
framebuffer messages will contain only the coordinates and size of the
additional updated regions.
Instructions/Requirements:
* The patch should be applied on top of the previous patch I submitted with
minor enhancements to the gtkvncviewer application:
http://sourceforge.net/mailarchive/message.php?msg_id=30323804
* Currently only works with libva 1.0: use branch "v1.0-branch" for libva and
intel-driver. Those can be built as follows:
cd libva
git checkout v1.0-branch
./autogen.sh
make
sudo make install
cd ..
git clone git://anongit.freedesktop.org/vaapi/intel-driver
cd intel-driver
git checkout v1.0-branch
./autogen.sh
make
sudo make install
Signed-off-by: David Verbeiren <david.verbeiren@intel.com>
According to the minilzo README, this brings a significant
speedup on 64-bit architechtures.
Changes compared to old version 1.08 can be found here:
http://www.oberhumer.com/opensource/lzo/lzonews.php
Signed-off-by: Christian Beier <dontmind@freeshell.org>
No functional changes. All files used by _both_ libvncserver and
libvncclient are put into a 'common' directory and references
from other files as well as Autotools and CMake build systems are
updated.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
The flag handling (both compiler options and include paths) are a mess at
the moment. There is no point in forcing "-O2 -g" when these are already
the defaults, and if someone changes the defaults, chances are good they
don't want you clobbering their choices.
The -Wall flag should be handled in configure and thrown into CFLAGS once
rather than every Makefile.am. Plus, this way we can control which
compilers the flag actually gets used with.
Finally, the INCLUDES variable is for -I paths, not AM_CFLAGS. Nor should
it contain -I. as this is already in the default includes setup.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Christian Beier
Brian Bidulock
David Verbeiren
Vic Lee
dscho
runge
steven_carr