spice.git - Spice

	Commit message (Collapse)	Author	Age	Files	Lines
*	client: mingw32 build needs the jpeg_boolean define	Alon Levy	2012-01-13	1	-1/+1
\|
*	add #include <config.h> to all source files	Christophe Fergeau	2011-05-03	1	-0/+3
\| \| \| \| \| \| \| \|	When using config.h, it must be the very first include in all source files since it contains #define that may change the compilation process (eg libc structure layout changes when it's used to enable large file support on 32 bit x86 archs). This commit adds it at the beginning of all .c and .cpp files
*	mingw32: refix to build on mingw..	Alon Levy	2010-12-30	1	-1/+1
\|
*	jpeg_boolean is a mingw32-libjpeg specific thing. Use a define check rather ↵	Tiziano Mueller	2010-12-30	1	-1/+1
\| \| \| \|	than a version check.
*	mingw32 build: fix signed/unsigned warnings as errors	Alon Levy	2010-12-08	1	-1/+1
\|
*	build: use jpeg_boolean with more recent libjpeg versions.	Gerd Hoffmann	2010-12-07	1	-1/+5
\| \| \| \|	Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
*	client: Include config.h from common.h	Alexander Larsson	2010-09-29	1	-4/+0
\| \| \| \| \|	config.h should be availible everywhere, so move its inclusion to the top of common.h.
*	Swap red and blue when decoding 0.4 mjpeg streams	Alexander Larsson	2010-07-20	1	-10/+19
\| \| \| \| \| \|	There was an error in how this was encoded in 0.4, which we need to handle. There is still some issues with the old streams as the luminocity handling in 0.4 was not correct.
*	Avoid unncessary buffer management in mjpeg decoder if possible	Alexander Larsson	2010-04-14	1	-19/+45
\|
*	Relicense everything from GPL to LGPL 2.1+	Alexander Larsson	2010-04-13	1	-9/+9
\|
*	Initialize _kill_mark so we don't get spurious valgrind warnings	Alexander Larsson	2010-04-08	1	-6/+8
\|
*	Free the jpeg decoder with the stream	Alexander Larsson	2010-04-08	1	-0/+1
\|
*	Use libjpeg to decode mjpegs, not ffmpeg	Alexander Larsson	2010-04-08	1	-0/+236
	This is pretty straightforward, although there are two weird issues. The current encoder has two bugs in the yuv conversion. First of all it switches red and blue, due to something of an endianness issue. We keep this behavior by switching red and blue. Maybe we want to change this in the new protocol version since switching this may cause jpeg compression to be worse. Secondly, the old coder/decoder did rgb to/from yuv420 wrongly for jpeg, not using the "full scale" version of Y that is used in jpeg, but the other one where y goes from 16 to 235. (See jpeg/jfif reference on http://en.wikipedia.org/wiki/YCbCr for details.) The new decoder uses the full range in order to get better quality, which means old encoders will show slightly darker images. This completely removes all ffmpeg usage in the client