Re: [Spice-devel] Neep help with ssl

[Alexandre DERUMIER]

>>If I read this correctly, you're getting the same error when using plain 
>>openssl client - that would suggest indeed suggest some problem with 
>>certificates and/or openssl library but certainly outside of scope of 
>>spice components. 

I finally get it working !, using tls-ciphers options.

theses cipher works for me:

spicec -h kvmtest1.odiso.net -s 60101 --ca-file ca-cert.pem --tls-ciphers 
DES-CBC-SHA
spicec -h kvmtest1.odiso.net -s 60101 --ca-file ca-cert.pem --tls-ciphers 
DES-CBC3-SHA
spicec -h kvmtest1.odiso.net -s 60101 --ca-file ca-cert.pem --tls-ciphers 
SEED-SHA


What is the default ciphers used if tls ciphers option is not specified ?

I see some bug report on openssl mailing list recently with aes cipher and "bad 
record mac" error, but it seem to be fixed now.


Thanks Again for help David !

Alexandre

- Mail original - 

De: "David Jaša"  
À: "Alexandre DERUMIER"  
Cc: spice-devel@lists.freedesktop.org 
Envoyé: Mercredi 17 Avril 2013 18:07:31 
Objet: Re: [Spice-devel] Neep help with ssl 

Alexandre DERUMIER píše v St 17. 04. 2013 v 17:07 +0200: 
> Here some news, 
> 
> the problem seem to be located on qemu-spice server side. 
> 
> I have reused my working certificates from proxmox (which works fine with 
> vnc/tls and also https). 
> 
> 
> Maybe is it a compatibility problem with spice and openssl of debian wheezy 
> (1.0.1e) ? 
> 
> soft stack versions are : 
> 
> - qemu 1.4.1 
> - spice 0.12.2 
> - libspice-protocol-dev 0.12.5 
> - openssl 1.0.1e 
> 
> 
> 
> 
> Here some tests results with openssl: 
> 
> 
> openssl client -> openssl server : OK 
> - 
> #openssl s_client -connect kvmtest1.odiso.net:60101 -CAfile ca-cert.pem 
> #openssl s_server -accept 60101 -cert server-cert.pem -key server-key.pem 
> -CAfile ca-cert.pem 
> 
> 
> spicec client -> openssl server : OK 
>  
> #spicec -h kvmtest1.odiso.net -s 60101 --ca-file ca-cert.pem 
> 
> #openssl s_server -accept 60101 -cert server-cert.pem -key server-key.pem 
> -CAfile ca-cert.pem 
> 
> 
> 
> 
> spicec client -> spice server : FAIL 
>  
> #spicec -h kvmtest1.odiso.net -s 60101 --ca-file ca-cert.pem 
> 
> #qemu -spice tls-port=60101,disable-ticketing,x509-dir=/etc/pki/libvirt-spice 
> 
> 
> Error: failed to connect w/SSL, ssl_error 
> error:0001:lib(0):func(0):reason(1) 
> 14029280376:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad 
> record mac:s3_pkt.c:1256:SSL alert number 20 
> Warning: SSL Error: error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert 
> bad record mac 
> 
> 
> 
> 
> openssl client -> spice server : FAIL 
> -- 
> #openssl s_client -connect kvmtest1.odiso.net:60101 -CAfile ca-cert.pem 
> 
> #qemu -spice tls-port=60101,disable-ticketing,x509-dir=/etc/pki/libvirt-spice 
> 
> 
> 
> $ openssl s_client -connect kvmtest1.odiso.net:60101 -CAfile ca-cert.pem 
> CONNECTED(0003) 
> depth=1 CN = Proxmox Virtual Environment, OU = 
> 6a15223364e62b87b401fe3d05d9dceb, O = PVE Cluster Manager CA 
> verify return:1 
> depth=0 OU = PVE Cluster Node, O = Proxmox Virtual Environment, CN = 
> kvmtest1.odiso.net 
> verify return:1 
> 140348776556200:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad 
> record mac:s3_pkt.c:1256:SSL alert number 20 
> 140348776556200:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
> failure:s23_lib.c:177: 

If I read this correctly, you're getting the same error when using plain 
openssl client - that would suggest indeed suggest some problem with 
certificates and/or openssl library but certainly outside of scope of 
spice components. 

David 

> --- 
> Certificate chain 
> 0 s:/OU=PVE Cluster Node/O=Proxmox Virtual Environment/CN=kvmtest1.odiso.net 
> i:/CN=Proxmox Virtual Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE 
> Cluster Manager CA 
> 1 s:/CN=Proxmox Virtual Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE 
> Cluster Manager CA 
> i:/CN=Proxmox Virtual Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE 
> Cluster Manager CA 
> --- 
> Server certificate 
> -BEGIN CERTIFICATE- 
> MIIDuDCCAqCgAwIBAgIBBDANBgkqhkiG9w0BAQUFADByMSQwIgYDVQQDExtQcm94 
> bW94IFZpcnR1YWwgRW52aXJvbm1lbnQxKTAnBgNVBAsTIDZhMTUyMjMzNjRlNjJi 
> ODdiNDAxZmUzZDA1ZDlkY2ViMR8wHQYDVQQKExZQVkUgQ2x1c3RlciBNYW5hZ2Vy 
> IENBMB4XDTEyMDMyMjA4MTY0MloXDTIyMDMyMDA4MTY0MlowXjEZMBcGA1UECxMQ 
> UFZFIENsdXN0ZXIgTm9kZTEkMCIGA1UEChMbUHJveG1veCBWaXJ0dWFsIEVudmly 
> b25tZW50MRswGQYDVQQDExJrdm10ZXN0MS5vZGlzby5uZXQwggEiMA0GCSqGSIb3 
> DQEBAQUAA4IBDwAwggEKAoIBAQCt5fOEFyp909x8KWVQ4a7kclTYIhwbW/7XziyN 
> fBf8ybuS2OmqwANAVAccVjPzRto05fGYjZfuykpOapbUVLAv+9u3hSKKgPd6g9tI 
> u2Ltvb8G0aoibPjtfAL2++61QUuTQUJ7aVlpSE+vWrqTgviCapFVJGiGhl9zoPC7 
> XuVnMmkdiAR0fQa9zFpqHP7zajbVqHPWpStMJrfoX0/0vFBxLP8xCQXIjqOR6AIY 
> LnCYc8MEIh0WlyN3WN19MezcCuNjXA3twv+pQEgG82y0DkAaJFMtg1zMaKXfAYil 
> kr0ZbEptyZlyD3nWoBTLOe8yiw+Lb7WED6Ccfm4XpR6Y5SutAgMBAAGjbTBrMAkG 
> A1Ud

