Hi,
On 08/21/2012 02:17 PM, Marc-André Lureau wrote:
On Wed, Aug 15, 2012 at 9:56 AM, Yonit Halperin wrote:
SpiceMsgWaitForChannels is not packed. Comparing the original
msg size to SpiceMsgWaitForChannels is wrong.
---
gtk/channel-base.c |3 ---
1 files changed, 0 insertions(+), 3
On 08/21/2012 02:24 PM, Marc-André Lureau wrote:
On Wed, Aug 15, 2012 at 9:56 AM, Yonit Halperin wrote:
message. All the other pending msgs will be sent later to the
destination server (see next patch).
If it breaks current semi-seamless or older migration methods, it
would be better to
ry private session members instead of session properties.
copy enable-usbredir flag to the migration session
new:don't attach migration temporary spice channel to smartcard devices.
Yonit Halperin (8):
channel-base: remove bad check of SpiceMsgWaitForChannels validity
chann
SpiceMsgWaitForChannels is not packed. Comparing the original
msg size to SpiceMsgWaitForChannels is wrong.
---
gtk/channel-base.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/gtk/channel-base.c b/gtk/channel-base.c
index cc4d242..2968f42 100644
--- a/gtk/channel-base
---
gtk/channel-main.c | 12
spice-common |2 +-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/gtk/channel-main.c b/gtk/channel-main.c
index 0c15dfa..91c9167 100644
--- a/gtk/channel-main.c
+++ b/gtk/channel-main.c
@@ -163,6 +163,7 @@ static void
spice_m
Update channel-main as well to support the change made to
SpiceMsgMainMigrationBegin: it now holds all the destination fields
inside SpiceMigrationDstInfo.
---
gtk/channel-main.c |6 +++---
spice-common |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gtk/channel
Flow:
(1) *src* main channel coroutine (main_handle_migrate_begin_seamless):
handles SPICE_MSG_MAIN_MIGRATE_BEGIN_SEAMLESS; yields to the main loop,
supplying it the destination information needed for connection.
(2) main context (migrate_connect):
Establishes a new session for connecti
In order to save migration time, and probably also decrease migration
data size, we push the flush mark to the src server before any other
message. All the other pending msgs will be sent later to the
destination server (see next patch).
---
gtk/channel-base.c | 12
1 files changed,
When swapping the src and dest channels's, we need to keep
the xmit_queue and msg serials. Their state is expected to stay the same
after migration.
---
gtk/channel-main.c |4 +++-
gtk/spice-channel-priv.h |2 +-
gtk/spice-channel.c | 12 +++-
gtk/spice-session-priv.h
Otherwise, we will not create smartcard/usb channel on the destination
side, and we will create audio channels, no matter if they existed
of didn't exist for the src side.
---
gtk/spice-channel.c | 12 +++-
gtk/spice-session.c |3 +++
gtk/usb-device-manager.c |4 +---
3
During migration, the smartcard channel that belongs to the temporary
copied session shouldn't be active.
---
gtk/channel-main.c |1 +
gtk/channel-smartcard.c | 55 ++
gtk/spice-session-priv.h |1 +
3 files changed, 38 insertions(+), 19
snd_channel_put freed "channel", and then channel->worker was accessed.
It caused segmentation faults during connections and disconnections of the
client.
---
server/snd_worker.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/snd_worker.c b/server/snd_worker.c
On 10/11/2012 08:58 PM, Marc-André Lureau wrote:
- Mensaje original -
snd_channel_put freed "channel", and then channel->worker was
accessed.
do you mean "channel->worker" is freed instead, (since other channel member are
accessed)?
I meant that "channel" is freed, and then there i
fix: rhbz#866929
At migration destination side, we need to restore the client's surfaces
state, before sending surfaces related messages.
Before this patch, we stopped the processing of only the cmd ring, till
migration data
arrived.
However, some QXL_IOs require reading and rendering the cmd rin
We no longer process destroy_primary or destroy_surfaces while waiting
for migration data.
---
server/red_worker.c | 51 ---
1 files changed, 16 insertions(+), 35 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index dd27872..4
The erroneous call was in handle_dev_start.
This patch also fixes not calling set_client_capabilities when the
qxl major_version is > 3.
---
server/red_worker.c | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
inde
Hi,
On 11/07/2012 10:25 AM, Uri Lublin wrote:
On 11/05/2012 11:33 PM, Yonit Halperin wrote:
fix: rhbz#866929
At migration destination side, we need to restore the client's surfaces
state, before sending surfaces related messages.
Before this patch, we stopped the processing of only th
Hi,
This series of patches includes fixes that are mostly related to migration.
Regards,
Yonit.
Yonit Halperin (7):
char_device.c: add ref count for write-to-device buffers
char_device.c: when the state is destroyed, also free the buffer that
is being written to the device
reds.c: fix
The ref count is used in order to keep buffers that were in the write
queue and now are part of migration data, in case the char_device state
is destroyed before we complete sending the migration data.
---
server/char_device.c | 51 +--
server/char_d
---
server/char_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/server/char_device.c b/server/char_device.c
index 1c48719..5231bf0 100644
--- a/server/char_device.c
+++ b/server/char_device.c
@@ -688,6 +688,9 @@ void spice_char_device_state_destroy(SpiceCharDeviceState
*char_dev)
fix calling spice_marhsaller_add_ref with memory on stack
---
server/red_worker.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 18ac949..092d45c 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -8433,7 +
The current solution just copy the buffer. Currently data that is read
from the guest is always copied before sending it to the client. When we
will have ref count for these buffers, we can also use it for marshalling
the migration data.
---
server/smartcard.c | 2 +-
1 file changed, 1 insertion(+
red_wait_outgoing_item only waits till the currently outgoing msg is
completely sent.
red_wait_outgoing_items does the same for multi-clients. handle_dev_stop
erroneously called
red_wait_outgoing_items, instead of waiting till all the items in the
pipes are sent.
This waiting is necessary because
Previously, there was no check for the size of the message received from
the client, and all messages were read into a buffer of size 1024.
However, migration data can be bigger than 1024. In such cases, memory
corruption occurred.
---
server/red_worker.c | 12
1 file changed, 12 inse
rhbz#862352
---
server/char_device.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/server/char_device.c b/server/char_device.c
index ac2632d..141ec88 100644
--- a/server/char_device.c
+++ b/server/char_device.c
@@ -816,12 +816,14 @@ void spice_char_device_wakeu
---
server/reds.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 98c8706..b99d01f 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1171,16 +1171,20 @@ void reds_marshall_migrate_data(SpiceMarshaller *m)
spic
On 11/22/2012 04:58 AM, Hans de Goede wrote:
Hi,
Looks good, one minor comment though, see
my remarks inline.
I'll fix it. Thanks for the review.
On 11/21/2012 08:42 PM, Yonit Halperin wrote:
The ref count is used in order to keep buffers that were in the write
queue and now are pa
rhbz#876685
The current lz implementation does not support such bitmaps.
The following patch will actually prevent allocating stride > bpp*width
for internal images.
---
server/red_worker.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/server/red
---
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 9bab003..8f7f45a 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -5065,7 +5065,7 @@ static ImageItem
*red_add_surface_area_image(DisplayChannel
On 11/28/2012 05:54 PM, Alon Levy wrote:
Why is there no need to align the stride of internal images? what happens if we
keep this alignment? Please add the answers to the patch log message.
Why do you think there may be a need? those images are just read from
the surface, compressed, and sent
The server can receive from the client agent data even when the agent
is disconnected. This can happen if the client sends the agent data
before it receives the AGENT_DISCONNECTED msg. We should receive and handle
such msgs, instead
of disconnecting the client.
This bug can also lead to a server c
red_proccess_commands calls were added after calling
guest_set_client_capabilities in order to cleanup the command ring from
old commands that the client might not be able to handle.
However, calling red_process_commands at this stage does send messages
to the client.
In addition, since setting the
Non rgb bitmaps are allowed to not have a palette in case they
are masks (which are 1BIT bitmaps).
Related: rhbz#864982
---
server/red_parse_qxl.c | 27 +--
server/red_worker.c|8 +++-
2 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/server/re
On 12/13/2012 06:42 AM, Alon Levy wrote:
All looks good except the assert. We should be removing them whenever they are
guest trigerable - maybe I'm not following the code, but if in red_get_image
sees no pallete in the qxl struct then palette will be NULL, which means it's
guest trigerable.
resolves: rhbz#891326
Starting from commit 81fe00b08ad4f, red_detach_streams_behind can
trigger modifications in the current tree (by update_area calls). Thus,
after calling red_detach_streams_behind it is not safe to access tree
entries that were calculated before the call.
This patch inserts the
The stream vis_region should be cleared after the stream region was sent
to the client losslessly. Otherwise, we might send redundant stream upgrades
if we process more drawables that are dependent on the stream region.
---
server/red_worker.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletion
Hi,
On 01/17/2013 09:26 AM, Uri Lublin wrote:
Resolves: rhbz#883578
Call qxl_allocate_monitors_config upon memory-remap such
that qxl->monitors_config points to the start of
monitors_config segment in qxl RAM memory.
Currently after memory remap, it's possible that monitors_config
memory and vi
On 01/21/2013 09:28 AM, Uri Lublin wrote:
On 01/21/2013 04:16 PM, Yonit Halperin wrote:
On 01/17/2013 09:26 AM, Uri Lublin wrote:
Resolves: rhbz#883578
Call qxl_allocate_monitors_config upon memory-remap such
that qxl->monitors_config points to the start of
monitors_config segment in qxl
Hi,
On 01/24/2013 08:23 AM, javaon wrote:
Thanks for replying, Alon.
Yes, I found that 3d rendering in software. But.. is there any method to
improve the response speed of Fedora GNOME desktop? You know, Windows
XP/7 guest's speed is really pretty fast!
Thanks.
You can try disabling off scree
Fixes: fedora 875348, 826036
When an image is not rendered, we still need to check if it contains
a palette that needs to be cached.
This bug caused the client to crash due to not finding palettes
in the cache.
---
common/canvas_base.c | 19 ++-
1 file changed, 18 insertions(+), 1
ront-end.
- Add vp8 encoding
- Solve some problems we have with video identification.
- Try to achieve faster convergence to the "right" bit-rate when we start with
a wrong estimation.
long-term TODO:
---
video pass-through
Regards,
Yonit.
Yonit Halperin (28):
red_wor
Frames counting was skipped when the previous frame was already
sent completely to the client.
---
server/red_worker.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 11fa126..a4a369a 100644
--- a/server/red_work
The mjpeg_encoder should be client specific, and not shared between
different clients**, for the following reasons:
(1) Since we use abbreviated jpeg datastream for mjpeg, employing the same
mjpeg_encoder for different clients might cause errors when the
clients decode the jpeg data.
(2) Th
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 rate and the size of the first encoded frames.
The following patches will introduce an adaptive video streaming
If the encoding size seems to get smaller/bigger, re-evaluate the
stream quality and frame rate.
---
server/mjpeg_encoder.c | 147 ++---
1 file changed, 139 insertions(+), 8 deletions(-)
diff --git a/server/mjpeg_encoder.c b/server/mjpeg_encoder.c
index
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 on the report.
When the bit rate is changed, the quality and frame rate of the stream
are re-evaluated.
---
s
Downgrading stream bit rate when the input frame rate in the server
exceeds the output frame rate, and frames are being dropped from the
output pipe.
---
server/mjpeg_encoder.c | 103 ++---
server/mjpeg_encoder.h | 10 +
2 files changed, 91 insertio
The required client playback latency is assessed based on the current
estimation of the bit rate, the network latency, and the encoding size
of the frames. When the playback delay that is reported by the client
seems too small, or when the stream parameters change, we send the
client an updated pla
---
server/mjpeg_encoder.c | 20 +---
server/mjpeg_encoder.h | 21 ++---
server/red_worker.c| 21 -
3 files changed, 39 insertions(+), 23 deletions(-)
diff --git a/server/mjpeg_encoder.c b/server/mjpeg_encoder.c
index 70b6338..c124286 100644
The actual frames distribution does not necessarily fit the
condition "at least one frame every (1000/rate_contorl->fps)
milliseconds".
For keeping the average frame rate close to the defined fps, we
periodically measure the current average fps, and modify
rate_control->adjusted_fps accordingly. Th
The stream starts after lossless frames were sent to the client,
and without rate control (except for pipe congestion). Thus, on the beginning
of the stream, we might observe frame drops on the client and server side which
are not necessarily related to mis-estimation of the bit rate, and we would
Each thread can create a spice_timer_queue, for managing its
own timers.
---
server/Makefile.am | 2 +
server/spice_timer_queue.c | 268 +
server/spice_timer_queue.h | 43
3 files changed, 313 insertions(+)
create mode 100644 server/
display channel - supplying timeouts interface to red_channel, in order to allow
periodic latency monitoring (see next patch).
---
server/red_worker.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/server/red_worker.c b/server/red_worker.c
index a390629..cb695fe 100644
--- a/s
---
server/inputs_channel.c | 1 +
server/main_channel.c | 2 +-
server/red_channel.c| 228
server/red_channel.h| 18
server/red_worker.c | 2 +-
server/smartcard.c | 1 +
server/spicevmc.c | 1 +
7 files cha
---
server/red_worker.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 82f2fc9..5043c10 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -10116,6 +10116,7 @@ static CommonChannelClient
*common_channel_client_cre
Periodically calculate the rate of frames arriving from the guest to the
server.
---
server/red_worker.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index c992688..82f2fc9 100644
--- a/server/red
This patch only employs setting the stream parameters based on
the initial given bit-rate, the latency, and the encoding size.
Later patches will also employ mjpeg_encoder response to client reports,
and its control over frame drops.
The patch also removes old stream bit rate calculations that wer
update mjpeg_encoder with reports from the client about
the playback quality.
---
server/red_dispatcher.c | 1 +
server/red_worker.c | 86 +++--
2 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/server/red_dispatcher.c b/server/red_dis
---
server/red_worker.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index 23f9ca5..ff26f84 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -3169,13 +3169,19 @@ static inline void pre_stream_item_swap
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 b/serve
---
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 MAIN_DISPATCH
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
+++ b/server
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 buffe
---
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 @@
#include
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
--- a/server/red_
---
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
+++ b/ser
---
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 RED_STR
---
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
red_marshall_stream_data(Re
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 clien
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 clien
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 fil
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 deletions(-
---
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 s
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 ins
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. Then,
---
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 dc89e2d..aa33d2c
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 of
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 rate
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 it
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 triggere
Hi,
On 03/03/2013 07:50 AM, Andrew Cathrow wrote:
- Original Message -
From: "Yonit Halperin"
To: spice-de...@freedesktop.org
Sent: Tuesday, February 26, 2013 1:03:46 PM
Subject: [Spice-devel] [PATCH spice-server 00/28] adaptive video streaming
Hi,
The following pa
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/10/2013 08:39 PM, Yonit Halperin wrote:
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
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 .
But as I went
Hi,
Sounds good. see my comments inline.
On 03/27/2013 04: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
Comments appreciated, especially regarding eviction policy, wh
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 I
On 03/28/2013 01:19 AM, Dave Airlie wrote:
Can you please explain how all this relates to Dave's work on the KMS? He
mentioned that he implemented paging there as well.
Well we won't be using the KMS driver in RHEL6, so we need to improve
the old UMS driver for that use case.
Though I expect
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.
Signed-o
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
+++ b/common
Ack
On 04/05/2013 09:55 AM, Hans de Goede wrote:
If no volume has been set it, we end up sending a volume message with
audio-volume for 0 channels (iow an empty message). This is not useful
and triggers the following warning in spice-gtk:
(remote-viewer:8726): GSpice-WARNING **: set_sink_input_
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 sen
Previously, when an error occurred on the src server side, and we
received other message than MIGRATE_DATA, this messages was forwarded
to the dest server, and made it crash.
---
gtk/channel-base.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gtk/channel-base.c b/gtk/c
701 - 800 of 941 matches
Mail list logo
