Commit Graph

12 Commits

Author SHA1 Message Date
Christophe Fergeau
78c1465ed3 add #include <config.h> to all source files
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
2011-05-03 14:44:10 +02:00
Alon Levy
742703f641 mingw32: refix to build on mingw.. 2010-12-30 12:16:31 +02:00
Tiziano Mueller
3c46335004 jpeg_boolean is a mingw32-libjpeg specific thing. Use a define check rather than a version check. 2010-12-30 11:27:29 +02:00
Alon Levy
06749bd66b mingw32 build: fix signed/unsigned warnings as errors 2010-12-08 17:11:45 +02:00
Gerd Hoffmann
8879a45d56 build: use jpeg_boolean with more recent libjpeg versions.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2010-12-07 21:36:37 +02:00
Alexander Larsson
93dc13c91a client: Include config.h from common.h
config.h should be availible everywhere, so move its inclusion
to the top of common.h.
2010-09-29 13:26:21 +02:00
Alexander Larsson
ccbb922d5a Swap red and blue when decoding 0.4 mjpeg streams
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.
2010-07-20 11:45:37 +02:00
Alexander Larsson
5a1f8bafa0 Avoid unncessary buffer management in mjpeg decoder if possible 2010-04-14 11:41:37 +02:00
Alexander Larsson
c97116aeb9 Relicense everything from GPL to LGPL 2.1+ 2010-04-13 22:22:15 +02:00
Alexander Larsson
de4306af33 Initialize _kill_mark so we don't get spurious valgrind warnings 2010-04-08 17:09:32 +02:00
Alexander Larsson
18485cef06 Free the jpeg decoder with the stream 2010-04-08 16:35:10 +02:00
Alexander Larsson
5059c304be Use libjpeg to decode mjpegs, not ffmpeg
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
2010-04-08 11:30:18 +02:00