Re: [Spice-devel] [spice-gtk v2 1/2] Fix possible multimedia time overflow

[Christophe de Dinechin]

> On 16 Mar 2017, at 11:49, Marc-André Lureau  > wrote:
> 
> Hi
> 
> - Original Message -
>> The multimedia time can easily overflow as is encoded in an
>> unsigned 32 bit and have a unit of milliseconds so it wrap
>> up every 49 days. Use some math that allow the number to overflow
>> without issues.
>> This could caused the client to stop handling streaming and
>> starting only queueing.
>> 
>> Signed-off-by: Frediano Ziglio > >
>> ---
>> This patch should be applied independently on 2/2 as intended to be
>> merged upstream as a fix while 2/2 depends on this as it change same
>> code portions.
>> ---
>> src/channel-display-gst.c   | 11 ++-
>> src/channel-display-mjpeg.c | 14 --
>> src/channel-display-priv.h  | 19 +++
>> 3 files changed, 33 insertions(+), 11 deletions(-)
>> 
>> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
>> index c4190b2..9c62e67 100644
>> --- a/src/channel-display-gst.c
>> +++ b/src/channel-display-gst.c
>> @@ -183,8 +183,9 @@ static void schedule_frame(SpiceGstDecoder *decoder)
>> }
>> 
>> SpiceStreamDataHeader *op = spice_msg_in_parsed(frame->msg);
>> -if (now < op->multi_media_time) {
>> -decoder->timer_id = g_timeout_add(op->multi_media_time - now,
>> +gint32 time_diff = compute_mm_time_diff(op->multi_media_time, now);
>> +if (time_diff >= 0) {
>> +decoder->timer_id = g_timeout_add(time_diff,
>>   display_frame, decoder);
>> } else if (g_queue_get_length(decoder->display_queue) == 1) {
>> /* Still attempt to display the least out of date frame so the
>> @@ -192,8 +193,8 @@ static void schedule_frame(SpiceGstDecoder *decoder)
>>  */
>> decoder->timer_id = g_timeout_add(0, display_frame, decoder);
>> } else {
>> -SPICE_DEBUG("%s: rendering too late by %u ms (ts: %u, mmtime:
>> %u), dropping",
>> -__FUNCTION__, now - op->multi_media_time,
>> +SPICE_DEBUG("%s: rendering too late by %d ms (ts: %u, mmtime:
>> %u), dropping",
>> +__FUNCTION__, -time_diff,
>> op->multi_media_time, now);
>> stream_dropped_frame_on_playback(decoder->base.stream);
>> g_queue_pop_head(decoder->display_queue);
>> @@ -431,7 +432,7 @@ static gboolean
>> spice_gst_decoder_queue_frame(VideoDecoder *video_decoder,
>> }
>> 
>> SpiceStreamDataHeader *frame_op = spice_msg_in_parsed(frame_msg);
>> -if (frame_op->multi_media_time < decoder->last_mm_time) {
>> +if (compute_mm_time_diff(frame_op->multi_media_time,
>> decoder->last_mm_time) < 0) {
>> SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
>> " resetting stream, id %u",
>> frame_op->multi_media_time,
>> diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
>> index 722494e..1b7373b 100644
>> --- a/src/channel-display-mjpeg.c
>> +++ b/src/channel-display-mjpeg.c
>> @@ -195,15 +195,15 @@ static void mjpeg_decoder_schedule(MJpegDecoder
>> *decoder)
>> do {
>> if (frame_msg) {
>> SpiceStreamDataHeader *op = spice_msg_in_parsed(frame_msg);
>> -if (time <= op->multi_media_time) {
>> -guint32 d = op->multi_media_time - time;
>> +gint32 time_diff = compute_mm_time_diff(op->multi_media_time,
>> time);
>> +if (time_diff >= 0) {
>> decoder->cur_frame_msg = frame_msg;
>> -decoder->timer_id = g_timeout_add(d,
>> mjpeg_decoder_decode_frame, decoder);
>> +decoder->timer_id = g_timeout_add(time_diff,
>> mjpeg_decoder_decode_frame, decoder);
>> break;
>> }
>> 
>> -SPICE_DEBUG("%s: rendering too late by %u ms (ts: %u, mmtime:
>> %u), dropping ",
>> -__FUNCTION__, time - op->multi_media_time,
>> +SPICE_DEBUG("%s: rendering too late by %d ms (ts: %u, mmtime:
>> %u), dropping ",
>> +__FUNCTION__, -time_diff,
>> op->multi_media_time, time);
>> stream_dropped_frame_on_playback(decoder->base.stream);
>> spice_msg_in_unref(frame_msg);
>> @@ -249,7 +249,9 @@ static gboolean mjpeg_decoder_queue_frame(VideoDecoder
>> *video_decoder,
>> SpiceStreamDataHeader *last_op, *frame_op;
>> last_op = spice_msg_in_parsed(last_msg);
>> frame_op = spice_msg_in_parsed(frame_msg);
>> -if (frame_op->multi_media_time < last_op->multi_media_time) {
>> +gint32 time_diff =
>> +compute_mm_time_diff(frame_op->multi_media_time,
>> last_op->multi_media_time);
>> +if (time_diff < 0) {
>> /* This should really not happen */
>> 

Re: [Spice-devel] [spice-gtk 1/2] Fix possible multimedia time overflow

[Frediano Ziglio]

> > On 16 Mar 2017, at 11:56, Frediano Ziglio < fzig...@redhat.com > wrote:
> 

> > > - Original Message -
> > 
> 

> > > > > Hi
> > > > 
> > > 
> > 
> 

> > > > > - Original Message -
> > > > 
> > > 
> > 
> 

> > > > > > The multimedia time can easily overflow as is encoded in an
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > unsigned 32 bit and have a unit of milliseconds so it wrap
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > up every 49 days. Use some math that allow the number to overflow
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > without issues.
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > This could caused the client to stop handling streaming and
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > starting only queueing.
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > Signed-off-by: Frediano Ziglio < fzig...@redhat.com >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > ---
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > src/channel-display-gst.c | 11 ++-
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > src/channel-display-mjpeg.c | 14 --
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > src/channel-display-priv.h | 15 +++
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > 3 files changed, 29 insertions(+), 11 deletions(-)
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > This patch should be applied independently on 2/2 as intended to be
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > merged upstream as a fix while 2/2 depends on this as it change
> > > > > > same
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > code portions.
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > index c4190b2..9c62e67 100644
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > --- a/src/channel-display-gst.c
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > +++ b/src/channel-display-gst.c
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > @@ -183,8 +183,9 @@ static void schedule_frame(SpiceGstDecoder
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > *decoder)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > }
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > SpiceStreamDataHeader *op = spice_msg_in_parsed(frame->msg);
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > - if (now < op->multi_media_time) {
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > - decoder->timer_id = g_timeout_add(op->multi_media_time -
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > now,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > + gint32 time_diff = compute_mm_time_diff(op->multi_media_time,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > now);
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > + if (time_diff >= 0) {
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > + decoder->timer_id = g_timeout_add(time_diff,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > display_frame, decoder);
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > } else if (g_queue_get_length(decoder->display_queue) == 1) {
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > /* Still attempt to display the least out of date frame so
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > the
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > @@ -192,8 +193,8 @@ static void schedule_frame(SpiceGstDecoder
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > *decoder)
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > */
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > decoder->timer_id = g_timeout_add(0, display_frame,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > decoder);
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > } else {
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > - SPICE_DEBUG("%s: rendering too late by %u ms (ts: %u,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > mmtime:
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > %u), dropping",
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > - __FUNCTION__, now - op->multi_media_time,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > + SPICE_DEBUG("%s: rendering too late by %d ms (ts: %u,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > mmtime:
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > %u), dropping",
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > + __FUNCTION__, -time_diff,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > op->multi_media_time, now);
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > stream_dropped_frame_on_playback(decoder->base.stream);
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > g_queue_pop_head(decoder->display_queue);
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > @@ -431,7 +432,7 @@ static gboolean
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > spice_gst_decoder_queue_frame(VideoDecoder *video_decoder,
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > }
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > SpiceStreamDataHeader *frame_op = spice_msg_in_parsed(frame_msg);
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > - if (frame_op->multi_media_time < decoder->last_mm_time) {
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > + if 

Re: [Spice-devel] KVM-SPICE: View youtube videos smoothly

[Oscar Segarra]

Hi,

Bug open at:

https://bugs.freedesktop.org/show_bug.cgi?id=100251

Thanks a lot!


2017-03-17 9:55 GMT+01:00 Pavel Grunt :

> Hi Oscar,
>
> I have a guess but I really need more info and this is going off
> topic, can you please open a bug
> https://bugs.freedesktop.org/enter_bug.cgi?product=Spice=spi
> ce-gtk
>
> please provide rpm versions:
> rpm -q virt-manager spice-gtk3
>
> debug logs
>
> domain xml `virsh dumpxml VM`
>
> Thanks,
> Pavel
>
> On Fri, 2017-03-17 at 09:39 +0100, Oscar Segarra wrote:
> > Hi,
> >
> > I attach logs of virt-manager.
> >
> > I'd like to add that virt-viewer look work correctly.
> >
> > 2017-03-17 9:04 GMT+01:00 Pavel Grunt :
> > > On Fri, 2017-03-17 at 01:40 +0100, Oscar Segarra wrote:
> > > > Hi Pavel,
> > > >
> > > > I have installed the latest nightly build but I have not seen
> > > any
> > > > difference to adjust spice options:
> > > >
> > >
> > > The options to enable streaming are not there, use `virsh edit` as
> > > mentioned earlier
> > >
> > > if the vm is in the user session
> > >
> > > $ virsh edit VM
> > > for system session
> > >
> > > $ virsh -c qemu:///system edit VM
> > >
> > > if you are talking about the options to change video encoder, they
> > > are
> > > in spicy - install package spice-gtk-tools
> > >
> > > and use it in similar way to remote-viewer
> > >
> > > $ spicy
> > >
> > > or
> > >
> > > $ spice --uri spice://host:port
> > >
> > >
> > > >
> > > >
> > > > I have not experienced any performance improvement... Just, from
> > > the
> > > > virt-manager I'm not able to see my windows 10 desktop (it is
> > > > completely black) XS
> > > Interesting, try running SPICE_DEBUG=1 virt-manager --debug
> > > and post the output (preferable do a bug report)
> > >
> > > >
> > > > Am I looking at the correct place?
> > >
> > > >
> > > >
> > > >
> > > > From Remote Viewer I can see the desktop as usual (I'm upgrading
> > > > windows):
> > > >
> > > >
> > > >
> > > > May I revert the spice install in order to make my virt-manager
> > > work
> > > > properly again?
> > >
> > > Downgrading should help, but we would really welcome a bug report
> > > (providing rpm versions of virt-manager and spice packages) in
> > > order
> > > to fix the bug.
> > >
> > >
> > > Thanks,
> > > Pavel
> > > >
> > > > Thanks a lot.
> > > >
> > > >
> > > > 2017-03-09 13:24 GMT+01:00 Oscar Segarra  > > m>:
> > > > > Hi Pavel,
> > > > >
> > > > > Yes, in my configuration I have already set:
> > > > >
> > > > > vram: 64MB
> > > > > streaming mode='filter' <-- I have tested with 'all" as well
> > > with
> > > > > the same results
> > > > > image compression='auto_glz'
> > > > >
> > > > > When I connect through the Internet or from my home wi-fi
> > > (54Mbps)
> > > > > In the logs I can see "LOW BANDWITH" detected, and the video
> > > > > performance is really bad.
> > > > >
> > > > > Thanks a lot.
> > > > >
> > > > >
> > > > > 2017-03-09 13:14 GMT+01:00 Pavel Grunt :
> > > > > > On Thu, 2017-03-09 at 06:43 -0500, Frediano Ziglio wrote:
> > > > > > >
> > > > > > >
> > > > > > > It's not a small addition. Usually wifi has a much higher
> > > > > > latency
> > > > > > > then wired lan. For comparison on lan usually you
> > > > > > > have 2-4 ms latency while on wifi 80-100 ms unless you
> > > have
> > > > > > powerful
> > > > > > > and quite idle network infrastructure
> > > > > > > (but still higher than wired).
> > > > > > >
> > > > > > > Unfortunately currently the protocol implementation is
> > > quite
> > > > > > latency
> > > > > > > dependent.
> > > > > > >
> > > > > > > I don't think the latency here is an issue if you are
> > > using a
> > > > > > recent
> > > > > > > encoder (here some client
> > > > > > > guy should help on how to know the encoder used).
> > > > > >
> > > > > > Since you are on el7 system you can test our nightly builds:
> > > > > > https://copr.fedorainfracloud.org/coprs/g/spice/nightly/
> > > > > > which provides ability to switch the video encoder in spicy
> > > > > > (package
> > > > > > spice-gtk-tools) under Options menu.
> > > > > >
> > > > > > Your vm needs to have the video streaming enabled (set to
> > > > > > 'filter' or
> > > > > > 'all').
> > > > > >
> > > > > > (virsh edit VM ; and add  to graphics
> > > > > > node)
> > > > > >
> > > > > > Also check if the image compression is turned on (ideally
> > > set to
> > > > > > glz)
> > > > > >
> > > > > > Pavel
> > > > > >
> > > > > > > Sorry, was meaning bandwidth in the above sentence.
> > > > > > >
> > > > > > > About the lag recently we detected another issue in the
> > > > > > protocol
> > > > > > > implementation, hope
> > > > > > > we can tune and fix it in a short period.
> > > > > > >
> > > > > > > Frediano
> > > > > > >
> > > > > > >
> > > > > > > I'd like to add that the connection is via wi-fi (54Mbps).
> > > > > > >
> > > > > > > Is it enough for spice videos?
> > > > > > >
> > > > > > > thanks a lot.
> > > > 

Re: [Spice-devel] [spice-server v2 2/3] tests: Port test-qxl-parsing to GTest

[Pavel Grunt]

On Thu, 2017-03-16 at 16:10 +0100, Christophe Fergeau wrote:
> test-qxl-parsing is really a series of several tests. Porting it to
> GTest makes this more obvious. This also has the side-effect of
> making
> it more friendly to 'make check-valgrind' (which would fail on
> SIGALRM,
> and on unexpected g_warning()).
> ---
>  server/tests/Makefile.am|   1 +
>  server/tests/test-qxl-parsing.c | 212 -
> ---
>  2 files changed, 149 insertions(+), 64 deletions(-)
> 
> diff --git a/server/tests/Makefile.am b/server/tests/Makefile.am
> index 3f61faa..fc9e1f2 100644
> --- a/server/tests/Makefile.am
> +++ b/server/tests/Makefile.am
> @@ -124,6 +124,7 @@ test_vdagent_CPPFLAGS =   \
>   -UGLIB_VERSION_MAX_ALLOWED  \
>   $(NULL)
>  test_codecs_parsing_CPPFLAGS = $(test_vdagent_CPPFLAGS)
> +test_qxl_parsing_CPPFLAGS = $(test_vdagent_CPPFLAGS)
>  
>  if HAVE_GSTREAMER
>  test_gst_SOURCES = test-gst.c \
> diff --git a/server/tests/test-qxl-parsing.c b/server/tests/test-
> qxl-parsing.c
> index dd99150..f84f8c8 100644
> --- a/server/tests/test-qxl-parsing.c
> +++ b/server/tests/test-qxl-parsing.c
> @@ -32,25 +32,7 @@
>  #include 
>  #include "memslot.h"
>  #include "red-parse-qxl.h"
> -
> -static int exit_code = EXIT_SUCCESS;
> -static const char *test_name = NULL;
> -
> -static void
> -failure(void)
> -{
> -assert(test_name);
> -printf("Test %s FAILED!\n", test_name);
> -exit_code = EXIT_FAILURE;
> -}
> -
> -static void
> -test(const char *desc)
> -{
> -test_name = desc;
> -printf("Starting test %s\n", desc);
> -alarm(5);
> -}
> +#include "test-glib-compat.h"
>  
>  static inline QXLPHYSICAL
>  to_physical(const void *ptr)
> @@ -71,45 +53,77 @@ create_chunk(size_t prefix, uint32_t size,
> QXLDataChunk* prev, int fill)
>  return ptr;
>  }
>  
> -int main(int argc, char **argv)
> +static void init_meminfo(RedMemSlotInfo *mem_info)
>  {
> -RedMemSlotInfo mem_info;
> -memslot_info_init(_info, 1 /* groups */, 1 /* slots */, 1,
> 1, 0);
> -memslot_info_add_slot(_info, 0, 0, 0 /* delta */, 0 /*
> start */, ~0ul /* end */, 0 /* generation */);
> -
> -RedSurfaceCmd cmd;
> -QXLSurfaceCmd qxl;
> -
> -RedCursorCmd red_cursor_cmd;
> -QXLCursorCmd cursor_cmd;
> -QXLCursor *cursor;
> -QXLDataChunk *chunks[2];
> +memslot_info_init(mem_info, 1 /* groups */, 1 /* slots */, 1,
> 1, 0);
> +memslot_info_add_slot(mem_info, 0, 0, 0 /* delta */, 0 /* start
> */, ~0ul /* end */, 0 /* generation */);
> +}
>  
> +static void init_qxl_surface(QXLSurfaceCmd *qxl)
> +{
>  void *surface_mem;
>  
> -memset(, 0, sizeof(qxl));
> +memset(qxl, 0, sizeof(*qxl));
>  
> -qxl.surface_id = 123;
> +qxl->surface_id = 123;
>  
> -/* try to create a surface with no issues, should succeed */
> -test("no issues");
> -qxl.u.surface_create.format = SPICE_SURFACE_FMT_32_xRGB;
> -qxl.u.surface_create.width = 128;
> -qxl.u.surface_create.stride = 512;
> -qxl.u.surface_create.height = 128;
> +qxl->u.surface_create.format = SPICE_SURFACE_FMT_32_xRGB;
> +qxl->u.surface_create.width = 128;
> +qxl->u.surface_create.stride = 512;
> +qxl->u.surface_create.height = 128;
>  surface_mem = malloc(0x1);
> -qxl.u.surface_create.data = to_physical(surface_mem);
> -if (red_get_surface_cmd(_info, 0, , to_physical()))
> -failure();
> +qxl->u.surface_create.data = to_physical(surface_mem);
> +}
> +
> +static void deinit_qxl_surface(QXLSurfaceCmd *qxl)
> +{
> +free((void *)qxl->u.surface_create.data);

`make syntax-check` is failing because of this

> +}
> +
> +static void test_no_issues(void)
> +{
> +RedMemSlotInfo mem_info;
> +RedSurfaceCmd cmd;
> +QXLSurfaceCmd qxl;
> +
> +init_meminfo(_info);
> +init_qxl_surface();
> +
> +/* try to create a surface with no issues, should succeed */
> +g_assert_false(red_get_surface_cmd(_info, 0, ,
> to_physical()));
> +
> +deinit_qxl_surface();
> +memslot_info_destroy(_info);
> +}
> +
> +static void test_stride_too_small(void)
> +{
> +RedMemSlotInfo mem_info;
> +RedSurfaceCmd cmd;
> +QXLSurfaceCmd qxl;
> +
> +init_meminfo(_info);
> +init_qxl_surface();
>  
>  /* try to create a surface with a stride too small to fit
>   * the entire width.
>   * This can be used to cause buffer overflows so refuse it.
>   */
> -test("stride too small");
>  qxl.u.surface_create.stride = 256;
> -if (!red_get_surface_cmd(_info, 0, ,
> to_physical()))
> -failure();
> +g_assert_true(red_get_surface_cmd(_info, 0, ,
> to_physical()));
> +
> +deinit_qxl_surface();
> +memslot_info_destroy(_info);
> +}
> +
> +static void test_too_big_image(void)
> +{
> +RedMemSlotInfo mem_info;
> +RedSurfaceCmd cmd;
> +QXLSurfaceCmd qxl;
> +
> +init_meminfo(_info);
> +init_qxl_surface();
>  
>  /* try to create a surface quite large.
>  

[Spice-devel] [PATCH spice] Do not ignore errors

[Pavel Grunt]

---
I am not an expert on auto* and make, but `-k` should be enough to keep going 
over
all the tests.

Example of ci output thanks to this change:
 https://gitlab.com/xerus/spice/builds/12448734

https://gitlab.com/xerus/spice/commits/valgrind 
---
 m4/ax_valgrind_check.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/ax_valgrind_check.m4 b/m4/ax_valgrind_check.m4
index 3761fd5e..ab929623 100644
--- a/m4/ax_valgrind_check.m4
+++ b/m4/ax_valgrind_check.m4
@@ -187,7 +187,7 @@ endif
 # Use recursive makes in order to ignore errors during check
 check-valgrind:
 ifeq ($(VALGRIND_ENABLED),yes)
-   -$(A''M_V_at)$(foreach tool,$(valgrind_enabled_tools), \
+   $(A''M_V_at)$(foreach tool,$(valgrind_enabled_tools), \
$(MAKE) $(AM_MAKEFLAGS) -k check-valgrind-$(tool); \
)
 else
-- 
2.12.0

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

Re: [Spice-devel] [spice-server v2 0/3] Add make check-valgrind target

[Pavel Grunt]

On Fri, 2017-03-17 at 11:52 +0100, Pavel Grunt wrote:
> Hi,
> 
> all the tests are failing for me (F26) - probably many false
> positives
> https://da.gd/XUKa3 

Fixed by installing debuginfos

> 
> I tried to add it to our ci:
> https://gitlab.com/xerus/spice/builds/12438066
> but it also fails
> 
> On Thu, 2017-03-16 at 16:10 +0100, Christophe Fergeau wrote:
> > This adds a make check-valgrind target after fixing some minor
> > issues
> > preventing it from succeeding
> > 
> > Christophe
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk 1/2] Fix possible multimedia time overflow

[Christophe de Dinechin]

> On 16 Mar 2017, at 11:56, Frediano Ziglio  > wrote:
> 
>> 
>> - Original Message -
 
 Hi
 
 - Original Message -
> The multimedia time can easily overflow as is encoded in an
> unsigned 32 bit and have a unit of milliseconds so it wrap
> up every 49 days. Use some math that allow the number to overflow
> without issues.
> This could caused the client to stop handling streaming and
> starting only queueing.
> 
> Signed-off-by: Frediano Ziglio  >
> ---
> src/channel-display-gst.c   | 11 ++-
> src/channel-display-mjpeg.c | 14 --
> src/channel-display-priv.h  | 15 +++
> 3 files changed, 29 insertions(+), 11 deletions(-)
> 
> This patch should be applied independently on 2/2 as intended to be
> merged upstream as a fix while 2/2 depends on this as it change same
> code portions.
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index c4190b2..9c62e67 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -183,8 +183,9 @@ static void schedule_frame(SpiceGstDecoder
> *decoder)
> }
> 
> SpiceStreamDataHeader *op = spice_msg_in_parsed(frame->msg);
> -if (now < op->multi_media_time) {
> -decoder->timer_id = g_timeout_add(op->multi_media_time -
> now,
> +gint32 time_diff = compute_mm_time_diff(op->multi_media_time,
> now);
> +if (time_diff >= 0) {
> +decoder->timer_id = g_timeout_add(time_diff,
>   display_frame, decoder);
> } else if (g_queue_get_length(decoder->display_queue) == 1) {
> /* Still attempt to display the least out of date frame so
> the
> @@ -192,8 +193,8 @@ static void schedule_frame(SpiceGstDecoder
> *decoder)
>  */
> decoder->timer_id = g_timeout_add(0, display_frame,
> decoder);
> } else {
> -SPICE_DEBUG("%s: rendering too late by %u ms (ts: %u,
> mmtime:
> %u), dropping",
> -__FUNCTION__, now - op->multi_media_time,
> +SPICE_DEBUG("%s: rendering too late by %d ms (ts: %u,
> mmtime:
> %u), dropping",
> +__FUNCTION__, -time_diff,
> op->multi_media_time, now);
> stream_dropped_frame_on_playback(decoder->base.stream);
> g_queue_pop_head(decoder->display_queue);
> @@ -431,7 +432,7 @@ static gboolean
> spice_gst_decoder_queue_frame(VideoDecoder *video_decoder,
> }
> 
> SpiceStreamDataHeader *frame_op = spice_msg_in_parsed(frame_msg);
> -if (frame_op->multi_media_time < decoder->last_mm_time) {
> +if (compute_mm_time_diff(frame_op->multi_media_time,
> decoder->last_mm_time) < 0) {
> SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
> " resetting stream, id %u",
> frame_op->multi_media_time,
> diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
> index 722494e..1b7373b 100644
> --- a/src/channel-display-mjpeg.c
> +++ b/src/channel-display-mjpeg.c
> @@ -195,15 +195,15 @@ static void mjpeg_decoder_schedule(MJpegDecoder
> *decoder)
> do {
> if (frame_msg) {
> SpiceStreamDataHeader *op =
> spice_msg_in_parsed(frame_msg);
> -if (time <= op->multi_media_time) {
> -guint32 d = op->multi_media_time - time;
> +gint32 time_diff =
> compute_mm_time_diff(op->multi_media_time,
> time);
> +if (time_diff >= 0) {
> decoder->cur_frame_msg = frame_msg;
> -decoder->timer_id = g_timeout_add(d,
> mjpeg_decoder_decode_frame, decoder);
> +decoder->timer_id = g_timeout_add(time_diff,
> mjpeg_decoder_decode_frame, decoder);
> break;
> }
> 
> -SPICE_DEBUG("%s: rendering too late by %u ms (ts: %u,
> mmtime:
> %u), dropping ",
> -__FUNCTION__, time - op->multi_media_time,
> +SPICE_DEBUG("%s: rendering too late by %d ms (ts: %u,
> mmtime:
> %u), dropping ",
> +__FUNCTION__, -time_diff,
> op->multi_media_time, time);
> stream_dropped_frame_on_playback(decoder->base.stream);
> spice_msg_in_unref(frame_msg);
> @@ -249,7 +249,9 @@ static gboolean
> mjpeg_decoder_queue_frame(VideoDecoder
> *video_decoder,
> SpiceStreamDataHeader *last_op, 

Re: [Spice-devel] [spice-server v2 3/3] build-sys: Add make check-valgrind target

[Pavel Grunt]

Hi Christophe,

the return code is wrong for failing tests. It is always 0.

Pavel

On Thu, 2017-03-16 at 16:10 +0100, Christophe Fergeau wrote:
> This allows to run automatically our test-suite with valgrind to
> test
> for memory leaks.
---
>  Makefile.am |   3 +
>  configure.ac|   9 +
>  m4/ax_valgrind_check.m4 | 236 +++
>  server/Makefile.am  |   3 +
>  server/tests/Makefile.am|   4 +
>  server/tests/valgrind/glib.supp | 493
> 
>  6 files changed, 748 insertions(+)
>  create mode 100644 m4/ax_valgrind_check.m4
>  create mode 100644 server/tests/valgrind/glib.supp
> 
> diff --git a/Makefile.am b/Makefile.am
> index 5272d5a..9a073a1 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -3,6 +3,9 @@ ACLOCAL_AMFLAGS = -I m4
>  
>  SUBDIRS = spice-common server docs tools
>  
> +check-valgrind:
> + $(MAKE) -C server check-valgrind
> +
>  pkgconfigdir = $(libdir)/pkgconfig
>  pkgconfig_DATA = spice-server.pc
>  
> diff --git a/configure.ac b/configure.ac
> index f04585f..9fd455b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -116,6 +116,15 @@ AC_ARG_ENABLE([automated_tests],
>  AS_IF([test x"$enable_automated_tests" != "xno"],
> [enable_automated_tests="yes"])
>  AM_CONDITIONAL(HAVE_AUTOMATED_TESTS, test
> "x$enable_automated_tests" != "xno")
>  
> +dnl Check for the presence of Valgrind and do the plumbing to allow
> +dnl the running of "make check-valgrind".
> +AX_VALGRIND_DFLT(memcheck, on)
> +AX_VALGRIND_DFLT(helgrind, off)
> +AX_VALGRIND_DFLT(drd, off)
> +AX_VALGRIND_DFLT(sgcheck, off)
> +
> +AX_VALGRIND_CHECK
> +
>  SPICE_CHECK_LZ4
>  SPICE_CHECK_SASL
>  
> diff --git a/m4/ax_valgrind_check.m4 b/m4/ax_valgrind_check.m4
> new file mode 100644
> index 000..3761fd5
> --- /dev/null
> +++ b/m4/ax_valgrind_check.m4
> @@ -0,0 +1,236 @@
> +#
> 
> ===
> +#https://www.gnu.org/software/autoconf-archive/ax_valgrind_chec
> k.html
> +#
> 
> ===
> +#
> +# SYNOPSIS
> +#
> +#   AX_VALGRIND_DFLT(memcheck|helgrind|drd|sgcheck, on|off)
> +#   AX_VALGRIND_CHECK()
> +#
> +# DESCRIPTION
> +#
> +#   AX_VALGRIND_CHECK checks whether Valgrind is present and, if
> so, allows
> +#   running `make check` under a variety of Valgrind tools to check
> for
> +#   memory and threading errors.
> +#
> +#   Defines VALGRIND_CHECK_RULES which should be substituted in
> your
> +#   Makefile; and $enable_valgrind which can be used in subsequent
> configure
> +#   output. VALGRIND_ENABLED is defined and substituted, and
> corresponds to
> +#   the value of the --enable-valgrind option, which defaults to
> being
> +#   enabled if Valgrind is installed and disabled otherwise.
> Individual
> +#   Valgrind tools can be disabled via --disable-valgrind-,
> the
> +#   default is configurable via the AX_VALGRIND_DFLT command or is
> to use
> +#   all commands not disabled via AX_VALGRIND_DFLT. All
> AX_VALGRIND_DFLT
> +#   calls must be made before the call to AX_VALGRIND_CHECK.
> +#
> +#   If unit tests are written using a shell script and automake's
> +#   LOG_COMPILER system, the $(VALGRIND) variable can be used
> within the
> +#   shell scripts to enable Valgrind, as described here:
> +#
> +# https://www.gnu.org/software/gnulib/manual/html_node/Running-
> self_002dtests-under-valgrind.html
> +#
> +#   Usage example:
> +#
> +#   configure.ac:
> +#
> +# AX_VALGRIND_DFLT([sgcheck], [off])
> +# AX_VALGRIND_CHECK
> +#
> +#   Makefile.am:
> +#
> +# @VALGRIND_CHECK_RULES@
> +# VALGRIND_SUPPRESSIONS_FILES = my-project.supp
> +# EXTRA_DIST = my-project.supp
> +#
> +#   This results in a "check-valgrind" rule being added to any
> Makefile.am
> +#   which includes "@VALGRIND_CHECK_RULES@" (assuming the module
> has been
> +#   configured with --enable-valgrind). Running `make check-
> valgrind` in
> +#   that directory will run the module's test suite (`make check`)
> once for
> +#   each of the available Valgrind tools (out of memcheck, helgrind
> and drd)
> +#   while the sgcheck will be skipped unless enabled again on the
> +#   commandline with --enable-valgrind-sgcheck. The results for
> each check
> +#   will be output to test-suite-$toolname.log. The target will
> succeed if
> +#   there are zero errors and fail otherwise.
> +#
> +#   Alternatively, a "check-valgrind-$TOOL" rule will be added, for
> $TOOL in
> +#   memcheck, helgrind, drd and sgcheck. These are useful because
> often only
> +#   some of those tools can be ran cleanly on a codebase.
> +#
> +#   The macro supports running with and without libtool.
> +#
> +# LICENSE
> +#
> +#   Copyright (c) 2014, 2015, 2016 Philip Withnall  @collabora.co.uk>
> +#
> +#   Copying and distribution of this file, with or without
> modification, are
> +#   permitted in any medium without royalty provided 

Re: [Spice-devel] [spice-server v2 1/3] reds-stream: Don't use sendmsg with uninitialized memory

[Pavel Grunt]

Ack,
Pavel

On Thu, 2017-03-16 at 16:10 +0100, Christophe Fergeau wrote:
> On my 64 bit Fedora 25, CMSG_SPACE() adds 4 bytes of padding after
> the
> file descriptor in the control data. This causes warnings when ran
> under
> valgrind as we set msg_controllen to CMSG_SPACE().
> 
> This commit fills the control data to 0 to avoid these warnings.
> 
> ==30301== Syscall param sendmsg(msg.msg_control) points to
> uninitialised byte(s)
> ==30301==at 0x8127367: sendmsg (sendmsg.c:28)
> ==30301==by 0x41880B: reds_stream_send_msgfd (reds-stream.c:295)
> ==30301==by 0x40953F: main (test-stream.c:121)
> ==30301==  Address 0xffefff1b4 is on thread 1's stack
> ==30301==  in frame #1, created by reds_stream_send_msgfd (reds-
> stream.c:263)
> ---
>  server/reds-stream.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/server/reds-stream.c b/server/reds-stream.c
> index a813a8b..8ac296d 100644
> --- a/server/reds-stream.c
> +++ b/server/reds-stream.c
> @@ -283,6 +283,10 @@ int reds_stream_send_msgfd(RedsStream *stream,
> int fd)
>  if (fd != -1) {
>  msgh.msg_control = control.data;
>  msgh.msg_controllen = sizeof(control.data);
> +/* CMSG_SPACE() might be larger than CMSG_LEN() as it can
> include some
> + * padding. We set the whole control data to 0 to avoid
> valgrind warnings
> + */
> +memset(control.data, 0, sizeof(control.data));
>  
>  cmsg = CMSG_FIRSTHDR();
>  cmsg->cmsg_len = CMSG_LEN(fd_size);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] KVM-SPICE: View youtube videos smoothly

[Pavel Grunt]

Hi Oscar,

I have a guess but I really need more info and this is going off
topic, can you please open a bug
https://bugs.freedesktop.org/enter_bug.cgi?product=Spice=spi
ce-gtk

please provide rpm versions:
rpm -q virt-manager spice-gtk3

debug logs

domain xml `virsh dumpxml VM`

Thanks,
Pavel

On Fri, 2017-03-17 at 09:39 +0100, Oscar Segarra wrote:
> Hi, 
> 
> I attach logs of virt-manager.
> 
> I'd like to add that virt-viewer look work correctly.
> 
> 2017-03-17 9:04 GMT+01:00 Pavel Grunt :
> > On Fri, 2017-03-17 at 01:40 +0100, Oscar Segarra wrote:
> > > Hi Pavel, 
> > >
> > > I have installed the latest nightly build but I have not seen
> > any
> > > difference to adjust spice options:
> > >
> > 
> > The options to enable streaming are not there, use `virsh edit` as
> > mentioned earlier
> > 
> > if the vm is in the user session
> > 
> > $ virsh edit VM
> > for system session
> > 
> > $ virsh -c qemu:///system edit VM
> > 
> > if you are talking about the options to change video encoder, they
> > are
> > in spicy - install package spice-gtk-tools
> > 
> > and use it in similar way to remote-viewer
> > 
> > $ spicy
> > 
> > or
> > 
> > $ spice --uri spice://host:port
> > 
> > 
> > >
> > >
> > > I have not experienced any performance improvement... Just, from
> > the
> > > virt-manager I'm not able to see my windows 10 desktop (it is
> > > completely black) XS
> > Interesting, try running SPICE_DEBUG=1 virt-manager --debug
> > and post the output (preferable do a bug report)
> > 
> > >
> > > Am I looking at the correct place?
> > 
> > >
> > >
> > >
> > > From Remote Viewer I can see the desktop as usual (I'm upgrading
> > > windows):
> > >
> > >
> > >
> > > May I revert the spice install in order to make my virt-manager
> > work
> > > properly again?
> > 
> > Downgrading should help, but we would really welcome a bug report
> > (providing rpm versions of virt-manager and spice packages) in
> > order
> > to fix the bug.
> > 
> > 
> > Thanks,
> > Pavel
> > >
> > > Thanks a lot.
> > >
> > >
> > > 2017-03-09 13:24 GMT+01:00 Oscar Segarra  > m>:
> > > > Hi Pavel, 
> > > >
> > > > Yes, in my configuration I have already set:
> > > >
> > > > vram: 64MB
> > > > streaming mode='filter' <-- I have tested with 'all" as well
> > with
> > > > the same results
> > > > image compression='auto_glz'
> > > >
> > > > When I connect through the Internet or from my home wi-fi
> > (54Mbps)
> > > > In the logs I can see "LOW BANDWITH" detected, and the video
> > > > performance is really bad.
> > > >
> > > > Thanks a lot.
> > > >
> > > >
> > > > 2017-03-09 13:14 GMT+01:00 Pavel Grunt :
> > > > > On Thu, 2017-03-09 at 06:43 -0500, Frediano Ziglio wrote:
> > > > > >
> > > > > >
> > > > > > It's not a small addition. Usually wifi has a much higher
> > > > > latency
> > > > > > then wired lan. For comparison on lan usually you
> > > > > > have 2-4 ms latency while on wifi 80-100 ms unless you
> > have
> > > > > powerful
> > > > > > and quite idle network infrastructure
> > > > > > (but still higher than wired).
> > > > > >
> > > > > > Unfortunately currently the protocol implementation is
> > quite
> > > > > latency
> > > > > > dependent.
> > > > > >
> > > > > > I don't think the latency here is an issue if you are
> > using a
> > > > > recent
> > > > > > encoder (here some client
> > > > > > guy should help on how to know the encoder used).
> > > > >
> > > > > Since you are on el7 system you can test our nightly builds:
> > > > > https://copr.fedorainfracloud.org/coprs/g/spice/nightly/
> > > > > which provides ability to switch the video encoder in spicy
> > > > > (package
> > > > > spice-gtk-tools) under Options menu.
> > > > >
> > > > > Your vm needs to have the video streaming enabled (set to
> > > > > 'filter' or
> > > > > 'all').
> > > > >
> > > > > (virsh edit VM ; and add  to graphics
> > > > > node)
> > > > >
> > > > > Also check if the image compression is turned on (ideally
> > set to
> > > > > glz)
> > > > >
> > > > > Pavel
> > > > >
> > > > > > Sorry, was meaning bandwidth in the above sentence.
> > > > > >
> > > > > > About the lag recently we detected another issue in the
> > > > > protocol
> > > > > > implementation, hope
> > > > > > we can tune and fix it in a short period.
> > > > > >
> > > > > > Frediano
> > > > > >
> > > > > >
> > > > > > I'd like to add that the connection is via wi-fi (54Mbps).
> > > > > >
> > > > > > Is it enough for spice videos?
> > > > > >
> > > > > > thanks a lot.
> > > > > >
> > > > > > 2017-03-08 19:14 GMT+01:00 Oscar Segarra  > ail.
> > > > > com>:
> > > > > > > Hi, 
> > > > > > >
> > > > > > > Youtuve videos from virt-manager (locally) has an
> > acceptable
> > > > > > > bejaviour... but If I try to connect from the LAN, the
> > > > > behaviour
> > > > > > > is not acceptable... the sound goes much faster than the
> > > > > image.
> > > > > > >
> > > > > > > I have increased the video memory up to 

Re: [Spice-devel] KVM-SPICE: View youtube videos smoothly

[Oscar Segarra]

Hi,

I attach logs of virt-manager.

I'd like to add that virt-viewer look work correctly.

2017-03-17 9:04 GMT+01:00 Pavel Grunt :

> On Fri, 2017-03-17 at 01:40 +0100, Oscar Segarra wrote:
> > Hi Pavel,
> >
> > I have installed the latest nightly build but I have not seen any
> > difference to adjust spice options:
> >
>
> The options to enable streaming are not there, use `virsh edit` as
> mentioned earlier
>
> if the vm is in the user session
>
> $ virsh edit VM
> for system session
>
> $ virsh -c qemu:///system edit VM
>
> if you are talking about the options to change video encoder, they are
> in spicy - install package spice-gtk-tools
>
> and use it in similar way to remote-viewer
>
> $ spicy
>
> or
>
> $ spice --uri spice://host:port
>
>
> >
> >
> > I have not experienced any performance improvement... Just, from the
> > virt-manager I'm not able to see my windows 10 desktop (it is
> > completely black) XS
> Interesting, try running SPICE_DEBUG=1 virt-manager --debug
> and post the output (preferable do a bug report)
>
> >
> > Am I looking at the correct place?
>
> >
> >
> >
> > From Remote Viewer I can see the desktop as usual (I'm upgrading
> > windows):
> >
> >
> >
> > May I revert the spice install in order to make my virt-manager work
> > properly again?
>
> Downgrading should help, but we would really welcome a bug report
> (providing rpm versions of virt-manager and spice packages) in order
> to fix the bug.
>
>
> Thanks,
> Pavel
> >
> > Thanks a lot.
> >
> >
> > 2017-03-09 13:24 GMT+01:00 Oscar Segarra :
> > > Hi Pavel,
> > >
> > > Yes, in my configuration I have already set:
> > >
> > > vram: 64MB
> > > streaming mode='filter' <-- I have tested with 'all" as well with
> > > the same results
> > > image compression='auto_glz'
> > >
> > > When I connect through the Internet or from my home wi-fi (54Mbps)
> > > In the logs I can see "LOW BANDWITH" detected, and the video
> > > performance is really bad.
> > >
> > > Thanks a lot.
> > >
> > >
> > > 2017-03-09 13:14 GMT+01:00 Pavel Grunt :
> > > > On Thu, 2017-03-09 at 06:43 -0500, Frediano Ziglio wrote:
> > > > >
> > > > >
> > > > > It's not a small addition. Usually wifi has a much higher
> > > > latency
> > > > > then wired lan. For comparison on lan usually you
> > > > > have 2-4 ms latency while on wifi 80-100 ms unless you have
> > > > powerful
> > > > > and quite idle network infrastructure
> > > > > (but still higher than wired).
> > > > >
> > > > > Unfortunately currently the protocol implementation is quite
> > > > latency
> > > > > dependent.
> > > > >
> > > > > I don't think the latency here is an issue if you are using a
> > > > recent
> > > > > encoder (here some client
> > > > > guy should help on how to know the encoder used).
> > > >
> > > > Since you are on el7 system you can test our nightly builds:
> > > > https://copr.fedorainfracloud.org/coprs/g/spice/nightly/
> > > > which provides ability to switch the video encoder in spicy
> > > > (package
> > > > spice-gtk-tools) under Options menu.
> > > >
> > > > Your vm needs to have the video streaming enabled (set to
> > > > 'filter' or
> > > > 'all').
> > > >
> > > > (virsh edit VM ; and add  to graphics
> > > > node)
> > > >
> > > > Also check if the image compression is turned on (ideally set to
> > > > glz)
> > > >
> > > > Pavel
> > > >
> > > > > Sorry, was meaning bandwidth in the above sentence.
> > > > >
> > > > > About the lag recently we detected another issue in the
> > > > protocol
> > > > > implementation, hope
> > > > > we can tune and fix it in a short period.
> > > > >
> > > > > Frediano
> > > > >
> > > > >
> > > > > I'd like to add that the connection is via wi-fi (54Mbps).
> > > > >
> > > > > Is it enough for spice videos?
> > > > >
> > > > > thanks a lot.
> > > > >
> > > > > 2017-03-08 19:14 GMT+01:00 Oscar Segarra  > > > com>:
> > > > > > Hi,
> > > > > >
> > > > > > Youtuve videos from virt-manager (locally) has an acceptable
> > > > > > bejaviour... but If I try to connect from the LAN, the
> > > > behaviour
> > > > > > is not acceptable... the sound goes much faster than the
> > > > image.
> > > > > >
> > > > > > I have increased the video memory up to 64MB but I have not
> > > > > > experienced any improvement.
> > > > > >
> > > > > > Is there any way to diagnose this lag problems?
> > > > > >
> > > > > > Thanks a lot.
> > > > > >
> > > > > > 2017-03-03 22:45 GMT+01:00 Oscar Segarra  > > > l.com>
> > > > > > :
> > > > > > > Hi,
> > > > > > >
> > > > > > > After some research, I have been able to install a newer
> > > > version
> > > > > > > from:
> > > > > > >
> > > > > > > https://fedorapeople.org/groups/virt/virtio-win/direct-dow
> > > > nloads
> > > > > > > /archive-virtio/virtio-win-0.1.133-1/
> > > > > > >
> > > > > > > Now, Video has experienced a nice improvement... but sound
> > > > still
> > > > > > > "hangs"...
> > > > > > >
> > > > > > > Is 

Re: [Spice-devel] KVM-SPICE: View youtube videos smoothly

[Pavel Grunt]

On Fri, 2017-03-17 at 01:40 +0100, Oscar Segarra wrote:
> Hi Pavel, 
> 
> I have installed the latest nightly build but I have not seen any
> difference to adjust spice options:
> 

The options to enable streaming are not there, use `virsh edit` as
mentioned earlier 

if the vm is in the user session

$ virsh edit VM
for system session

$ virsh -c qemu:///system edit VM

if you are talking about the options to change video encoder, they are
in spicy - install package spice-gtk-tools

and use it in similar way to remote-viewer

$ spicy

or 

$ spice --uri spice://host:port


> 
> 
> I have not experienced any performance improvement... Just, from the
> virt-manager I'm not able to see my windows 10 desktop (it is
> completely black) XS
Interesting, try running SPICE_DEBUG=1 virt-manager --debug
and post the output (preferable do a bug report)

> 
> Am I looking at the correct place?

> 
> 
> 
> From Remote Viewer I can see the desktop as usual (I'm upgrading
> windows):
> 
> 
> 
> May I revert the spice install in order to make my virt-manager work
> properly again?

Downgrading should help, but we would really welcome a bug report
(providing rpm versions of virt-manager and spice packages) in order
to fix the bug.


Thanks,
Pavel
> 
> Thanks a lot.
> 
> 
> 2017-03-09 13:24 GMT+01:00 Oscar Segarra :
> > Hi Pavel, 
> > 
> > Yes, in my configuration I have already set:
> > 
> > vram: 64MB
> > streaming mode='filter' <-- I have tested with 'all" as well with
> > the same results
> > image compression='auto_glz'
> > 
> > When I connect through the Internet or from my home wi-fi (54Mbps)
> > In the logs I can see "LOW BANDWITH" detected, and the video
> > performance is really bad.
> > 
> > Thanks a lot.
> > 
> > 
> > 2017-03-09 13:14 GMT+01:00 Pavel Grunt :
> > > On Thu, 2017-03-09 at 06:43 -0500, Frediano Ziglio wrote:
> > > >
> > > >
> > > > It's not a small addition. Usually wifi has a much higher
> > > latency
> > > > then wired lan. For comparison on lan usually you
> > > > have 2-4 ms latency while on wifi 80-100 ms unless you have
> > > powerful
> > > > and quite idle network infrastructure
> > > > (but still higher than wired).
> > > >
> > > > Unfortunately currently the protocol implementation is quite
> > > latency
> > > > dependent.
> > > >
> > > > I don't think the latency here is an issue if you are using a
> > > recent
> > > > encoder (here some client
> > > > guy should help on how to know the encoder used).
> > > 
> > > Since you are on el7 system you can test our nightly builds:
> > > https://copr.fedorainfracloud.org/coprs/g/spice/nightly/
> > > which provides ability to switch the video encoder in spicy
> > > (package
> > > spice-gtk-tools) under Options menu.
> > > 
> > > Your vm needs to have the video streaming enabled (set to
> > > 'filter' or
> > > 'all').
> > > 
> > > (virsh edit VM ; and add  to graphics
> > > node)
> > > 
> > > Also check if the image compression is turned on (ideally set to
> > > glz)
> > > 
> > > Pavel
> > > 
> > > > Sorry, was meaning bandwidth in the above sentence.
> > > >
> > > > About the lag recently we detected another issue in the
> > > protocol
> > > > implementation, hope
> > > > we can tune and fix it in a short period.
> > > >
> > > > Frediano
> > > >
> > > >
> > > > I'd like to add that the connection is via wi-fi (54Mbps).
> > > >
> > > > Is it enough for spice videos?
> > > >
> > > > thanks a lot.
> > > >
> > > > 2017-03-08 19:14 GMT+01:00 Oscar Segarra  > > com>:
> > > > > Hi, 
> > > > >
> > > > > Youtuve videos from virt-manager (locally) has an acceptable
> > > > > bejaviour... but If I try to connect from the LAN, the
> > > behaviour
> > > > > is not acceptable... the sound goes much faster than the
> > > image.
> > > > >
> > > > > I have increased the video memory up to 64MB but I have not
> > > > > experienced any improvement.
> > > > >
> > > > > Is there any way to diagnose this lag problems?
> > > > >
> > > > > Thanks a lot.
> > > > >
> > > > > 2017-03-03 22:45 GMT+01:00 Oscar Segarra  > > l.com>
> > > > > :
> > > > > > Hi, 
> > > > > >
> > > > > > After some research, I have been able to install a newer
> > > version
> > > > > > from:
> > > > > >
> > > > > > https://fedorapeople.org/groups/virt/virtio-win/direct-dow
> > > nloads
> > > > > > /archive-virtio/virtio-win-0.1.133-1/
> > > > > >
> > > > > > Now, Video has experienced a nice improvement... but sound
> > > still
> > > > > > "hangs"...
> > > > > >
> > > > > > Is there any advice to customize sound?
> > > > > >
> > > > > > Thanks a lot.
> > > > > >
> > > > > > 2017-03-03 21:45 GMT+01:00 Pavel Grunt 
> > > :
> > > > > > > On Fri, 2017-03-03 at 20:19 +0100, Oscar Segarra wrote:
> > > > > > > > I must say the version is weird.
> > > > > > > > It is the version that comes with 2K8. I have not been
> > > able
> > > > > > > to find
> > > > > > > > the W10 qxl driver... ¿Can you paste