Re: [Spice-devel] Neep help with ssl

[David Jaša]

Alexandre DERUMIER píše v St 17. 04. 2013 v 17:07 +0200:
> Here some news,
> 
> the problem seem to be located on qemu-spice server side.
> 
> I have reused my working certificates from proxmox (which works fine with 
> vnc/tls and also https).
> 
> 
> Maybe is it a compatibility problem with spice and openssl of debian wheezy 
> (1.0.1e) ?
> 
> soft stack versions are :
> 
> - qemu 1.4.1
> - spice 0.12.2
> - libspice-protocol-dev 0.12.5
> - openssl 1.0.1e
> 
> 
> 
> 
> Here some tests results with openssl:
> 
> 
> openssl client -> openssl server : OK
> -
> #openssl s_client -connect kvmtest1.odiso.net:60101 -CAfile ca-cert.pem
> #openssl s_server -accept 60101  -cert server-cert.pem -key server-key.pem 
> -CAfile ca-cert.pem 
> 
> 
> spicec client -> openssl server : OK
> 
> #spicec -h kvmtest1.odiso.net -s 60101 --ca-file ca-cert.pem
> 
> #openssl s_server -accept 60101 -cert server-cert.pem -key server-key.pem 
> -CAfile ca-cert.pem 
> 
> 
> 
> 
> spicec client -> spice server : FAIL
> 
> #spicec -h kvmtest1.odiso.net -s 60101 --ca-file ca-cert.pem
> 
> #qemu -spice tls-port=60101,disable-ticketing,x509-dir=/etc/pki/libvirt-spice
> 
> 
> Error: failed to connect w/SSL, ssl_error 
> error:0001:lib(0):func(0):reason(1)
> 14029280376:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad 
> record mac:s3_pkt.c:1256:SSL alert number 20
> Warning: SSL Error: error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert 
> bad record mac
> 
> 
> 
> 
> openssl client -> spice server : FAIL
> --
> #openssl s_client -connect kvmtest1.odiso.net:60101 -CAfile ca-cert.pem
> 
> #qemu -spice tls-port=60101,disable-ticketing,x509-dir=/etc/pki/libvirt-spice
> 
> 
> 
> $ openssl s_client -connect kvmtest1.odiso.net:60101 -CAfile ca-cert.pem
> CONNECTED(0003)
> depth=1 CN = Proxmox Virtual Environment, OU = 
> 6a15223364e62b87b401fe3d05d9dceb, O = PVE Cluster Manager CA
> verify return:1
> depth=0 OU = PVE Cluster Node, O = Proxmox Virtual Environment, CN = 
> kvmtest1.odiso.net
> verify return:1
> 140348776556200:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad 
> record mac:s3_pkt.c:1256:SSL alert number 20
> 140348776556200:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
> failure:s23_lib.c:177:

If I read this correctly, you're getting the same error when using plain
openssl client - that would suggest indeed suggest some problem with
certificates and/or openssl library but certainly outside of scope of
spice components.

David

> ---
> Certificate chain
>  0 s:/OU=PVE Cluster Node/O=Proxmox Virtual Environment/CN=kvmtest1.odiso.net
>i:/CN=Proxmox Virtual 
> Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE Cluster Manager CA
>  1 s:/CN=Proxmox Virtual 
> Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE Cluster Manager CA
>i:/CN=Proxmox Virtual 
> Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE Cluster Manager CA
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIDuDCCAqCgAwIBAgIBBDANBgkqhkiG9w0BAQUFADByMSQwIgYDVQQDExtQcm94
> bW94IFZpcnR1YWwgRW52aXJvbm1lbnQxKTAnBgNVBAsTIDZhMTUyMjMzNjRlNjJi
> ODdiNDAxZmUzZDA1ZDlkY2ViMR8wHQYDVQQKExZQVkUgQ2x1c3RlciBNYW5hZ2Vy
> IENBMB4XDTEyMDMyMjA4MTY0MloXDTIyMDMyMDA4MTY0MlowXjEZMBcGA1UECxMQ
> UFZFIENsdXN0ZXIgTm9kZTEkMCIGA1UEChMbUHJveG1veCBWaXJ0dWFsIEVudmly
> b25tZW50MRswGQYDVQQDExJrdm10ZXN0MS5vZGlzby5uZXQwggEiMA0GCSqGSIb3
> DQEBAQUAA4IBDwAwggEKAoIBAQCt5fOEFyp909x8KWVQ4a7kclTYIhwbW/7XziyN
> fBf8ybuS2OmqwANAVAccVjPzRto05fGYjZfuykpOapbUVLAv+9u3hSKKgPd6g9tI
> u2Ltvb8G0aoibPjtfAL2++61QUuTQUJ7aVlpSE+vWrqTgviCapFVJGiGhl9zoPC7
> XuVnMmkdiAR0fQa9zFpqHP7zajbVqHPWpStMJrfoX0/0vFBxLP8xCQXIjqOR6AIY
> LnCYc8MEIh0WlyN3WN19MezcCuNjXA3twv+pQEgG82y0DkAaJFMtg1zMaKXfAYil
> kr0ZbEptyZlyD3nWoBTLOe8yiw+Lb7WED6Ccfm4XpR6Y5SutAgMBAAGjbTBrMAkG
> A1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgZAMAsGA1UdDwQEAwIF4DA+BgNVHREE
> NzA1hwR/AAABgglsb2NhbGhvc3SHBAoDXh+CCGt2bXRlc3QxghJrdm10ZXN0MS5v
> ZGlzby5uZXQwDQYJKoZIhvcNAQEFBQADggEBADWSVeDJHA6y45lmtmYOGfXQlSmI
> zSLAzXm7brshvvyom+HEMYNmoMgwPZnt5wJgRF88uGzAFUlZSU8z62xtQwjEAVOC
> cfXkoM/D0gVKFGvz5T4kBNrache5on++Co6WJhM+txwmBnfJ1aYV1LhOSbPDYGlF
> sAVUPszYe+wDnxxDeaPRyW48+wMz4dMtcfQKmPJE1dvmdkYVxG7cAnYg8QIgMeBV
> cnRghW8Ko0YEI4HJb75H49WNxgD2VtWMIyHyaN4SdxeFyan/KPqj8jbjO6JYBDHz
> /FlXxrBhYijyvSSpwHk4+HN13grffREuq/DHgJ3SFqgxQx3sMQTuXsE3nuk=
> -END CERTIFICATE-
> subject=/OU=PVE Cluster Node/O=Proxmox Virtual 
> Environment/CN=kvmtest1.odiso.net
> issuer=/CN=Proxmox Virtual 
> Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE Cluster Manager CA
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 2144 bytes and written 326 bytes
> ---
> New, TLSv1/SSLv3, Cipher is AES256-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1
> Cipher: AES256-SHA
> Session-I

