On Tue, Jun 28, 2011 at 10:13:24PM +0200, Christophe Fergeau wrote:
> Yes, I know, I haven't looked at all at that code yet though, but it can
> be done later if this patch series looks like the way to go.
After having looked at the jpeg_encoder.c code, it looks similar to
mjpeg_encoder.c after th
Hi,
On Tue, Jun 28, 2011 at 09:39:05PM +0300, Yonit Halperin wrote:
> server/jpeg_encoder.c can benefit from libjpeg-turbo as well. It is
> used for sending jpeg bitmaps if the client connection is limited
> (or when setting jpeg-wan-compression=always on spice options in
> qemu command line). It
On 06/28/2011 02:18 PM, Christophe Fergeau wrote:
Hi,
Currently, the mjpeg encoder has to preprocess the images it gets from
spice-server to make sure the pixel order is the one libjpeg expects (RGB).
This means iterating over the whole images swapping pixels since the input
images are BGR or BG
On Tue, Jun 28, 2011 at 12:55:31AM +0200, Marc-André Lureau wrote:
> Although not really important, the previous code was racy (stat + exec).
>
ACK. Just need to document that the spice-xpi-client must use exec as
the last step, or be a symlink to the client itself.
> I propose running /usr/libe
After the refactoring to optionally use libjpeg-turbo, some
of the functions that mjpeg-encoder used to provide are now no
longer used. This commit removes them.
---
server/mjpeg_encoder.c | 46 --
server/mjpeg_encoder.h |4
2 files changed, 0
When libjpeg-turbo is available, we can use the BGR and BGRX
colorspaces that it provides to avoid extra conversions of the
data we want to compress to mjpeg
---
server/mjpeg_encoder.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/server/mjpeg_encode
The main point is to move the pixel conversion code into
the MjpegEncoder class to be able to make use libjpeg-turbo
additional pixel formats without the reds_worker code noticing.
---
server/red_worker.c | 85 +++---
1 files changed, 12 insertions(+),
Returns the number of bytes per pixel corresponding to the input
data format.
---
server/mjpeg_encoder.c |5 +
server/mjpeg_encoder.h |1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/server/mjpeg_encoder.c b/server/mjpeg_encoder.c
index 8e74e0a..bfe8ca7 100644
--- a
This API is meant to allow us to move the pixel format conversion
into MjpegEncoder. This will allow us to be able to use the
additional pixel formats from libjpeg-turbo when available.
---
server/mjpeg_encoder.c | 102
server/mjpeg_encoder.h |
It takes a lot of arguments, "id" is unused, "frame" and
"frame_size" can be obtained from the "stream" argument, so
can get rid of 3 arguments to make things more readable.
---
server/red_worker.c | 16 ++--
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/server/red_
When encoding a frame, red_worker passes an allocated buffer to
libjpeg where it should encode the frame. When it fails, a new
bigger buffer is allocated and the encoding is restarted from
scratch. However, it's possible to use libjpeg to realloc this
buffer if it gets too small during the encoding
When encoding to mjpeg, the on screen data have to be converted
to 24bpp RGB since that's the format that libjpeg expects. Factor
as much code as possible for the 3 formats we handle.
---
server/red_worker.c | 171 +++
1 files changed, 50 insertions
red_worker was using some share/unshare stream_buf functions whose
body is empty. This commit removes them and their use.
---
server/red_worker.c | 12
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index bee86b9..577dee2 10
Hi,
Currently, the mjpeg encoder has to preprocess the images it gets from
spice-server to make sure the pixel order is the one libjpeg expects (RGB).
This means iterating over the whole images swapping pixels since the input
images are BGR or BGRX.
However, libjpeg-turbo, in addition to SIMD opti
On Tue, Jun 28, 2011 at 10:19:28AM +0300, yhalperi wrote:
> On 06/23/2011 09:13 PM, Alon Levy wrote:
> Hi,
> >+static _inline void async_io(PDev *pdev, PUCHAR async, PUCHAR sync, UCHAR
> >val)
> Instead of two parameters, one for async and one for sync, I prefer
> one parameter - an enum for the a
On Tue, Jun 28, 2011 at 12:26:18PM +0200, Alon Levy wrote:
> I'm going along with suggestion 3+, where spice-common is a submodule,
> not a library.
Which doesn't prevent us from making it a library later on.
Christophe
pgpUT2PIv8Ljy.pgp
Description: PGP signature
__
On Thu, Jun 23, 2011 at 04:25:34PM +0300, Uri Lublin wrote:
> On 06/23/2011 02:10 PM, Alon Levy wrote:
> >On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
> >>On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
> >>>Hi All,
> >>
> >
> >Ok, so take three:
> >
> > (1) spice-protocol
hi
- Original Message -
> On 06/28/2011 01:55 AM, Marc-André Lureau wrote:
> > Although not really important, the previous code was racy (stat +
> > exec).
>
> What seems to be the problem with it ?
There is time between stat() and exec(), you can only reliably do exec() only.
But well,
On Tue, Jun 28, 2011 at 3:24 PM, Christophe Fergeau wrote:
> On Tue, Jun 28, 2011 at 01:20:52AM +0800, Liang Guo wrote:
>>
>> I found the root of this problem, spicec is linked with -lCEGUIBase,
>> and /usr/lib/libCEGUIBASE.la have
>>
>> dependency_libs=' /usr/lib/libfreetype.la -lz -lpcre -lfreei
On 06/22/2011 11:46 AM, Gerd Hoffmann wrote:
Hi,
Add wrapper functions for all spice worker calls.
Signed-off-by: Gerd Hoffmann
---
hw/qxl-render.c|4 +-
hw/qxl.c | 32 +-
ui/spice-display.c | 94 ---
ui/
On 06/28/2011 11:14 AM, John A. Sullivan III wrote:
On Tue, 2011-06-28 at 09:30 +0200, David Jaša wrote:
Dne 28.6.2011 00:39, John A. Sullivan III napsal(a):
On Tue, 2011-06-28 at 00:14 +0200, David Jaša wrote:
Dne 27.6.2011 20:45, John A. Sullivan III napsal(a):
On Mon, 2011-06-27 at 08:32 +
On Tue, 2011-06-28 at 09:30 +0200, David Jaša wrote:
> Dne 28.6.2011 00:39, John A. Sullivan III napsal(a):
> > On Tue, 2011-06-28 at 00:14 +0200, David Jaša wrote:
> >> Dne 27.6.2011 20:45, John A. Sullivan III napsal(a):
> >>> On Mon, 2011-06-27 at 08:32 +0300, Yaniv Kaul wrote:
> Licensing
Dne 28.6.2011 00:39, John A. Sullivan III napsal(a):
> On Tue, 2011-06-28 at 00:14 +0200, David Jaša wrote:
>> Dne 27.6.2011 20:45, John A. Sullivan III napsal(a):
>>> On Mon, 2011-06-27 at 08:32 +0300, Yaniv Kaul wrote:
Licensing and patent concerns of x264 aside (see
http://mailman.vide
On Tue, Jun 28, 2011 at 01:20:52AM +0800, Liang Guo wrote:
>
> I found the root of this problem, spicec is linked with -lCEGUIBase,
> and /usr/lib/libCEGUIBASE.la have
>
> dependency_libs=' /usr/lib/libfreetype.la -lz -lpcre -lfreeimage -lGLU -lGL'
>
Rereading your email, isn't something bad goi
On 06/28/2011 01:55 AM, Marc-André Lureau wrote:
Although not really important, the previous code was racy (stat + exec).
What seems to be the problem with it ?
I propose running /usr/libexec/spice-xpi-client without parameters,
which could be a shell script with the required arguments to ca
On 06/23/2011 09:13 PM, Alon Levy wrote:
Hi,
+static _inline void async_io(PDev *pdev, PUCHAR async, PUCHAR sync, UCHAR val)
Instead of two parameters, one for async and one for sync, I prefer one
parameter - an enum for the action, and then async_io can choose the
right port.
+{
+if (pdev
26 matches
Mail list logo
