A frame can be dropped if a new frame was added during the same
call to red_process_command (we didn't attempt to send the older
frame). Such drops are ignored.
---
server/red_worker.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/server/red_worker.c
---
server/dispatcher.h | 6 +++---
server/main_dispatcher.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/server/dispatcher.h b/server/dispatcher.h
index a468c58..1b389bd 100644
--- a/server/dispatcher.h
+++ b/server/dispatcher.h
@@ -1,5 +1,5 @@
-#ifndef
also update spice-common submodule
---
server/snd_worker.c | 45 +
server/snd_worker.h | 2 ++
2 files changed, 47 insertions(+)
diff --git a/server/snd_worker.c b/server/snd_worker.c
index bc7be51..9353e82 100644
--- a/server/snd_worker.c
+++
When there is no audio playback, we set the mm_time in the client to be older
than the one in the server by at least the requested latency (the delta is
actually bigger, due to the network latency).
When there is an audio playback, we adjust the mm_time in the client by
adjusting the playback
---
server/red_worker.c | 56 -
1 file changed, 51 insertions(+), 5 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 46dd069..acf391d 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -81,6 +81,7 @@
mjpeg_encoder modify the initial bit we supply it, according to the
client feedback. If it reaches a bit rate which is higher than the
initial one, we use the higher bit rate as the new bit rate estimation.
---
server/mjpeg_encoder.c | 5 +
server/mjpeg_encoder.h | 2 ++
server/red_worker.c
SPICE_BIT_RATE can be set for supplying red_worker the available
bandwidth (in Mbps).
---
server/red_worker.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 954b950..deb375c 100644
---
---
server/mjpeg_encoder.c | 7 +
server/red_worker.c| 69 +-
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/server/mjpeg_encoder.c b/server/mjpeg_encoder.c
index 7825955..b5faed6 100644
--- a/server/mjpeg_encoder.c
+++
---
server/red_worker.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 2cb9f62..81b86de 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -110,7 +110,7 @@
#define DISPLAY_FREE_LIST_DEFAULT_SIZE 128
#define
---
server/red_worker.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 81b86de..f341b15 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -8565,6 +8565,7 @@ static inline int
If the server client support SPICE_DISPLAY_CAP_STREAM_REPORT,
the server first sends SPICE_MSG_DISPLAY_STREAM_ACTIVATE_REPORT. Then,
the client periodically sends SPICE_MSGC_DISPLAY_STREAM_REPORT
messages that supply the server details about the current quality of
the video streaming on the
SPICE_MSG_PLAYBACK_LATENCY is intended for adjusting the latency
of the audio playback. It is used for synchronizing the audio and video
playback.
The corresponding capability is SPICE_PLAYBACK_CAP_LATENCY.
---
spice/enums.h| 1 +
spice/protocol.h | 1 +
2 files changed, 2 insertions(+)
diff
If the server client support SPICE_DISPLAY_CAP_STREAM_REPORT,
the server first sends SPICE_MSG_DISPLAY_STREAM_ACTIVATE_REPORT. Then,
the client periodically sends SPICE_MSGC_DISPLAY_STREAM_REPORT
messages that supply the server details about the current quality of
the video streaming on the
SPICE_MSG_PLAYBACK_LATENCY is intended for adjusting the
latency of the audio playback. It is used for synchronizing
the audio and video playback.
The corresponding capability is SPICE_PLAYBACK_CAP_LATENCY.
---
common/messages.h | 4
spice-protocol| 2 +-
spice.proto | 4
3
also prints the number of underflows during a spice-pulse audio playback
---
gtk/channel-display-priv.h | 17
gtk/channel-display.c | 50 --
gtk/spice-pulse.c | 9 -
3 files changed, 73 insertions(+), 3
---
gtk/spice-pulse.c | 69 +--
1 file changed, 26 insertions(+), 43 deletions(-)
diff --git a/gtk/spice-pulse.c b/gtk/spice-pulse.c
index 295ea4f..107ce7c 100644
--- a/gtk/spice-pulse.c
+++ b/gtk/spice-pulse.c
@@ -275,6 +275,30 @@ static void
Support checking whether an audio playback is active and what its latency
is.
---
gtk/Makefile.am | 1 +
gtk/channel-playback-priv.h | 23 +++
gtk/channel-playback.c | 24
gtk/spice-session-priv.h| 3 +++
gtk/spice-session.c
handle MSG_STREAM_ACTIVIATE_REPORT and send MSGC_STREAM_REPORT
periodically, or when the playback is out of sync.
---
gtk/channel-display-priv.h | 10
gtk/channel-display.c | 116 -
spice-common | 2 +-
3 files changed, 114
Add a new property for minimum playback latency. This property is
updated with the value from SPICE_MSG_PLAYBACK_LATENCY.
I also increased the default latency from 100ms to 200ms in order to
be more robust to different bandwidth settings.
---
gtk/channel-playback.c | 31
If the current latency is smaller than the new min-latency
value, we cork the playback till the target latency is achieved.
Note: I didn't modify the prebuf configuration and used
pa_stream_prebuf, because pulse updated the prebuf only if
I set both prebuf and tlength to be target_latency*2.
---
gtk/channel-playback-priv.h | 1 +
gtk/channel-playback.c | 9 +
gtk/spice-session-priv.h| 1 +
gtk/spice-session.c | 15 +++
4 files changed, 26 insertions(+)
diff --git a/gtk/channel-playback-priv.h b/gtk/channel-playback-priv.h
index
This was added in order to respond more quickly when the audio and video
playback are
not synchronized, and when the latency between the client and the server
is high (i.e., when the server response to the status is delayed).
---
gtk/channel-display-priv.h | 2 ++
gtk/channel-display.c | 9
Hi,
The detailed results file is attached.
Regards,
Yonit.
On 02/26/2013 01:03 PM, Yonit Halperin wrote:
Hi,
The following patch series introduces adaptive video streaming to spice.
Until now, the mjpeg quality was constant (70), and the frame rate was modified
according to the rate
Hi,
On 02/26/2013 01:40 PM, Marc-André Lureau wrote:
Hi
- Mensaje original -
The adaptive video streaming is implemented by the following
heuristic:
Given a bit rate, we calculate the best combination of mjpeg quality
and frame rate (henceforth, the stream parameters) for this
bit
Hi,
On 02/04/2013 06:27 AM, Rob Verduijn wrote:
Hello,
I'm not sure if this is the right mailinglist for my question so
please forgive me and direct me to the proper one if its not.
I've installed the latest spice releases on opensuse and everything is
working fine. (usbredir, qxl etc)
I use
On 02/26/2013 02:49 PM, Marc-André Lureau wrote:
- Mensaje original -
Hi,
On 02/26/2013 01:40 PM, Marc-André Lureau wrote:
Hi
- Mensaje original -
The adaptive video streaming is implemented by the following
heuristic:
Given a bit rate, we calculate the best combination of
On 02/27/2013 09:30 AM, Hans de Goede wrote:
Hi,
On 02/27/2013 03:01 PM, Yonit Halperin wrote:
On 02/26/2013 02:49 PM, Marc-André Lureau wrote:
- Mensaje original -
Hi,
On 02/26/2013 01:40 PM, Marc-André Lureau wrote:
Hi
- Mensaje original -
The adaptive video streaming
Hi,
On 02/28/2013 10:14 AM, David Jaša wrote:
Hi,
this email is a wrap-up of in-person discussion with Hans about bug:
https://bugzilla.redhat.com/show_bug.cgi?id=884631
The problem is that if client tries to connect to destination host when
VM is already migrating. The problem can be
On 03/10/2013 06:50 AM, Alon Levy wrote:
On Tue, Feb 26, 2013 at 01:03:51PM -0500, Yonit Halperin wrote:
mjpeg_encoder can receive periodic reports about the playback status on
the client side. Then, mjpeg_encoder analyses the report and can
increase or decrease the stream bit rate, depending
Hi,
On 03/26/2013 01:36 PM, Jeremy White wrote:
I thought it would be lovely if I could make my deferred_fps stuff
available to users of qemu. I think it is a helpful change for people
with bandwidth constraints.
And, of course, it'd be nice if I weren't the only one using it grin.
But as I
Hi,
On 03/27/2013 06:17 AM, Hans de Goede wrote:
Hi,
On 03/27/2013 09:07 AM, Søren Sandmann wrote:
Hello,
The following is some notes on what I am planning to do for UMS memory
management. It basically amounts to a rewrite of qxl-surface-ums.c
Looks / sounds good, a few remarks below (note
On 03/27/2013 10:28 AM, Alon Levy wrote:
Hi,
On 03/27/2013 06:17 AM, Hans de Goede wrote:
Hi,
On 03/27/2013 09:07 AM, Søren Sandmann wrote:
Hello,
The following is some notes on what I am planning to do for UMS
memory
management. It basically amounts to a rewrite of qxl-surface-ums.c
Looks
Ack series
On 03/29/2013 05:11 AM, Hans de Goede wrote:
Before this patch the write-loop in spice_char_device_write_to_device would
break on running becoming 0, after having written some data, without updating
the buffer status, causing the same data to be written *again* when started.
region_bounds_intersects mistakingly ignored one of the input regions,
and compared the other region to itself.
---
common/region.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/region.c b/common/region.c
index cd9ade0..14a27ed 100644
--- a/common/region.c
+++
When qemu migration completes, we need to stop the streams, and to send
the corresponding upgrade_items to the client.
Otherwise, (1) the client might display lossy regions that we don't track
(streams are not part of the migration data).
(2) streams_timeout may occur after MSG_MIGRATE has been
On 04/14/2013 09:14 AM, Alon Levy wrote:
On Tue, Feb 26, 2013 at 01:03:49PM -0500, Yonit Halperin wrote:
Previously, the mjpeg quality was always 70. The frame rate was
tuned according to the frames' congestion in the pipe.
This patch sets the quality and frame rate according to
a given bit
On 04/14/2013 09:21 AM, Alon Levy wrote:
On Tue, Feb 26, 2013 at 01:03:54PM -0500, Yonit Halperin wrote:
ACK with one comment.
---
server/mjpeg_encoder.c | 20 +---
server/mjpeg_encoder.h | 21 ++---
server/red_worker.c| 21 -
3
On 04/14/2013 09:24 AM, Alon Levy wrote:
On Tue, Feb 26, 2013 at 01:03:57PM -0500, Yonit Halperin wrote:
Each thread can create a spice_timer_queue, for managing its
own timers.
ACK.
nitpick: why ms and not nano?
Because of SpiceCoreInterface (see the following patch).
---
server
On 04/14/2013 09:28 AM, Alon Levy wrote:
On Tue, Feb 26, 2013 at 01:03:59PM -0500, Yonit Halperin wrote:
ACK.
just a note: maybe we should not send our time, but an id, to not leak
information?
Sending the time is not necessary. Just kept it in order to be
compatible with the way we used
Hi,
On 04/14/2013 09:37 AM, Alon Levy wrote:
On Tue, Feb 26, 2013 at 01:03:46PM -0500, Yonit Halperin wrote:
ACK series, sorry for the delay. I have to admit I don't understand the
first patches as well as I should, but seeing as they have been tested
and that I would just be delaying them
Hi,
can you attach the full stack trace?
Is it reproducible? Do you perform any actions in the guest for
reproducing it?
I tried it with win7 guest and upstream/master qemu and spice, and
couldn't reproduce it.
Cheers,
Yonit.
On 04/01/2013 04:50 AM, Liuji (Jeremy) wrote:
Hello, everyone
I
Ack
On 04/19/2013 08:01 AM, Hans de Goede wrote:
My commit 71315b2e snd_worker: Don't send empty audio-volume messages,
fixes only one case of sending an empty volume message, if the client connects
to a vm early during its boot sequence, while the snd hardware is being reset
by the guest
Hi,
Good Catch!
Actually, the bandwidth is not getting evaluated after migration .
I think it is better, if we replace
display_channel_client_is_low_bandwidth with a boolean in the display
channel client that will be set once, when the channel is created (by
calling
, it will probably lead
to another assert...)
On 04/25/2013 10:02 AM, Yonit Halperin wrote:
Hi,
Good Catch!
Actually, the bandwidth is not getting evaluated after migration .
I think it is better, if we replace
display_channel_client_is_low_bandwidth with a boolean in the display
channel client
the migration data wrongly. The warning comes after the
fact, it's already too late.
On 04/25/2013 10:02 AM, Yonit Halperin wrote:
Hi,
Good Catch!
Actually, the bandwidth is not getting evaluated after migration .
I think it is better, if we replace
display_channel_client_is_low_bandwidth
, these options require that both spice-gtk and spice-client will be
new (
though (2) doesn't require protocol changes).
For video streams without audio, I will also send a patch that sends
SPICE_MSG_MAIN_MULTI_MEDIA_TIME after migration
(unless solution (1) above is chosen).
Comments?
Yonit.
Yonit Halperin
rhbz#951664
When the src and dst server have different mm-times, we can
hit a case when for a short period of time the session mm-time and
the video mm-time are not synced. If the video mm-time is much
bigger than the session mm-time, the next stream rendering will be
scheduled to (video-mm-time
will send a patch for
spice-server to send the MM_TIME after migration, but there will still
be a race between the display channel and main channel.
On Tue, Apr 30, 2013 at 12:19 AM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
rhbz#951664
When the src and dst
mm-time can change after migration. This can cause video synchronization
problems after migration if not handled appropriately (see rhbz#951664).
---
gtk/spice-session.c | 29 +
gtk/spice-session.h | 3 ++-
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git
rhbz#951664
When the src and dst servers have different mm-times, we can
hit a case when for a short period of time the session mm-time and
the video mm-time are not synced. If the video mm-time is much
bigger than the session mm-time, the next stream rendering will be
scheduled to (video-mm-time
When a client disconnects, red_channel_client_pipe_clear is called.
Releasing pipe items of type == MIGRATE||EMPTY_MSG||PING
wasn't handled, and was passed to channel_cbs.release_item.
There, an error occured since the pipe items were not recognized.
---
server/red_channel.c | 3 +++
1 file
mm-time can change after migration. This can cause video synchronization
problems after migration if not handled appropriately (see rhbz#951664).
---
gtk/spice-session.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/gtk/spice-session.c
rhbz#951664
When the src and dst servers have different mm-times, we can
hit a case when for a short period of time the session mm-time and
the video mm-time are not synced. If the video mm-time is much
bigger than the session mm-time, the next stream rendering will be
scheduled to (video-mm-time
We mustn't send any msg to the client, besides MSG_MIGRATE_DATA, after
we send MSG_MIGRATE.
---
server/red_channel.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/server/red_channel.c b/server/red_channel.c
index 9047762..4e03d64 100644
--- a/server/red_channel.c
+++
The connection to the target server is established before migration
starts. However, the client reads and replies to messages from the server only
after
migration completes. Thus, we better not send ping msgs from the target
before migration completes (because the observed roundtrip duration will
the
fact, it's already too late.
On 04/25/2013 10:02 AM, Yonit Halperin wrote:
Hi,
Good Catch!
Actually, the bandwidth is not getting evaluated after migration .
I think it is better, if we replace
display_channel_client_is_low_bandwidth with a boolean in the display
channel client that will be set
---
server/main_channel.c | 10 +-
server/main_channel.h | 6 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/server/main_channel.c b/server/main_channel.c
index dd927ab..4cf7e19 100644
--- a/server/main_channel.c
+++ b/server/main_channel.c
@@ -164,6 +164,7 @@ enum
Replace the mixed calls to display_channel_client_is_low_bandwidth
and to main_channel_client_is_low_bandwidth, with one flag in
CommonChannelClient that is set upon channel creation.
---
server/red_worker.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
rhbz#956345
After a spice session has been migrated, we don't retest the network
(user experience considerations). Instead, we obtain the is_low_bandwidth flag
from the src-server, via the migration data.
Before this patch, if we migrated from server s1 to s2 and then to s3,
and if the connection
---
server/main_dispatcher.c | 5 +
server/reds.c| 19 ++-
server/reds.h| 4
3 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/server/main_dispatcher.c b/server/main_dispatcher.c
index 8402402..92b0791 100644
---
---
server/reds.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index a378f80..f6a1ce9 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -196,10 +196,9 @@ static void reds_stream_push_channel_event(RedsStream *s,
int event)
void
---
server/reds.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/server/reds.c b/server/reds.c
index f6a1ce9..38923b0 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -194,12 +194,37 @@ static void reds_stream_push_channel_event(RedsStream *s,
int event)
---
server/red_channel.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 9d71543..7fde50d 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -1680,6 +1680,7 @@ static void
spice_channel_client_error prints warning and shutdowns the
channel_client that hit the error.
This macro is useful for errors that are specific for one session
and that are unrecoverable only with respect to this session.
Prefer disconnecting a client over aborting when possible.
---
---
server/red_channel.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 7fde50d..b738a80 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -1275,14 +1275,17 @@ static void
already connected,
I don't think they should be disconnected independently.
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
---
server/reds.c | 25 +
1 file changed, 25 insertions(+)
diff --git
by itself.
On Wed, May 8, 2013 at 4:06 PM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
---
server/main_dispatcher.c | 5 +
server/reds.c| 19 ++-
server/reds.h| 4
3 files changed, 19 insertions(+), 9
On 05/08/2013 10:55 AM, Marc-André Lureau wrote:
On Wed, May 8, 2013 at 4:55 PM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
If these channels were already connected, I believe it is better to
close the client, than having the user don't understand why suddenly
When setting an initial video stream bit rate, if the bit rate
wasn't calculated by main_channel_client, and we don't have
estimation from previos streams, use some default values.
---
server/red_worker.c | 42 ++
1 file changed, 30 insertions(+), 12
On 05/09/2013 02:33 AM, bigclouds wrote:
many functions start with 'red', what does it mean?
thanks
That is historical. It stands for Remote Desktop.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
On 05/08/2013 07:27 PM, Yonit Halperin wrote:
When setting an initial video stream bit rate, if the bit rate
wasn't calculated by main_channel_client, and we don't have
estimation from previos streams, use some default values.
---
server/red_worker.c | 42
On 05/09/2013 10:46 AM, Marc-André Lureau wrote:
On Wed, May 1, 2013 at 4:19 PM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
mm-time can change after migration. This can cause video synchronization
problems after migration if not handled appropriately (see
On 05/09/2013 11:16 AM, Marc-André Lureau wrote:
On Thu, May 9, 2013 at 5:06 PM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
On 05/09/2013 10:46 AM, Marc-André Lureau wrote:
On Wed, May 1, 2013 at 4:19 PM, Yonit Halperin
yhalp...@redhat.com
.
Yonit Halperin (3):
emit_main_context macro: handle calls from both coroutine context and
main context
spice-session: new signal for notifying on a significant change in
mm-time
channel-display: protect video streaming from temporarily unsynced
mm_time (migration related)
gtk
---
gtk/coroutine.h | 1 +
gtk/spice-channel-priv.h | 12
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/gtk/coroutine.h b/gtk/coroutine.h
index 031a97b..a9b3a87 100644
--- a/gtk/coroutine.h
+++ b/gtk/coroutine.h
@@ -55,6 +55,7 @@ struct coroutine
#endif
mm-time can change after migration. This can cause video synchronization
problems after migration if not handled appropriately (see rhbz#951664).
---
gtk/spice-session.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/gtk/spice-session.c
rhbz#951664
When the src and dst servers have different mm-times, we can
hit a case when for a short period of time the session mm-time and
the video mm-time are not synced. If the video mm-time is much
bigger than the session mm-time, the next stream rendering will be
scheduled to (video-mm-time
(snd_send_data,
snd_receive).
thanks
在 2013-05-08 23:57:54，Marc-André Lureau marcandre.lur...@gmail.com
写道：
On Wed, May 8, 2013 at 5:03 PM, Yonit Halperin yhalp...@redhat.com
mailto:yhalp...@redhat.com wrote:
I can live with that. Maybe we should add to spice-gtk a user
If client_migrate_info was called once with cert-host-subject and
then again without cert-host-subject, on a third call to
client_migrate info, the cert-host-subject from the first call would
have been freed for the second time.
---
server/main_channel.c | 2 ++
1 file changed, 2 insertions(+)
Hi,
Video streaming support involves: (1) lossy compression of video frames
(using jpeg) (2) lip sync (3) frame rate control
Video is detected by identification of high rate updates of the same
region over the primary surface.
off=turn off video streaming support
filter=don't stream as
The assert:
spice_assert(pthread_equal(pthread_self(), client-thread_id))
and the assert:
spice_assert(pthread_equal(pthread_self(), rcc-channel-thread_id))
were coded in order to protect data that is accessed from the main
context (red_client and most of the channels), from
access by threads of
Hi,
On 06/18/2013 10:33 AM, bigclouds wrote:
hi,all
i have used spice for a long time,it is good, but in pratice it needs
improvement, like resource usage, network bandwidth,performance.
1.it eats up much cpu on client side, up to 90% when play video. i am
sure whether decompression or
rhbz#966835
We do not support copying such bitmaps. But instead of failing
operations that involve such bitmaps we either BSODed (in checked
builds), or proceeded with the bitmap copying (in free builds) - this lead to
an infinite
loop allocating QXLDataChunks without any data, just header.
---
DebugPrintV first locks print_sem, and then locks io_sem.
async_io, locks io_sem.
In ordr to avoid a deadlock, DebugPrintV MUSTN'T be called when
io_sem is locked.
Also notice, that locking io_sem during DebugPrintV limits our ability
to use the log_port for debugging concurrency problems related
Hi,
For the purpose of disabling guest desktop effects, we already have a
spice-gtk option which we use for Windows guests, and can be used for
Linux guests as well. The Linux agent should support
VD_AGENT_DISPLAY_CONFIG for this.
However, for local usage, we would also like to disable
On 06/23/2013 06:30 AM, Uri Lublin wrote:
On 06/21/2013 04:50 PM, Yonit Halperin wrote:
DebugPrintV first locks print_sem, and then locks io_sem.
async_io, locks io_sem.
In ordr to avoid a deadlock, DebugPrintV MUSTN'T be called when
io_sem is locked.
Also notice, that locking io_sem during
Those messages are too frequent and don't contribute much
---
server/red_channel.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index 5662041..c0b1781 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@
also added start/end-bit-rate and avg-quality to the final stream stats.
---
server/mjpeg_encoder.c | 1 -
server/red_worker.c| 22 +++---
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/server/mjpeg_encoder.c b/server/mjpeg_encoder.c
index 92aef27..04b244e
---
gtk/channel-display.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/gtk/channel-display.c b/gtk/channel-display.c
index bc6fc08..07f6c1e 100644
--- a/gtk/channel-display.c
+++ b/gtk/channel-display.c
@@ -1511,6 +1511,7 @@ static void
---
server/mjpeg_encoder.c | 11 +++
server/mjpeg_encoder.h | 7 +++
2 files changed, 18 insertions(+)
diff --git a/server/mjpeg_encoder.c b/server/mjpeg_encoder.c
index 4460322..92aef27 100644
--- a/server/mjpeg_encoder.c
+++ b/server/mjpeg_encoder.c
@@ -169,6 +169,7 @@ struct
spice-server supports adaptive video streaming only if the client
publishes SPICE_DISPLAY_CAP_STREAM_REPORT.
Disabling this feature is useful for debugging and performance comparison.
---
gtk/channel-display.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff
The image descriptor flags shouldn't be copied as is from the flags that
were set by the driver. Specifically, the CACHE_ME flag shouldn't be copied,
since it is possible that (a) the image won't be cached (b) the image
is already cached, but in its lossy version, and we may want to set the bit
---
NEWS | 7 +++
configure.ac | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index a602292..23b83d2 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,10 @@
+Major changes in 0.12.6
+===
+* add adaptive video streaming support:
+ control
Hi All,
I'm happy to announce a new spice-protocol release in the stable
spice-0.12.x series
Changes in spice-protocol-0.12.6
* Add adaptive video streaming support:
control playback latency and receive playback
reports from the client.
* Add agent
option for remote-viewer. You can change the
size of the cache and see if it improves the performance. Then we can
consider implementing caching on disk, and not only memory.
Cheers,
Yonit.
thanks.
At 2013-06-19 01:44:29,Yonit Halperin yhalp...@redhat.com wrote:
Hi,
On 06/18/2013 10:33 AM
Hi,
On 07/01/2013 04:27 AM, Matilde Yanez wrote:
Hello,
I need some information about video detection, on VM.
When I am on web pages, or documents, with images the VM seems to detect
video and start the mjpeg_encoder process.
Thus, the display is slows down.
What vm are you using? We
On 07/02/2013 10:22 AM, Matilde Yanez wrote:
Hi,
thanks for answers.
2013/7/2 Yonit Halperin yhalp...@redhat.com mailto:yhalp...@redhat.com
Hi,
On 07/01/2013 04:27 AM, Matilde Yanez wrote:
Hello,
I need some information about video detection, on VM.
When I
Ack. Thanks! We have recently associated this problem with some opened
bugs we have. I believe Uri is working on a patch for a similar fix to
the red_pipes.* routines in red_worker.
On 07/05/2013 03:11 AM, David Gibson wrote:
Currently, both red_channel_pipes_add_type() and
rhbz#968050
In contrast to Microsoft Msdn documentation, the iUniq of a SURFOBJ doesn't
always change when the surface changes. However, it seems that the
iUniq of the associated color_trans (XLATEOBJ) changes, while its
flXlate=XO_TRIVIAL. Since we tried to retrieve the alpha bitmap key
only by
Hi,
On 07/08/2013 06:32 AM, Uri Lublin wrote:
RCC_FOREACH may be dangerous
The following patches replace FOREACH loops with a SAFE version.
Using unsafe loops may cause spice-server to abort (assert fails).
Specifically a read/write fail in those loops, may cause the client
to disconnect,
601 - 700 of 763 matches
Mail list logo