Re: [Spice-devel] [PATCH spice-server 00/28] adaptive video streaming

[Alon Levy]

> On 04/17/2013 10:47 AM, Alon Levy wrote:
> > On Mon, 2013-04-15 at 14:54 -0400, Yonit Halperin wrote:
> >> 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 further, I prefer to let you push
> >>> them. I hope to work a bit on testability of streams that doesn't
> >>> require creating a vm, but of course that too is just a note and not
> >>> related to acking this series.
> >>>
> >> Thanks for reviewing.
> >> Anyone care to also review the spice-gtk,spice-common and spice-protocol
> >> patches?
> >
> > I think it's best I review those too.
> >
> Cool, Thanks.

ACK series including common, protocol & gtk, just sent a couple of small notes 
but looks good. Pulseaudio corking change (6/8) maybe someone else wants to 
take a look, I'm not sure about what your comment actually means.

> >>
> >> Thanks,
> >> Yonit.
> >>
>  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 queued in the pipe). In the client side, the
>  video playback is synchronized according
>  to the audio playback (each audio and video frame holds an mm-time
>  field). The jitter-buffer size in the client
>  was constant as well - 100 ms. When video frames arrive late to the
>  client (i.e., when the audio playback is ahead of them),
>  they are dropped.
> 
>  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 the encoding
>  size for different jpeg
>  qualities by applying them on successive frames.
>  Every new stream is assigned with an initial bit rate. The bit rate is
>  re-estimated and
>  modified during the stream life time. The bit-rate is modified based on:
>  1) periodic reports from the client:
>   The client reports includes information about drops and the
>   playback latency.
>   In response to drops, or too short playback latency, we decrease
>   the bit rate.
>   In response to reports that suggest that the client playback is
>   stable with the
>   current configuration, we try to increase the bit-rate.
>  2) server drops: the bit-rate is decreased when server drops occur.
> 
>  Each time the bit rate changes, the stream parameters are re-evaluated.
>  In addition, we monitor the frames' encoding size, and when there is a
>  change
>  that may allow improving the stream parameters, or alternatively,
>  requires decreasing the
>  quality, we again re-evaluate them.
> 
>  Other changes:
>  --
> 
>  Besides the client reports, I also added to the protocol a message that
>  controls the
>  audio playback latency, for allowing better synchronization of the audio
>  and video playback buffering.
> 
>  The roundtrip time is used for estimating the required playback delay.
>  In order to get a more accurate estimation
>  of the roundtrip time I also added an option to measure it periodically
>  instead of just on startup, and
>  take the minimum measurement as estimation.
> 
>  Results
>  ---
>  I compared the video quality of the current spice master, and of the new
>  spice, under different network setups.
>  Spice master was a bit modified for making the comparison more fair: I
>  increased the audio jitter buffer to 200ms (instead of 100),
>  and also included the patch "red_worker: stream agent - fix miscounting
>  of frames".
>  The network setup was emulated using tc.
> 
>  You can find the tests details and the results in a following email.
> 
>  For 5Mpbs and 60ms roundtrip (Test1), in spice-master, more than 70% of
>  the frames that are sent to the client are being dropped, and the video
>  is unwatchable. With new spice, while the average frame rate is about
>  the same, only about 2% of the frames are being dropped by the client.
>  For 2.5Mbps and 60ms (Test2), as expected, things gets worse for
>  spice-master, and the drops rate reaches 90%. For the new spice, it is
>  less then 20%, and
>  the video is watchable.
> 
>  I also tested a setup of 10Mbps with high latency (170ms, Test3). The
>  latency affects the ini

Re: [Spice-devel] [PATCH spice-gtk 6/8] spice-pulse: adjust the playback latency when the min-latency property changes

[Alon Levy]

> 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,
> due to the tlength growth, each time the playback latency deviated
> from the target latency, an underflow occurred. Since the latency
> that is computed by the server is not exact and is based on its
> current evaluation of the bit-rate, which is dynamic, it is better not
> to change the tlength (in order to avoid unnecessary underflows).

Looks good to me, so ACK

You can remove the FIXME below now I think :)

