From: Christophe de Dinechin
The problem occurs when we call spice_playback_channel_set_delay before
the channel had received any data setting c->last_time, but after
session initialization had set mm_time in the session. The result was
that the (good) value in
This brings in 2 bug fixes, one of these is important on RHEL7 to
workaround an argparser bug with the python2 version it ships.
Signed-off-by: Christophe Fergeau
---
src/keycodemapdb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/keycodemapdb
- Original Message -
> This brings in 2 bug fixes, one of these is important on RHEL7 to
> workaround an argparser bug with the python2 version it ships.
>
> Signed-off-by: Christophe Fergeau
ack
> ---
> src/keycodemapdb | 2 +-
> 1 file changed, 1 insertion(+),
Hi,
On Thu, Jul 13, 2017 at 02:50:52PM +0200, Pavel Grunt wrote:
> On Thu, 2017-07-13 at 14:33 +0200, Victor Toso wrote:
> > From: Victor Toso
> >
> > This patch fixes the avdec_h264 element not being present on
> > gstvideo_has_codec() which get all decoder elements from
From: Christophe de Dinechin
The mm timer is a millisecond timer that wraps around after ~49 days.
All comparisons that look like a
---
src/channel-display-gst.c | 4 ++--
src/channel-display-mjpeg.c | 4 ++--
src/channel-display.c | 2 +-
src/channel-playback.c
Hi
- Original Message -
> On Thu, Jul 13, 2017 at 08:58:42AM -0400, Marc-André Lureau wrote:
> > Hi
> >
> > - Original Message -
> > > On Wed, Jul 12, 2017 at 03:20:26PM +, Marc-André Lureau wrote:
> > > > >
> > > > > This is the latest gettext release, which is not even 1
GST_DEBUG_GRAPH_SHOW_FULL_PARAMS is available since that
---
src/channel-display-gst.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 87e472c..fcb9e25 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@
On Thu, Jul 13, 2017 at 08:58:42AM -0400, Marc-André Lureau wrote:
> Hi
>
> - Original Message -
> > On Wed, Jul 12, 2017 at 03:20:26PM +, Marc-André Lureau wrote:
> > > >
> > > > This is the latest gettext release, which is not even 1 year old, is
> > > > this the only one which is
On Fri, 2017-06-30 at 12:51 +0200, Victor Toso wrote:
> From: Victor Toso
>
> Including some comment about current implementation of stream-id
> value
> in the Spice.
>
> Signed-off-by: Victor Toso
> ---
> src/channel-display.c | 42
- Original Message -
> On Thu, Jul 13, 2017 at 12:13:59PM -0400, Marc-André Lureau wrote:
> > Hi
> >
> > - Original Message -
> > > On Thu, Jul 13, 2017 at 08:58:42AM -0400, Marc-André Lureau wrote:
> > > > Hi
> > > >
> > > > - Original Message -
> > > > > On Wed, Jul
On Fri, 2017-06-30 at 12:51 +0200, Victor Toso wrote:
> From: Victor Toso
>
> Changing the name from clear_streams() to streams_finalize() to
> better
> match streams_check_init().
Since I was not really in favor of the new factored-out
streams_check_init() function, the
On Wed, Jul 12, 2017 at 03:20:26PM +, Marc-André Lureau wrote:
> >
> > This is the latest gettext release, which is not even 1 year old, is
> > this the only one which is going to work? Or is it possible to relax
> > this version chekc?
> >
>
> It's quite a mess to downgrade gettext or find
Hi
- Original Message -
> From: Christophe de Dinechin
>
> This patch series is a crude attempt at getting rid of the frames backlog
> when the spice client is overloaded. Another parameter I have been
> playing wiht is the max-bytes parameter in the GStreamer
>
From: Christophe de Dinechin
These two macros are intended to identify places in the code where there
are ad-hoc values that can be tweaked to optimize behavior. They may be
connected later to a mechanism that allows such "tweaks" to be made
without recompiling, e.g. by
From: Christophe de Dinechin
Experience has shown that if the machine running the guest is overloaded,
it may pile up a lot of backlog in the frames queue. This patch clears
the queue if it exceeds 100 entries. This value is arbitrary. It
corresponds to a few seconds on a
From: Christophe de Dinechin
This patch series is a crude attempt at getting rid of the frames backlog
when the spice client is overloaded. Another parameter I have been
playing wiht is the max-bytes parameter in the GStreamer
pipeline, which is currently set to 0
From: Christophe de Dinechin
The GStreamer configuration currently sets max-bytes=0 in the pipeline.
The rationale is that we need to be able to keep frames in case later frames
require them for decoding. However, having experienced scenarios where
spice would accumulate
- Original Message -
> From: Christophe de Dinechin
>
> Experience has shown that if the machine running the guest is overloaded,
> it may pile up a lot of backlog in the frames queue. This patch clears
> the queue if it exceeds 100 entries. This value is
Hi
- Original Message -
> On Wed, Jul 12, 2017 at 03:20:26PM +, Marc-André Lureau wrote:
> > >
> > > This is the latest gettext release, which is not even 1 year old, is
> > > this the only one which is going to work? Or is it possible to relax
> > > this version chekc?
> > >
> >
> >
If we are configured to use the systemd init script, also add support
for systemd socket activation. systemd will listen on the socket that is
used to communicate between the session agent and the system daemon.
When the session agent connects, the system daemon will automatically be
started. The
On Thu, Jul 13, 2017 at 12:13:59PM -0400, Marc-André Lureau wrote:
> Hi
>
> - Original Message -
> > On Thu, Jul 13, 2017 at 08:58:42AM -0400, Marc-André Lureau wrote:
> > > Hi
> > >
> > > - Original Message -
> > > > On Wed, Jul 12, 2017 at 03:20:26PM +, Marc-André Lureau
Hi
- Original Message -
> GST_DEBUG_GRAPH_SHOW_FULL_PARAMS is available since that
> ---
> src/channel-display-gst.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index 87e472c..fcb9e25 100644
> ---
Hello,
I noticed the release of spice-protocol 0.12.13 doesn't seem to have an
associated signature file, which is different from the last few years of
releases.
Is this a change in policy for spice-protocol?
Leo
signature.asc
Description: PGP signature
Hello guys!Sorry to interrupt you.I want to remote access to VM through
spice protocol instead of RDP protocol .I have read the offical website
about how to install SPICE throuth virt-manager or libvirt or QEMU.But the
content doesn`t refer to how to integrate SPICE with Openstack.Do you know
how
Hi,
On Tue, Jul 11, 2017 at 01:13:44PM +0200, Victor Toso wrote:
> Hi,
>
> On Tue, Jul 11, 2017 at 09:21:53AM +0200, Pavel Grunt wrote:
> > ---
> > v2:
> > - Use ngettext for error messages in plural
> > - rebased on top of Victor's patch
>
> Looks good
> Acked-by: Victor Toso
Hi,
In my comments below, I assume that if we are using a message for debug
purposes, we don't need to translate it. That is, if we GError* will not
be exported to the application.
Let me know if my assumption is wrong.
On Tue, Jul 11, 2017 at 03:43:41PM +0200, Pavel Grunt wrote:
>
Hi
I pushed my pending build-sys/gettext series, instead of a single patch.
The v1 was already reviewed, and I was going to send a v2 for final
comments. Since it's build-sys changes already reviewed, let's avoid the
churn of revert, and you can have a look at the commits for additional
fixup.
From: Marc-André Lureau
../../src/channel-display-gst.c: In function 'handle_pipeline_message':
../../src/channel-display-gst.c:289:75: error: format '%ld' expects argument of
type 'long int', but argument 2 has type 'gint64 {aka long long int}'
[-Werror=format=]
On Wed, Jul 12, 2017 at 10:02 AM Uri Lublin wrote:
> Hi Yuri,
>
> I'd mention in the Subject/Log that a device is now identified
> by its bus.addr instead of vid:pid.
>
> On 07/05/2017 08:21 AM, Yuri Benditovich wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1425961
> >
Hi,
On Thu, Jul 13, 2017 at 12:05:40PM +0200, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> ../../src/channel-display-gst.c: In function 'handle_pipeline_message':
> ../../src/channel-display-gst.c:289:75: error: format '%ld' expects argument
>
Pushed upstream,
Shortlog: file-xfer: Inform client of errors on init of xfer
Commit : c021bb051fac1b66199ea75ce10139f16b081f42
Victor Toso on Thu, 13 Jul 2017 12:23:43 +0200
On Tue, Jul 11, 2017 at 12:42:29PM +0200, Victor Toso wrote:
> From: Victor Toso
>
> With
On Wed, Jul 12, 2017 at 03:20:53PM -0400, Leo Famulari wrote:
> Hello,
>
> I noticed the release of spice-protocol 0.12.13 doesn't seem to have an
> associated signature file, which is different from the last few years of
> releases.
>
> Is this a change in policy for spice-protocol?
I believe
GStreamer's avdec_h264 needs h264parse to be able to process H264 video
streams. However the check for elements through GstRegistry forgot to
include the parsers, thus making spice-gtk to not set the relevant cap
to inform the server about H264 decoding capability.
---
src/channel-display-gst.c |
Hi,
On Thu, Jul 13, 2017 at 01:18:14PM +0200, Pavel Grunt wrote:
> On Thu, 2017-07-13 at 13:11 +0200, Victor Toso wrote:
> > On Thu, Jul 13, 2017 at 01:05:31PM +0200, Pavel Grunt wrote:
> > > GStreamer's avdec_h264 needs h264parse to be able to process H264 video
> > > streams. However the check
On Thu, 2017-07-13 at 13:22 +0200, Victor Toso wrote:
> Hi,
>
> On Thu, Jul 13, 2017 at 01:18:14PM +0200, Pavel Grunt wrote:
> > On Thu, 2017-07-13 at 13:11 +0200, Victor Toso wrote:
> > > On Thu, Jul 13, 2017 at 01:05:31PM +0200, Pavel Grunt wrote:
> > > > GStreamer's avdec_h264 needs h264parse
On Thu, Jul 13, 2017 at 01:05:31PM +0200, Pavel Grunt wrote:
> GStreamer's avdec_h264 needs h264parse to be able to process H264 video
> streams. However the check for elements through GstRegistry forgot to
> include the parsers, thus making spice-gtk to not set the relevant cap
> to inform the
Hi,
On Thu, Jul 13, 2017 at 01:11:00PM +0200, Victor Toso wrote:
> On Thu, Jul 13, 2017 at 01:05:31PM +0200, Pavel Grunt wrote:
> > GStreamer's avdec_h264 needs h264parse to be able to process H264 video
> > streams. However the check for elements through GstRegistry forgot to
> > include the
On Thu, 2017-07-13 at 13:11 +0200, Victor Toso wrote:
> On Thu, Jul 13, 2017 at 01:05:31PM +0200, Pavel Grunt wrote:
> > GStreamer's avdec_h264 needs h264parse to be able to process H264 video
> > streams. However the check for elements through GstRegistry forgot to
> > include the parsers, thus
From: Victor Toso
This patch fixes the avdec_h264 element not being present on
gstvideo_has_codec() which get all decoder elements from GstRegistry
and filter them on our GstCaps in order to get the ones for given
codec.
The issue is around the filtering. The current
On Thu, Jul 13, 2017 at 01:31:34PM +0200, Pavel Grunt wrote:
> On Thu, 2017-07-13 at 13:22 +0200, Victor Toso wrote:
> > Hi,
> >
> > On Thu, Jul 13, 2017 at 01:18:14PM +0200, Pavel Grunt wrote:
> > > On Thu, 2017-07-13 at 13:11 +0200, Victor Toso wrote:
> > > > On Thu, Jul 13, 2017 at 01:05:31PM
On Thu, 2017-07-13 at 14:33 +0200, Victor Toso wrote:
> From: Victor Toso
>
> This patch fixes the avdec_h264 element not being present on
> gstvideo_has_codec() which get all decoder elements from GstRegistry
> and filter them on our GstCaps in order to get the ones for
41 matches
Mail list logo