On Tue, Feb 26, 2013 at 01:36:23AM +0100, Marc-André Lureau wrote:
Never call vevent_get_next_vevent() before calling vcard_emul_init()
Some mutexes are initialized in vevent_queue_init(), during emul_init()
A bit more details about what's going on in spice-gtk code could be nice
(the monitor
hello:
how can i set the display resolution before connect to a desktop?
envirment:
virtualization: rhev 3.1
guest os: windows xp sp3
client: spicec 0.10.0
thanks!
--
Chang Xiaodong___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
changxiaodong píše v St 20. 02. 2013 v 12:32 +0800:
hello:
how can i set the display resolution before connect to a desktop?
no, that isn't possible. The windowed client will pick up whatever
resolution is currently used in the guest, if the client is run from
full screen, it will try to
On Mon, Feb 25, 2013 at 03:39:00PM +1000, airl...@gmail.com wrote:
From: Dave Airlie airl...@gmail.com
This makes X -retro actually render fast, as opposed to glacially slow.
Works with xspice. Didn't grok it otherwise.
Tested-by ...
Signed-off-by: Dave Airlie airl...@redhat.com
---
On Tue, Feb 26, 2013 at 02:32:03PM +1000, Dave Airlie wrote:
Hi,
Patches don't apply on top of uxa: port over tiled fill code from EXA.
Okay this is the next chunk of prep for getting KMS into the driver,
the first 8 patches are just preparation work and moving stuff around,
along with a
changxiaodong píše v St 20. 02. 2013 v 12:32 +0800:
hello:
how can i set the display resolution before connect to a desktop?
no, that isn't possible. The windowed client will pick up whatever
resolution is currently used in the guest, if the client is run from
full screen, it will try
Hey Dave,
On 02/25/2013 10:32 PM, Dave Airlie wrote:
Hi,
Okay this is the next chunk of prep for getting KMS into the driver,
the first 8 patches are just preparation work and moving stuff around,
along with a couple of minor fixes.
The big guy on the end adds the BO abstraction layer,
vdagent terminates when the global event is set by vdservice. vdservice is also
responsible to reset the event in any case, without trusting vdagent to do so.
Otherwise, it may terminate the following vdagent instance immediately as well.
Regression was due to commit 2d03cc.
rhbz #868254
---
ACK.
On 02/26/2013 05:04 PM, Arnon Gilboa wrote:
vdagent terminates when the global event is set by vdservice. vdservice is also
responsible to reset the event in any case, without trusting vdagent to do so.
Otherwise, it may terminate the following vdagent instance immediately as well.
On Tue, Feb 26, 2013 at 02:32:12PM +1000, Dave Airlie wrote:
ACK all the patches above, ACK this one too with small nit picks.
Did not break xspice :)
Regarding application of patches - I had to manually merge but the
merges were the trivial ones so probably some whitespace? so if you
manage to
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 frame drops in the server side (a drop occurs when a
new frame reaches the server while
an older frame is still
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
---
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)
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
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
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.
---
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
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
---
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
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. Then,
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
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
---
---
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
---
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
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
---
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
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
---
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
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 of
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. In order to decide this combination, we evaluate
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
- 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 mjpeg
quality
and frame 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
In fact, I went a API that can send a message to agent in the guest and change
resolution.
Thanks agine!
发自我的 iPad
在 2013-2-26，下午10:48，Alon Levy al...@redhat.com 写道：
changxiaodong píše v St 20. 02. 2013 v 12:32 +0800:
hello:
how can i set the display resolution before connect to a desktop?
thanks
now i connect with --full-screen=auto-conf
发自我的 iPad
在 2013-2-26，下午10:48，Alon Levy al...@redhat.com 写道：
changxiaodong píše v St 20. 02. 2013 v 12:32 +0800:
hello:
how can i set the display resolution before connect to a desktop?
no, that isn't possible. The windowed client will
58 matches
Mail list logo