> ---
>  gtk/spice-pulse.c | 67
>  ---
>  1 file changed, 59 insertions(+), 8 deletions(-)
> 
> diff --git a/gtk/spice-pulse.c b/gtk/spice-pulse.c
> index 107ce7c..7a4e2c6 100644
> --- a/gtk/spice-pulse.c
> +++ b/gtk/spice-pulse.c
> @@ -46,6 +46,8 @@ struct _SpicePulsePrivate {
>  int state;
>  struct stream   playback;
>  struct stream   record;
> +guint   last_delay;
> +guint   target_delay;
>  };
>  
>  G_DEFINE_TYPE(SpicePulse, spice_pulse, SPICE_TYPE_AUDIO)
> @@ -185,7 +187,7 @@ static void pulse_flush_cb(pa_stream *pastream, int
> success, void *data)
>  s->cork_op = NULL;
>  }
>  
> -static void pulse_cork_cb(pa_stream *pastream, int success, void *data)
> +static void pulse_cork_flush_cb(pa_stream *pastream, int success, void
> *data)
>  {
>  struct stream *s = data;
>  
> @@ -199,7 +201,19 @@ static void pulse_cork_cb(pa_stream *pastream, int
> success, void *data)
>  }
>  }
>  
> -static void stream_cork(SpicePulse *pulse, struct stream *s)
> +static void pulse_cork_cb(pa_stream *pastream, int success, void *data)
> +{
> +struct stream *s = data;
> +
> +SPICE_DEBUG("%s: cork started", __FUNCTION__);
> +if (!success)
> +g_warning("pulseaudio cork operation failed");
> +
> +pa_operation_unref(s->cork_op);
> +s->cork_op = NULL;
> +}
> +
> +static void stream_cork(SpicePulse *pulse, struct stream *s, gboolean
> with_flush)
>  {
>  SpicePulsePrivate *p = SPICE_PULSE_GET_PRIVATE(pulse);
>  pa_operation *o = NULL;
> @@ -211,7 +225,10 @@ static void stream_cork(SpicePulse *pulse, struct stream
> *s)
>  }
>  
>  if (!pa_stream_is_corked(s->stream) && !s->cork_op) {
> -if (!(o = pa_stream_cork(s->stream, 1, pulse_cork_cb, s))) {
> +if (!(o = pa_stream_cork(s->stream, 1,
> + with_flush ? pulse_cork_flush_cb :
> +  pulse_cork_cb,
> + s))) {
>  g_warning("pa_stream_cork() failed: %s",
>pa_strerror(pa_context_errno(p->context)));
>  }
> @@ -277,11 +294,12 @@ static void stream_underflow_cb(pa_stream *s, void
> *userdata)
>  
>  static void stream_update_latency_callback(pa_stream *s, void *userdata)
>  {
> +SpicePulse *pulse = userdata;
>  pa_usec_t usec;
>  int negative = 0;
>  SpicePulsePrivate *p;
>  
> -p = SPICE_PULSE_GET_PRIVATE(userdata);
> +p = SPICE_PULSE_GET_PRIVATE(pulse);
>  
>  g_return_if_fail(s != NULL);
>  g_return_if_fail(p != NULL);
> @@ -295,8 +313,16 @@ static void stream_update_latency_callback(pa_stream *s,
> void *userdata)
>  }
>  
>  g_return_if_fail(negative == FALSE);
> -
> +p->last_delay = usec / PA_USEC_PER_MSEC;
>  spice_playback_channel_set_delay(SPICE_PLAYBACK_CHANNEL(p->pchannel),
>  usec / 1000);
> +if (pa_stream_is_corked(p->playback.stream)) {
> +if (p->last_delay >= p->target_delay) {
> +SPICE_DEBUG("%s: uncork playback. delay %u target %u",
> __FUNCTION__, p->last_delay, p->target_delay);
> +stream_uncork(pulse, &p->playback);
> +} else {
> +SPICE_DEBUG("%s: still corked. delay %u target %u",
> __FUNCTION__, p->last_delay, p->target_delay);
> +}
> +}
>  }
>  
>  static void create_playback(SpicePulse *pulse)
> @@ -319,7 +345,7 @@ static void create_playback(SpicePulse *pulse)
>  
>  /* FIXME: we might want customizable latency */

Here.

>  buffer_attr.maxlength = -1;
> -buffer_attr.tlength = pa_usec_to_bytes(100 * PA_USEC_PER_MSEC,
> &p->playback.spec);
> +buffer_attr.tlength = pa_usec_to_bytes(p->target_delay *
> PA_USEC_PER_MSEC, &p->playback.spec);
>  buffer_attr.prebuf = -1;
>  buffer_attr.minreq = -1;
>  flags = PA_STREAM_ADJUST_LATENCY | PA_STREAM_AUTO_TIMING_UPDATE;
> @@ -337,15 +363,18 @@ static void playback_start(SpicePlaybackChannel
> *channel, gint format, gint chan
>  SpicePulse *pulse = data;
>  SpicePulsePrivate *p = SPICE_PULSE_GET_PRIVATE(pulse);
>  pa_context_state_t state;
> +guint latency;
>  
>  g_return_if_fail(p

Re: [Spice-devel] [PATCH spice-gtk 4/8] channel-display: video stream quality report

[Alon Levy]

> handle MSG_STREAM_ACTIVIATE_REPORT and send MSGC_STREAM_REPORT
> periodically, or when the playback is out of sync.

ACK with one comment

> ---
>  gtk/channel-display-priv.h |  10 
>  gtk/channel-display.c  | 116
>  -
>  spice-common   |   2 +-
>  3 files changed, 114 insertions(+), 14 deletions(-)
> 
> diff --git a/gtk/channel-display-priv.h b/gtk/channel-display-priv.h
> index f57dc6e..49f82fe 100644
> --- a/gtk/channel-display-priv.h
> +++ b/gtk/channel-display-priv.h
> @@ -88,6 +88,16 @@ typedef struct display_stream {
>  GArray   *drops_seqs_stats_arr;
>  uint32_t num_drops_seqs;
>  
> +/* playback quality report to server */
> +gboolean report_is_active;
> +uint32_t report_id;
> +uint32_t report_max_window;
> +uint32_t report_timeout;
> +uint64_t report_start_time;
> +uint32_t report_start_frame_time;
> +uint32_t report_num_frames;
> +uint32_t report_num_drops;
> +uint32_t report_drops_seq_len;
>  } display_stream;
>  
>  void stream_get_dimensions(display_stream *st, int *width, int *height);
> diff --git a/gtk/channel-display.c b/gtk/channel-display.c
> index ab4d3bd..efb9aec 100644
> --- a/gtk/channel-display.c
> +++ b/gtk/channel-display.c
> @@ -687,6 +687,7 @@ static void
> spice_display_channel_reset_capabilities(SpiceChannel *channel)
>  spice_channel_set_capability(SPICE_CHANNEL(channel),
>  SPICE_DISPLAY_CAP_MONITORS_CONFIG);
>  spice_channel_set_capability(SPICE_CHANNEL(channel),
>  SPICE_DISPLAY_CAP_COMPOSITE);
>  spice_channel_set_capability(SPICE_CHANNEL(channel),
>  SPICE_DISPLAY_CAP_A8_SURFACE);
> +spice_channel_set_capability(SPICE_CHANNEL(channel),
> SPICE_DISPLAY_CAP_STREAM_REPORT);
>  }
>  
>  static void spice_display_channel_init(SpiceDisplayChannel *channel)
> @@ -1238,6 +1239,65 @@ static gboolean display_stream_render(display_stream
> *st)
>  return FALSE;
>  }
>  
> +#define STREAM_REPORT_DROP_SEQ_LEN_LIMIT 3 /* after a sequence of 3 drops,
> push a report to the server, even
> +  if the report window is bigger
> */

Put the comment before and then you can keep the 80 chars width (not sure if it 
is actually in the spice-gtk coding standard but it looks better).

> +
> +static void display_update_stream_report(SpiceDisplayChannel *channel,
> uint32_t stream_id,
> + uint32_t frame_time, int32_t
> latency)
> +{
> +display_stream *st = channel->priv->streams[stream_id];
> +guint64 now;
> +
> +if (!st->report_is_active) {
> +return;
> +}
> +now = g_get_monotonic_time();
> +
> +if (st->report_num_frames == 0) {
> +st->report_start_frame_time = frame_time;
> +st->report_start_time = now;
> +}
> +st->report_num_frames++;
> +
> +if (latency < 0) { // drop
> +st->report_num_drops++;
> +st->report_drops_seq_len++;
> +} else {
> +st->report_drops_seq_len = 0;
> +}
> +
> +if (st->report_num_frames >= st->report_max_window ||
> +now - st->report_start_time >= st->report_timeout ||
> +st->report_drops_seq_len >= STREAM_REPORT_DROP_SEQ_LEN_LIMIT) {
> +SpiceMsgcDisplayStreamReport report;
> +SpiceSession *session =
> spice_channel_get_session(SPICE_CHANNEL(channel));
> +SpiceMsgOut *msg;
> +
> +report.stream_id = stream_id;
> +report.unique_id = st->report_id;
> +report.start_frame_mm_time = st->report_start_frame_time;
> +report.end_frame_mm_time = frame_time;
> +report.num_frames = st->report_num_frames;
> +report.num_drops = st-> report_num_drops;
> +report.last_frame_delay = latency;
> +if (spice_session_is_playback_active(session)) {
> +report.audio_delay =
> spice_session_get_playback_latency(session);
> +} else {
> +report.audio_delay = UINT_MAX;
> +}
> +
> +msg = spice_msg_out_new(SPICE_CHANNEL(channel),
> SPICE_MSGC_DISPLAY_STREAM_REPORT);
> +msg->marshallers->msgc_display_stream_report(msg->marshaller,
> &report);
> +spice_msg_out_send(msg);
> +
> +st->report_start_time = 0;
> +st->report_start_frame_time = 0;
> +st->report_num_frames = 0;
> +st->report_num_drops = 0;
> +st->report_drops_seq_len = 0;
> +}
> +}
> +
>  /* coroutine context */
>  static void display_handle_stream_data(SpiceChannel *channel, SpiceMsgIn
>  *in)
>  {
> @@ -1245,6 +1305,7 @@ static void display_handle_stream_data(SpiceChannel
> *channel, SpiceMsgIn *in)
>  SpiceStreamDataHeader *op = spice_msg_in_parsed(in);
>  display_stream *st;
>  guint32 mmtime;
> +int32_t latency;
>  
>  g_return_if_fail(c != NULL);
>  g_return_if_fail(c->streams != NULL);
> @@ -1266,7 +1327,9 @@ static void display_handle_stream_data(SpiceChannel
> *channel

Re: [Spice-devel] [PATCH spice-gtk 3/8] channel-playback: provide access to playback properties via the session

[Alon Levy]

> Support checking whether an audio playback is active and what its latency
> is.

ACK, one comment.

> ---
>  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 | 30 ++
>  5 files changed, 81 insertions(+)
>  create mode 100644 gtk/channel-playback-priv.h
> 
> diff --git a/gtk/Makefile.am b/gtk/Makefile.am
> index eb64b13..6b4219f 100644
> --- a/gtk/Makefile.am
> +++ b/gtk/Makefile.am
> @@ -235,6 +235,7 @@ libspice_client_glib_2_0_la_SOURCES = 
> \
>   channel-inputs.c\
>   channel-main.c  \
>   channel-playback.c  \
> + channel-playback-priv.h \
>   channel-port.c  \
>   channel-record.c\
>   channel-smartcard.c \
> diff --git a/gtk/channel-playback-priv.h b/gtk/channel-playback-priv.h
> new file mode 100644
> index 000..dc89e2d
> --- /dev/null
> +++ b/gtk/channel-playback-priv.h
> @@ -0,0 +1,23 @@
> +/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
> +/*
> +   Copyright (C) 2013 Red Hat, Inc.
> +
> +   This library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   This library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with this library; if not, see
> .
> +*/
> +#ifndef __SPICE_CLIENT_PLAYBACK_CHANNEL_PRIV_H__
> +#define __SPICE_CLIENT_PLAYBACK_CHANNEL_PRIV_H__
> +
> +gboolean spice_playback_channel_is_active(SpicePlaybackChannel *channel);
> +guint32 spice_playback_channel_get_latency(SpicePlaybackChannel *channel);
> +#endif
> diff --git a/gtk/channel-playback.c b/gtk/channel-playback.c
> index 2d542a7..7cbfa36 100644
> --- a/gtk/channel-playback.c
> +++ b/gtk/channel-playback.c
> @@ -55,6 +55,8 @@ struct _SpicePlaybackChannelPrivate {
>  guint8  nchannels;
>  guint16 *volume;
>  guint8  mute;
> +gbooleanis_active;
> +guint32 latency;
>  };
>  
>  G_DEFINE_TYPE(SpicePlaybackChannel, spice_playback_channel,
>  SPICE_TYPE_CHANNEL)
> @@ -416,6 +418,7 @@ static void playback_handle_start(SpiceChannel *channel,
> SpiceMsgIn *in)
>  
>  c->frame_count = 0;
>  c->last_time = start->time;
> +c->is_active = TRUE;
>  
>  switch (c->mode) {
>  case SPICE_AUDIO_DATA_MODE_RAW:
> @@ -450,7 +453,10 @@ static void playback_handle_start(SpiceChannel *channel,
> SpiceMsgIn *in)
>  /* coroutine context */
>  static void playback_handle_stop(SpiceChannel *channel, SpiceMsgIn *in)
>  {
> +SpicePlaybackChannelPrivate *c = SPICE_PLAYBACK_CHANNEL(channel)->priv;
> +
>  emit_main_context(channel, SPICE_PLAYBACK_STOP);
> +c->is_active = FALSE;
>  }
>  
>  /* coroutine context */
> @@ -512,6 +518,24 @@ void
> spice_playback_channel_set_delay(SpicePlaybackChannel *channel, guint32 del
>  CHANNEL_DEBUG(channel, "playback set_delay %u ms", delay_ms);
>  
>  c = channel->priv;
> +c->latency = delay_ms;
>  
> spice_session_set_mm_time(spice_channel_get_session(SPICE_CHANNEL(channel)),
>c->last_time - delay_ms);
>  }
> +
> +G_GNUC_INTERNAL
> +gboolean spice_playback_channel_is_active(SpicePlaybackChannel *channel)
> +{
> +g_return_val_if_fail(SPICE_IS_PLAYBACK_CHANNEL(channel), FALSE);
> +return channel->priv->is_active;
> +}
> +
> +G_GNUC_INTERNAL
> +guint32 spice_playback_channel_get_latency(SpicePlaybackChannel *channel)
> +{
> +g_return_val_if_fail(SPICE_IS_PLAYBACK_CHANNEL(channel), 0);
> +if (!channel->priv->is_active) {
> +return 0;
> +}
> +return channel->priv->latency;
> +}
> diff --git a/gtk/spice-session-priv.h b/gtk/spice-session-priv.h
> index 7ee6b6c..4cf5fe9 100644
> --- a/gtk/spice-session-priv.h
> +++ b/gtk/spice-session-priv.h
> @@ -106,6 +106,7 @@ struct _SpiceSessionPrivate {
>  SpiceDesktopIntegration *desktop_integration;
>  SpiceGtkSession   *gtk_session;
>  SpiceUsbDeviceManager *usb_manager;
> +SpicePlaybackChannel *playback_channel;
>  };
>  
>  SpiceSession *spice_session_new_from_session(SpiceSession *session);
> @@ -154,6 +155,8 @@ gboolean
> spice_session_migr

Re: [Spice-devel] [spice-xpi 1/3] build: Adjust plugin name when building xpi

[Alon Levy]

> The plugin binary name was changed from libnsISpice to npSpiceConsole,
> but the Makefile.am rule optionnally building SpiceXpi.xpi was not
> changed to take this rename into account.

ACK series.

> ---
>  SpiceXPI/Makefile.am | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/SpiceXPI/Makefile.am b/SpiceXPI/Makefile.am
> index de058b5..a12135a 100644
> --- a/SpiceXPI/Makefile.am
> +++ b/SpiceXPI/Makefile.am
> @@ -9,12 +9,12 @@ all-local: SpiceXPI.xpi
>  
>  CLEANFILES = SpiceXPI.xpi
>  
> -SpiceXPI.xpi: $(srcdir)/src/install.rdf src/plugin/nsISpicec.xpt
> src/plugin/.libs/libnsISpicec.so
> +SpiceXPI.xpi: $(srcdir)/src/install.rdf src/plugin/nsISpicec.xpt
> src/plugin/.libs/npSpiceConsole.so
>   $(AM_V_GEN)rm -rf $(DISTDIR)
>   @[ -d $(DISTDIR)/plugins ] || mkdir -p $(DISTDIR)/plugins
>   @cp $(srcdir)/src/install.rdf $(DISTDIR)
>   @cp src/plugin/*.xpt $(DISTDIR)/plugins
> - @cp src/plugin/.libs/libnsISpicec.so $(DISTDIR)/plugins/nsISpicec.so
> + @cp src/plugin/.libs/npSpiceConsole.so 
> $(DISTDIR)/plugins/npSpiceConsole.so
>   @(cd $(DISTDIR); zip -q -r ../$@ .)
>  
>  distclean-local:
> --
> 1.8.1.4
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Neep help with ssl

[Alexandre DERUMIER]

Here some news,

the problem seem to be located on qemu-spice server side.

I have reused my working certificates from proxmox (which works fine with 
vnc/tls and also https).


Maybe is it a compatibility problem with spice and openssl of debian wheezy 
(1.0.1e) ?

soft stack versions are :

- qemu 1.4.1
- spice 0.12.2
- libspice-protocol-dev 0.12.5
- openssl 1.0.1e




Here some tests results with openssl:


openssl client -> openssl server : OK
-
#openssl s_client -connect kvmtest1.odiso.net:60101 -CAfile ca-cert.pem
#openssl s_server -accept 60101  -cert server-cert.pem -key server-key.pem 
-CAfile ca-cert.pem 


spicec client -> openssl server : OK

#spicec -h kvmtest1.odiso.net -s 60101 --ca-file ca-cert.pem

#openssl s_server -accept 60101 -cert server-cert.pem -key server-key.pem 
-CAfile ca-cert.pem 




spicec client -> spice server : FAIL

#spicec -h kvmtest1.odiso.net -s 60101 --ca-file ca-cert.pem

#qemu -spice tls-port=60101,disable-ticketing,x509-dir=/etc/pki/libvirt-spice


Error: failed to connect w/SSL, ssl_error 
error:0001:lib(0):func(0):reason(1)
14029280376:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad 
record mac:s3_pkt.c:1256:SSL alert number 20
Warning: SSL Error: error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad 
record mac




openssl client -> spice server : FAIL
--
#openssl s_client -connect kvmtest1.odiso.net:60101 -CAfile ca-cert.pem

#qemu -spice tls-port=60101,disable-ticketing,x509-dir=/etc/pki/libvirt-spice



$ openssl s_client -connect kvmtest1.odiso.net:60101 -CAfile ca-cert.pem
CONNECTED(0003)
depth=1 CN = Proxmox Virtual Environment, OU = 
6a15223364e62b87b401fe3d05d9dceb, O = PVE Cluster Manager CA
verify return:1
depth=0 OU = PVE Cluster Node, O = Proxmox Virtual Environment, CN = 
kvmtest1.odiso.net
verify return:1
140348776556200:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad 
record mac:s3_pkt.c:1256:SSL alert number 20
140348776556200:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
failure:s23_lib.c:177:
---
Certificate chain
 0 s:/OU=PVE Cluster Node/O=Proxmox Virtual Environment/CN=kvmtest1.odiso.net
   i:/CN=Proxmox Virtual Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE 
Cluster Manager CA
 1 s:/CN=Proxmox Virtual Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE 
Cluster Manager CA
   i:/CN=Proxmox Virtual Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE 
Cluster Manager CA
---
Server certificate
-BEGIN CERTIFICATE-
MIIDuDCCAqCgAwIBAgIBBDANBgkqhkiG9w0BAQUFADByMSQwIgYDVQQDExtQcm94
bW94IFZpcnR1YWwgRW52aXJvbm1lbnQxKTAnBgNVBAsTIDZhMTUyMjMzNjRlNjJi
ODdiNDAxZmUzZDA1ZDlkY2ViMR8wHQYDVQQKExZQVkUgQ2x1c3RlciBNYW5hZ2Vy
IENBMB4XDTEyMDMyMjA4MTY0MloXDTIyMDMyMDA4MTY0MlowXjEZMBcGA1UECxMQ
UFZFIENsdXN0ZXIgTm9kZTEkMCIGA1UEChMbUHJveG1veCBWaXJ0dWFsIEVudmly
b25tZW50MRswGQYDVQQDExJrdm10ZXN0MS5vZGlzby5uZXQwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCt5fOEFyp909x8KWVQ4a7kclTYIhwbW/7XziyN
fBf8ybuS2OmqwANAVAccVjPzRto05fGYjZfuykpOapbUVLAv+9u3hSKKgPd6g9tI
u2Ltvb8G0aoibPjtfAL2++61QUuTQUJ7aVlpSE+vWrqTgviCapFVJGiGhl9zoPC7
XuVnMmkdiAR0fQa9zFpqHP7zajbVqHPWpStMJrfoX0/0vFBxLP8xCQXIjqOR6AIY
LnCYc8MEIh0WlyN3WN19MezcCuNjXA3twv+pQEgG82y0DkAaJFMtg1zMaKXfAYil
kr0ZbEptyZlyD3nWoBTLOe8yiw+Lb7WED6Ccfm4XpR6Y5SutAgMBAAGjbTBrMAkG
A1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgZAMAsGA1UdDwQEAwIF4DA+BgNVHREE
NzA1hwR/AAABgglsb2NhbGhvc3SHBAoDXh+CCGt2bXRlc3QxghJrdm10ZXN0MS5v
ZGlzby5uZXQwDQYJKoZIhvcNAQEFBQADggEBADWSVeDJHA6y45lmtmYOGfXQlSmI
zSLAzXm7brshvvyom+HEMYNmoMgwPZnt5wJgRF88uGzAFUlZSU8z62xtQwjEAVOC
cfXkoM/D0gVKFGvz5T4kBNrache5on++Co6WJhM+txwmBnfJ1aYV1LhOSbPDYGlF
sAVUPszYe+wDnxxDeaPRyW48+wMz4dMtcfQKmPJE1dvmdkYVxG7cAnYg8QIgMeBV
cnRghW8Ko0YEI4HJb75H49WNxgD2VtWMIyHyaN4SdxeFyan/KPqj8jbjO6JYBDHz
/FlXxrBhYijyvSSpwHk4+HN13grffREuq/DHgJ3SFqgxQx3sMQTuXsE3nuk=
-END CERTIFICATE-
subject=/OU=PVE Cluster Node/O=Proxmox Virtual Environment/CN=kvmtest1.odiso.net
issuer=/CN=Proxmox Virtual 
Environment/OU=6a15223364e62b87b401fe3d05d9dceb/O=PVE Cluster Manager CA
---
No client certificate CA names sent
---
SSL handshake has read 2144 bytes and written 326 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: AES256-SHA
Session-ID: 
Session-ID-ctx: 
Master-Key: 
8613FF06A8B943D3761042D44C080ECA4911AAE71A07C99C53971A5AF5E37373E23F520BF96342EA9DCE5C95D9EA48B9
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1366211037
Timeout   : 300 (sec)
Verify return code: 0 (ok)
---
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server 00/28] adaptive video streaming

[Yonit Halperin]

On 04/17/2013 10:47 AM, Alon Levy wrote:

On Mon, 2013-04-15 at 14:54 -0400, Yonit Halperin wrote:

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 further, I prefer to let you push
them. I hope to work a bit on testability of streams that doesn't
require creating a vm, but of course that too is just a note and not
related to acking this series.


Thanks for reviewing.
Anyone care to also review the spice-gtk,spice-common and spice-protocol
patches?


I think it's best I review those too.


Cool, Thanks.


Thanks,
Yonit.


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 queued in the pipe). In the client side, the video 
playback is synchronized according
to the audio playback (each audio and video frame holds an mm-time field). The 
jitter-buffer size in the client
was constant as well - 100 ms. When video frames arrive late to the client 
(i.e., when the audio playback is ahead of them),
they are dropped.

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 the encoding size 
for different jpeg
qualities by applying them on successive frames.
Every new stream is assigned with an initial bit rate. The bit rate is 
re-estimated and
modified during the stream life time. The bit-rate is modified based on:
1) periodic reports from the client:
 The client reports includes information about drops and the playback 
latency.
 In response to drops, or too short playback latency, we decrease the bit 
rate.
 In response to reports that suggest that the client playback is stable 
with the
 current configuration, we try to increase the bit-rate.
2) server drops: the bit-rate is decreased when server drops occur.

Each time the bit rate changes, the stream parameters are re-evaluated.
In addition, we monitor the frames' encoding size, and when there is a change
that may allow improving the stream parameters, or alternatively, requires 
decreasing the
quality, we again re-evaluate them.

Other changes:
--

Besides the client reports, I also added to the protocol a message that 
controls the
audio playback latency, for allowing better synchronization of the audio and 
video playback buffering.

The roundtrip time is used for estimating the required playback delay. In order 
to get a more accurate estimation
of the roundtrip time I also added an option to measure it periodically instead 
of just on startup, and
take the minimum measurement as estimation.

Results
---
I compared the video quality of the current spice master, and of the new spice, 
under different network setups.
Spice master was a bit modified for making the comparison more fair: I 
increased the audio jitter buffer to 200ms (instead of 100),
and also included the patch "red_worker: stream agent - fix miscounting of 
frames".
The network setup was emulated using tc.

You can find the tests details and the results in a following email.

For 5Mpbs and 60ms roundtrip (Test1), in spice-master, more than 70% of the 
frames that are sent to the client are being dropped, and the video
is unwatchable. With new spice, while the average frame rate is about the same, 
only about 2% of the frames are being dropped by the client.
For 2.5Mbps and 60ms (Test2), as expected, things gets worse for spice-master, 
and the drops rate reaches 90%. For the new spice, it is less then 20%, and
the video is watchable.

I also tested a setup of 10Mbps with high latency (170ms, Test3). The latency 
affects the initial bit rate estimation in spice (probably due to the tcp acks 
overhead).
Thus, the stream is started with a bit-rate estimation of less then 1.25Mbps. The 
adaptive video heuristic gradually converges to a higher bit rate (the column 
"end-bit-rate"), and
the next video stream will be started with the improved bit rate estimation.
In Test5 I tested a real environment with a network setup similar to Test3. 
However, the test are not comparable because in Test5 setup (different server 
and guest),
the basic frame rate (i.e., from the guest to the server) is much smaller 
(still need to investigate why).

In Test4 (20Mbps; <1 ms roundtrip), I evaluated and unlimited setup, i.e., a 
setup which will allow the best frame rate and jpeg-quality for the stream.
With new spice, the capacity of the channel is exploited efficiently. With 
spice-master, the con

Re: [Spice-devel] [PATCH spice-server 00/28] adaptive video streaming

[Alon Levy]

On Mon, 2013-04-15 at 14:54 -0400, Yonit Halperin wrote:
> 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 further, I prefer to let you push
> > them. I hope to work a bit on testability of streams that doesn't
> > require creating a vm, but of course that too is just a note and not
> > related to acking this series.
> >
> Thanks for reviewing.
> Anyone care to also review the spice-gtk,spice-common and spice-protocol 
> patches?

I think it's best I review those too.

> 
> Thanks,
> Yonit.
> 
> >> 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 queued in the pipe). In the client side, the video 
> >> playback is synchronized according
> >> to the audio playback (each audio and video frame holds an mm-time field). 
> >> The jitter-buffer size in the client
> >> was constant as well - 100 ms. When video frames arrive late to the client 
> >> (i.e., when the audio playback is ahead of them),
> >> they are dropped.
> >>
> >> 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 the encoding 
> >> size for different jpeg
> >> qualities by applying them on successive frames.
> >> Every new stream is assigned with an initial bit rate. The bit rate is 
> >> re-estimated and
> >> modified during the stream life time. The bit-rate is modified based on:
> >> 1) periodic reports from the client:
> >> The client reports includes information about drops and the playback 
> >> latency.
> >> In response to drops, or too short playback latency, we decrease the 
> >> bit rate.
> >> In response to reports that suggest that the client playback is stable 
> >> with the
> >> current configuration, we try to increase the bit-rate.
> >> 2) server drops: the bit-rate is decreased when server drops occur.
> >>
> >> Each time the bit rate changes, the stream parameters are re-evaluated.
> >> In addition, we monitor the frames' encoding size, and when there is a 
> >> change
> >> that may allow improving the stream parameters, or alternatively, requires 
> >> decreasing the
> >> quality, we again re-evaluate them.
> >>
> >> Other changes:
> >> --
> >>
> >> Besides the client reports, I also added to the protocol a message that 
> >> controls the
> >> audio playback latency, for allowing better synchronization of the audio 
> >> and video playback buffering.
> >>
> >> The roundtrip time is used for estimating the required playback delay. In 
> >> order to get a more accurate estimation
> >> of the roundtrip time I also added an option to measure it periodically 
> >> instead of just on startup, and
> >> take the minimum measurement as estimation.
> >>
> >> Results
> >> ---
> >> I compared the video quality of the current spice master, and of the new 
> >> spice, under different network setups.
> >> Spice master was a bit modified for making the comparison more fair: I 
> >> increased the audio jitter buffer to 200ms (instead of 100),
> >> and also included the patch "red_worker: stream agent - fix miscounting of 
> >> frames".
> >> The network setup was emulated using tc.
> >>
> >> You can find the tests details and the results in a following email.
> >>
> >> For 5Mpbs and 60ms roundtrip (Test1), in spice-master, more than 70% of 
> >> the frames that are sent to the client are being dropped, and the video
> >> is unwatchable. With new spice, while the average frame rate is about the 
> >> same, only about 2% of the frames are being dropped by the client.
> >> For 2.5Mbps and 60ms (Test2), as expected, things gets worse for 
> >> spice-master, and the drops rate reaches 90%. For the new spice, it is 
> >> less then 20%, and
> >> the video is watchable.
> >>
> >> I also tested a setup of 10Mbps with high latency (170ms, Test3). The 
> >> latency affects the initial bit rate estimation in spice (probably due to 
> >> the tcp acks overhead).
> >> Thus, the stream is started with a bit-rate estimation of less then 
> >> 1.25Mbps. The adaptive video heuristic gradually converges to a higher bit 
> >> rate (the column "end-bit-rate"), and
> >> the next video stream will be started with the improved bit rate 
> >> estimation.
> >> In Test5 I tested a real environment with a network setup similar to 
> >> Test3. However, the test are not comparable b

[Spice-devel] [spice-xpi 2/3] build: Use correct plugin name in Windows resource file

[Christophe Fergeau]

The nsISpicec -> npSpiceConsole rename was not propagated there.
---
 SpiceXPI/src/plugin/resource.rc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SpiceXPI/src/plugin/resource.rc b/SpiceXPI/src/plugin/resource.rc
index 8892b0a..38a50d2 100644
--- a/SpiceXPI/src/plugin/resource.rc
+++ b/SpiceXPI/src/plugin/resource.rc
@@ -20,7 +20,7 @@ BEGIN
 VALUE "FileVersion", "2, 8, 0, 0"
 VALUE "InternalName", "SpiceXPI"
 VALUE "LegalCopyright", "Fedora"
-VALUE "OriginalFilename", "nsISpicec.dll"
+VALUE "OriginalFilename", "npSpiceConsole.dll"
 VALUE "ProductName", "Spice XPI"
 VALUE "ProductVersion", "2, 8, 0, 0"
 VALUE "MIMEType", "application/x-spice"
-- 
1.8.1.4

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [spice-xpi 1/3] build: Adjust plugin name when building xpi

[Christophe Fergeau]

The plugin binary name was changed from libnsISpice to npSpiceConsole,
but the Makefile.am rule optionnally building SpiceXpi.xpi was not
changed to take this rename into account.
---
 SpiceXPI/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/SpiceXPI/Makefile.am b/SpiceXPI/Makefile.am
index de058b5..a12135a 100644
--- a/SpiceXPI/Makefile.am
+++ b/SpiceXPI/Makefile.am
@@ -9,12 +9,12 @@ all-local: SpiceXPI.xpi
 
 CLEANFILES = SpiceXPI.xpi
 
-SpiceXPI.xpi: $(srcdir)/src/install.rdf src/plugin/nsISpicec.xpt 
src/plugin/.libs/libnsISpicec.so
+SpiceXPI.xpi: $(srcdir)/src/install.rdf src/plugin/nsISpicec.xpt 
src/plugin/.libs/npSpiceConsole.so
$(AM_V_GEN)rm -rf $(DISTDIR)
@[ -d $(DISTDIR)/plugins ] || mkdir -p $(DISTDIR)/plugins
@cp $(srcdir)/src/install.rdf $(DISTDIR)
@cp src/plugin/*.xpt $(DISTDIR)/plugins
-   @cp src/plugin/.libs/libnsISpicec.so $(DISTDIR)/plugins/nsISpicec.so
+   @cp src/plugin/.libs/npSpiceConsole.so 
$(DISTDIR)/plugins/npSpiceConsole.so
@(cd $(DISTDIR); zip -q -r ../$@ .)
 
 distclean-local:
-- 
1.8.1.4

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [spice-xpi 3/3] build: Make sure $(PYTHON) is set when building xpi

[Christophe Fergeau]

Python is needed to generate nsISpicec.h and nsISpicec.xpt from
nsISpicec.idl.
---
 configure.ac | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure.ac b/configure.ac
index 39a1f7e..4a79626 100644
--- a/configure.ac
+++ b/configure.ac
@@ -50,6 +50,7 @@ AC_ARG_ENABLE([xpi],
   [Enable compilation of an xpi package])],
   [], [enable_xpi=no])
 if test x"$enable_xpi" != xno; then
+AM_PATH_PYTHON
 PKG_CHECK_MODULES(XUL, libxul-embedding >= 10)
 AC_SUBST(XUL_CFLAGS)
 AC_SUBST(XUL_LIBS)
-- 
1.8.1.4

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] MacOS SPICE client

[Christophe Fergeau]

Hi,

On Tue, Apr 16, 2013 at 06:00:48PM +0200, Edwin Peer wrote:
> After battling unsuccessfully with jhbuild, I was pleased to find
> this page on the SPICE wiki: http://spice-space.org/page/OSX_Client
> 
> Only problem, it doesn't seem to work. Fonts are rendered as blocks
> and I get this if I run it from a terminal:
>
[snip]
>
> I'm running Mountain Lion and don't really know my way around MacOS
> all that well. Would appreciate any help I could get.

Yes, that's a known issue, it's likely that some pango configuration file
is missing from the bundle. However, if you ignore the misrendered fonts
and enter a spice://example.com:5900 URI, it should connect fine to your
spice session.

Christophe


pgpKsNJD0I5es.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel