Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 6fccf621..bd72625d 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -469,7 +469,7
This fixes building spice-gtk on Debian 10.
Signed-off-by: Francois Gouget
---
See https://github.com/mesonbuild/meson/issues/4720
tests/meson.build | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tests/meson.build b/tests/meson.build
index 57bd2cc5..bc5be5fd 100644
> Can I send an update to this patch ?
Sure.
I'm fine with the proposed changes.
--
Francois Gouget
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
may not be in sync across streams.
So I think the delay management should be handled globally too which I
think should be quite doable. But I have been busy with other stuff so I
did not get time to investigate and resubmit.
--
Francois Gouget
___
S
Signed-off-by: Francois Gouget
---
Just a minor patch partly inspired by a patch from Frediano Ziglio.
5975a98a94e0 at git://people.freedesktop.org/~fziglio/spice-protocol
The "client|server" comments bear verification: they're based on a
comment in do_client_monitors() in
Code dealing with nanosecond timestamps normally uses 64 bit integers
and not long long ints. So this makes it easier to print the value of
expressions using these constants.
Signed-off-by: Francois Gouget
---
v3: https://lists.freedesktop.org/archives/spice-devel/2019-June/049361.html
v4
being the case though.
I count 8 casts out of 26 instances of NSEC_PER_SEC and its derivatives.
Anyway, since there's opposition to the 'no cast' approach I'll send a
patch based on INT64_C() instead.
--
Francois Gouget
_
margin_spread) to
avoid nudging the delay in response to minor random variations.
Signed-off-by: Francois Gouget
---
v3: Many changes based on previous feedback.
src/channel-display-gst.c | 20 ++--
src/channel-display-mjpeg.c | 14 +--
src/channel-display-priv.h | 24 -
src/channel
display_handle_stream_data() now has its own mechanism to avoid
dropping frames which does not depend on the playback latency.
Signed-off-by: Francois Gouget
---
src/channel-display-priv.h | 2 --
src/channel-display.c | 8
src/channel-playback-priv.h | 1 -
src/channel
The frame display time is no longer based on the mmtime clock and thus
is not impacted by mmtime offset changes.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 21 -
src/channel-display-mjpeg.c | 13
src/channel-display-priv.h | 3 --
src/channel
More data helps improve the accuracy of the estimation of the true clock
offset and minimum network latency.
Signed-off-by: Francois Gouget
---
src/channel-playback.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/channel-playback.c b/src/channel-playback.c
Each video and audio stream has its own lag: for video streams it is
the decoding time and for audio ones buffering by the audio subsystem.
The only way to keep them all in sync is to synchronize to the most
laggy stream.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 9
Signed-off-by: Francois Gouget
---
src/channel-display-mjpeg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
index 20e10d9b..764f0611 100644
--- a/src/channel-display-mjpeg.c
+++ b/src/channel-display-mjpeg.c
@@ -189,6 +189,9
was likely caused by a server migration.
> > + * Reset the time offset.
> > + */
>
> Was this tested? Is there no other event to specifically detect migration?
I added code to simulate a migration based on the
display_session_mm_time_reset_cb() comment in channel-display.c. But I
have no way of actually testing it.
> We (the client) needs to reconnect during migration so surely there's
> another event during this change.
The problem as I understand it is that the playback channel may be
migrated and start receiving new mmtime timestamps before the old video
stream has been shut down. This can result in a discrepency in the
time base and if there is a clean way to detect and deal with it that
comment does not say how.
> > +s->client_time_offset = new_offset;
> > +return now;
> > +}
> > +if (new_offset < s->client_time_offset) {
> > +/* The previous message we used to compute the offset was probably
> > + * delayed resulting in a too large offset. Eventually the offset
> > + * should settle to the true clock offset plus the network latency,
> > + * excluding the network jitter.
> > + */
>
> A bit OT: maybe would be great to have the "client time" when we start
> receiving
> the message from the server instead of taking the time after the full message
> arrives. Should be more consistent with server mmtime changes (server
> timestamp
> messages before sending).
I don't think that's possible without having lower layers know way too
much for their own good.
--
Francois Gouget
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
have the same issue too, isn't it?
No. If I want to trace a 64 bit variable I just use %ld/%lu and that's
it. No need to look at utils.h to refresh my memory on whether a
specific macro is a long long unlike all the other similarly name
e constants are used as arguments to a
printf()-equivalent that the LL trap is sprung. And I'd argue this is
not a case where there's much of an overflow risk to start with, and not
one where it would even matter much since most of those are temporary
one-off debugging traces.
--
Francois Gouget
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
avoid the long vs long long confusion (such as in print
> >> statements).
> >> Also some of the expressions these constants are used in may overflow so
> >> perform the appropriate casts in those locations. This makes it clearer
> >> that these operations are 64
We don't want to maintain more macros than necessary and these have
been unused for over two years.
Signed-off-by: Francois Gouget
---
v2: Remove unused macros altogether rather than marking them as
deprecated (no use of them has been found in spice, spice-gtk,
spice-common,
s are reinstated.
Signed-off-by: Francois Gouget
---
I noticed that this patch fell off despite what looked like general
agreement. I re-grepped for these macros and did not find them used in
the current Spice codebase which means they have not been used for at
least two years.
ally make sense so it is better to use the prefix to indicate
what they are related to such as the frame or the current time.
[...]
> > - guint32 server_mmtime,
> > - guint32 client_mmtime)
> > +
Signed-off-by: Francois Gouget
---
src/channel-display-mjpeg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
index 20e10d9b..764f0611 100644
--- a/src/channel-display-mjpeg.c
+++ b/src/channel-display-mjpeg.c
@@ -189,6 +189,9
Each video and audio stream has its own lag: for video streams it is
the decoding time and for audio ones buffering by the audio subsystem.
The only way to keep them all in sync is to synchronize to the most
laggy stream.
Signed-off-by: Francois Gouget
---
There may be a thread conetxt issue
display_handle_stream_data() now has its own mechanism to avoid
dropping frames which does not depend on the playback latency.
Signed-off-by: Francois Gouget
---
src/channel-display-priv.h | 2 --
src/channel-display.c | 8
src/channel-playback-priv.h | 1 -
src/channel
They are however tied to the frame.
Signed-off-by: Francois Gouget
---
src/channel-display.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/channel-display.c b/src/channel-display.c
index cda0fcdd..b26326d6 100644
--- a/src/channel-display.c
+++
The frame display time is no longer based on the mmtime clock and thus
is not impacted by mmtime offset changes.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 21 -
src/channel-display-mjpeg.c | 13
src/channel-display-priv.h | 3 --
src/channel
More data helps improve the accuracy of the estimation of the true clock
offset and minimum network latency.
Signed-off-by: Francois Gouget
---
src/channel-playback.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/channel-playback.c b/src/channel-playback.c
e new name.
Signed-off-by: Francois Gouget
---
It's less confusing when using the right terminology so I'm starting
with this before the more involved patches.
src/channel-display-gst.c | 6 +++---
src/channel-display-mjpeg.c | 4 ++--
src/channel-display.c | 26 +--
nudging the delay in response to minor random variations.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 22 ++---
src/channel-display-mjpeg.c | 14 +--
src/channel-display-priv.h | 18 +++-
src/channel-display.c | 178
src/spice
or more
frame intervals.
Signed-off-by: Francois Gouget
---
v2: Renamed rank to queue_len.
Moved it to the last position in the statistics string.
src/channel-display-gst.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/channel-display-gst.c b/src
Take into account changes made in 8835e757922c, 8c2101254051 and
possibly other other commits.
Add MAX_DECODED_FRAMES to define how many decoded frames GStreamer
should queue.
Signed-off-by: Francois Gouget
---
v2: No change.
src/channel-display-gst.c | 63
frame is
available.
Note that even so the decoding time may be overestimated as the frame
may have been waiting for a while in encoded form for a spot to be freed
in the GStreamer pipeline's sink queue.
Signed-off-by: Francois Gouget
---
v2: No change.
src/channel-display-g
Signed-off-by: Francois Gouget
---
v2: No change.
src/channel-display-gst.c | 81 ---
1 file changed, 42 insertions(+), 39 deletions(-)
diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 91ece0fa..ec8a7d39 100644
--- a/src/channel
knows immediately when a frame is late and has
all the information it needs to figure out how much buffering is needed.
So this is the approach taken in this patchset. See patch 7 and up for
more details.
Francois Gouget (12):
gstreamer: Avoid a couple of forward function declarations
gstreamer: Fi
rform the appropriate casts in those locations. This makes it clearer
that these operations are 64 bit.
Signed-off-by: Francois Gouget
---
v3: Turned all the timeout constants with casts to int64_t.
server/common-graphics-channel.h | 2 +-
server/dcc.h | 2 +-
server/gstr
On Fri, 14 Jun 2019, Frediano Ziglio wrote:
> >
> > Signed-off-by: Francois Gouget
>
> Considering that the field is public and that code will get
> slower and bigger at least would be good to describe the reason
> why you consider it better.
Consistency mostly. This
oon as the decoded frame is
available.
Note that even so the decoding time may be overestimated as the frame
may have been waiting for a while in encoded form for a spot to be freed
in the GStreamer pipeline's sink queue.
Signed-off-by: Francois Gouget
---
src/channel-disp
or more
frame intervals.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index fc338dff..b8f0c2ee 100644
--- a/src/channel-display-gst.c
+++ b/src/channel
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 81 ---
1 file changed, 42 insertions(+), 39 deletions(-)
diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index c756f916..50f29060 100644
--- a/src/channel-display-gst.c
+++ b
Take into account changes made in 8835e757922c, 8c2101254051 and
possibly other other commits.
Add MAX_DECODED_FRAMES to define how many decoded frames GStreamer
should queue.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 63 +++
1 file
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 91ece0fa..c756f916 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -278,7 +278,7
On Wed, 12 Jun 2019, Snir Sheriber wrote:
> Hi,
>
> On 6/11/19 9:42 PM, Francois Gouget wrote:
> > schedule_frame() only pulls frames out of GStreamer's pipeline once all
> > previous decoded frames have been displayed. Thus when the video delay
>
>
> IIRC w
rform the appropriate casts in those locations. This makes it clearer
that these operations are 64 bit.
Signed-off-by: Francois Gouget
---
v2: Cast COMMON_CLIENT_TIMEOUT to an int64_t instead of an uint64_t.
v1: https://lists.freedesktop.org/archives/spice-devel/2019-May/049193.html
server/c
This constant fits in a regular 32 bit signed integer so it does not
need the suffix.
It is also not used in expressions that may overflow.
Signed-off-by: Francois Gouget
---
v2: No changes.
v1: https://lists.freedesktop.org/archives/spice-devel/2019-May/049193.html
server/utils.h | 2 +-
1
t there is no extra delay in either case.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 183 --
1 file changed, 96 insertions(+), 87 deletions(-)
diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 91ece0fa..fed73592 10
and I occasionally had the
"rendering too late" trace which did not seem right.
> > Also reverse the inequality to make it easier to understand.
>
> That's relative but I don't mind ;)
Sure but it looks more like "frame->time >= now" so I lik
understand.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 858e8aeb..91ece0fa 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
r the first frame in
spice_gst_decoder_queue_frame() if the uptime was greater than about
25 days.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 88918f10..858e8aeb 100644
This constant fits in a regular 32 bit signed integer so it does not
need the suffix.
It is also not used in expressions that may overflow.
Signed-off-by: Francois Gouget
---
server/utils.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/utils.h b/server/utils.h
index
ow so
perform the appropriate casts in those locations. This makes it clearer
that these operations are 64 bit.
Signed-off-by: Francois Gouget
---
server/common-graphics-channel.h | 2 +-
server/dcc.h | 2 +-
server/gstreamer-encoder.c | 2 +-
server/mjpeg-encoder.c
compilation errors.
Finally, while the main NSEC_PER_* constants fit in 32 bit some of the
derived ones such as COMMON_CLIENT_TIMEOUT don't. For those use an
uint64_t cast rather than an LL suffix to avoid the %ld vs. %lld
confusion (again for debugging).
Francois Gouget (2):
utils: Remove t
Signed-off-by: Francois Gouget
---
server/mjpeg-encoder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/mjpeg-encoder.c b/server/mjpeg-encoder.c
index 1400519bb..b03fffe14 100644
--- a/server/mjpeg-encoder.c
+++ b/server/mjpeg-encoder.c
@@ -335,13 +335,13
This reduces code duplication and passing the MJpegEncoder object
makes it possible to modify the playback calculation without adding
more arguments.
Signed-off-by: Francois Gouget
---
v2: Reduced the diff and constified the MJpegEncoder* parameter.
server/mjpeg-encoder.c | 20
Signed-off-by: Francois Gouget
---
server/gstreamer-encoder.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/server/gstreamer-encoder.c b/server/gstreamer-encoder.c
index 110d12981..cae22c100 100644
--- a/server/gstreamer-encoder.c
+++ b/server
Signed-off-by: Francois Gouget
---
server/gstreamer-encoder.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/server/gstreamer-encoder.c b/server/gstreamer-encoder.c
index bccbe0660..110d12981 100644
--- a/server/gstreamer-encoder.c
+++ b/server/gstreamer-encoder.c
@@ -404,6 +404,13
It makes no sense to expect average frame sizes anywhere close to 2GB.
But then make sure to avoid arithmetic overflows.
Signed-off-by: Francois Gouget
---
In get_min_playback_delay() I opted for the cast approach as this makes
what happens clearer. I deemed the assignment (uint32_t
The source framerate is as important as the resolution when trying to
understand if the system should be fast enough to encode the video
stream in real time.
Signed-off-by: Francois Gouget
---
v2: Tweaked the message.
server/gstreamer-encoder.c | 2 +-
1 file changed, 1 insertion(+), 1
rns uint32_t but you should
> change above line to
>
>uint32_t send_time = (uint32_t) ((uint64_t) (MSEC_PER_SEC * 8) * size /
> encoder->bit_rate);
>
> or leave size uint64_t.
I would be ok with that too. It's mostly having get_average_frame_size()
On Thu, 16 May 2019, Frediano Ziglio wrote:
> >
> > It makes no sense to expect average frame sizes anywhere close to 2GB.
> >
> > Signed-off-by: Francois Gouget
>
> Sure but 256 kb are possible.
Even multiplied by two that fits pretty well in a 32 signed
This reduces code duplication and passing the MJpegEncoder object
makes it possible to modify the playback calculation without adding
more arguments.
Signed-off-by: Francois Gouget
---
server/mjpeg-encoder.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions
adjusting the client mm_time whenever playing a silent
video (or full desktop stream) when no sound has been played before
such as when using Xspice, booting an OS with no startup or login
jingle, or possibly when migrating a VM (per commit 1c154ea5ecc3).
Signed-off-by: Francois Gouget
---
server
It makes no sense to expect average frame sizes anywhere close to 2GB.
Signed-off-by: Francois Gouget
---
server/gstreamer-encoder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/gstreamer-encoder.c b/server/gstreamer-encoder.c
index e319eea22..6130781da 100644
This way all the minimum delay calculation is in one place and this
makes gstreamer's implementation closer to the mjpeg one.
Signed-off-by: Francois Gouget
---
server/gstreamer-encoder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/gstreamer-encoder.c b/s
The source framerate is as important as the resolution when trying to
understand if the system should be fast enough to encode the video
stream in real time.
Signed-off-by: Francois Gouget
---
server/gstreamer-encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server
Signed-off-by: Francois Gouget
---
server/mjpeg-encoder.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/server/mjpeg-encoder.c b/server/mjpeg-encoder.c
index b373e8b71..1400519bb 100644
--- a/server/mjpeg-encoder.c
+++ b/server/mjpeg-encoder.c
@@ -38,7 +38,6 @@ static const int
using them to be dropped. So more care must be
> > taken.
> >
>
> Is the problem of "care to take" something not avoidable or is it
> something we create with our hands? I mean, I know that current
> implementation will drop frames which we don't want but is it
monstrated it ?
Starting Xspice (so no Windows jingle or other being played on startup),
playing a WebGL demo, and then trying to figure out why the server's
latency adjustments had absolutely no effect on the client.
--
Francois Gouget
___
d decreasing the latency.
Increasing the latency means a frame queued on the client will be
displayed even later. So the latency can be increased freely.
Decreasing the latency means a bunch of frames queued on the client may
suddenly become late, causing them to be dropped. So more care must be
On Thu, 11 Apr 2019, Victor Toso wrote:
> Hi,
>
> On Wed, Apr 10, 2019 at 11:25:17AM +0200, Francois Gouget wrote:
> > We send mm_time adjustments to the client whenever there is no audio
> > playback. There is no audio playback on startup. Therefore
> > mm_time_enab
Signed-off-by: Francois Gouget
---
server/video-stream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/video-stream.c b/server/video-stream.c
index 197950984..ba1a5adf2 100644
--- a/server/video-stream.c
+++ b/server/video-stream.c
@@ -675,7 +675,7 @@ static void
We send mm_time adjustments to the client whenever there is no audio
playback. There is no audio playback on startup. Therefore
mm_time_enabled must be true on startup. QED.
Signed-off-by: Francois Gouget
---
server/reds.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/server/reds.c b
Based on a patch by Frediano Ziglio.
Signed-off-by: Francois Gouget
---
server/red-qxl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/red-qxl.c b/server/red-qxl.c
index 0dd26b22c..789817f69 100644
--- a/server/red-qxl.c
+++ b/server/red-qxl.c
@@ -791,7 +791,7
dcc_create_surface() already returns immediately if dcc is NULL.
Signed-off-by: Francois Gouget
---
server/dcc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/server/dcc.c b/server/dcc.c
index a05b6e59e..b6cd6b3f9 100644
--- a/server/dcc.c
+++ b/server/dcc.c
@@ -303,8
Signed-off-by: Francois Gouget
---
server/dcc.c | 2 +-
server/display-channel.c | 16
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/server/dcc.c b/server/dcc.c
index ae7b4380f..a05b6e59e 100644
--- a/server/dcc.c
+++ b/server/dcc.c
@@ -579,7 +579,7
lated. There is also a plain virgl branch but that one seems even
older.
https://cgit.freedesktop.org/~fziglio/qemu/log/?h=virgl-spice
This one would not be needed for Xspice but I may use it for
reference.
And there has been no Virgl work on the Xspice side of things, right?
--
l push with my variant, and we can revise how this all works and
> make this optional when/if the code you alude to gets public :)
Sure. That totally works for me!
--
Francois Gouget
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.or
be easy for me to adjust to.
(And I apologize for the delay, my Internet connection broke down last
week and then I was away for the extended week-end)
--
Francois Gouget commit 6a3bd17fa881c3d95c3c3e923161137e147660b6
Author: Francois Gouget
Date: Fri May 20 19:32:42 2016 +020
On Thu, 6 Apr 2017, Francois Gouget wrote:
> Currently the video decoders are directly passed network messages which
> ties them pretty closely to the network code. Should the protocol switch
> to a new type of messages the video decoding code will need to be
> updated. Even wo
e that spelling if British English is the standard in Spice.
https://en.oxforddictionaries.com/definition/non-existent
But as far as I can tell the form with a space and the -ing ending is
not valid at all.
--
Francois Gouget
___
Spice
e
tiny circle of core contributors.
--
Francois Gouget
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Signed-off-by: Francois Gouget
---
src/udscs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/udscs.h b/src/udscs.h
index 6160568..7b6bff0 100644
--- a/src/udscs.h
+++ b/src/udscs.h
@@ -53,7 +53,7 @@ typedef void (*udscs_read_callback)(struct udscs_connection
**connp
Signed-off-by: Francois Gouget
---
src/vdagentd/console-kit.c | 2 +-
src/vdagentd/vdagentd.c| 2 +-
src/vdagentd/virtio-port.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/vdagentd/console-kit.c b/src/vdagentd/console-kit.c
index a939f38..9e46ad5 100644
--- a
Signed-off-by: Francois Gouget
---
data/spice-vdagentd.1.in | 2 +-
src/vdagentd/console-kit.c | 2 +-
src/vdagentd/vdagentd.c| 4 ++--
src/vdagentd/virtio-port.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/data/spice-vdagentd.1.in b/data/spice-vdagentd.1.in
Use the official case for Xfce.
Signed-off-by: Francois Gouget
---
src/vdagent/vdagent.c | 2 +-
src/vdagent/x11-priv.h | 2 +-
src/vdagent/x11-randr.c | 6 +++---
src/vdagent/x11.c | 10 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/vdagent
Signed-off-by: Francois Gouget
---
data/spice-vdagent.1.in | 2 +-
src/vdagent/file-xfers.c | 4 ++--
src/vdagent/x11-randr.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/data/spice-vdagent.1.in b/data/spice-vdagent.1.in
index f8547d4..590efa5 100644
--- a/data/spice
Signed-off-by: Francois Gouget
---
Note: I don't have commit access.
README | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 0cd42d0..2eefbc4 100644
--- a/README
+++ b/README
@@ -20,12 +20,12 @@ Features:
* Automatic adjustment of the X-se
On Tue, 4 Apr 2017, Jonathon Jongsma wrote:
> Acked-by: Jonathon Jongsma
Could you or someone else please commit this patch?
> On Tue, 2017-04-04 at 17:02 +0200, Francois Gouget wrote:
> > Signed-off-by: Francois Gouget
> > ---
> > src/mspace.c| 8 +++
On Tue, 4 Apr 2017, Jonathon Jongsma wrote:
> Acked-by: Jonathon Jongsma
Could you or someone else please commit this patch?
> On Tue, 2017-04-04 at 17:00 +0200, Francois Gouget wrote:
> > Signed-off-by: Francois Gouget
> > ---
> > README
This improves the separation between networking and the video decoding
components.
It also makes it easier to reuse the latter should the client one day
receive video streams through other messages.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 79
This makes it easier to reuse display_streams for other types of
video streams should the need arise.
Signed-off-by: Francois Gouget
---
src/channel-display.c | 110 --
1 file changed, 62 insertions(+), 48 deletions(-)
diff --git a/src/channel
This emphasizes that this structure is specific to the GStreamer
decoder.
Signed-off-by: Francois Gouget
---
I also removed the underscore in the SpiceFrame struct. It's not used
anywhere else so this has no impact. This name could probably be removed
altogether but naming the structs
This regroups all the parsing in one place and makes the rest of the
display_stream code independent from the network messaging details.
Signed-off-by: Francois Gouget
---
src/channel-display-priv.h | 7 +++
src/channel-display.c | 37 ++---
2 files
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index c4190b2d..7e0ddde4 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
two patches
are ok but not patch 3, please apply the first two so the next round has
fewer patches.
Francois Gouget (5):
streaming: Document the GStreamer decoding process
streaming: Move SpiceMsgIn parsing to display_handle_stream_create()
streaming: Rename SpiceFrame to SpiceGstFr
ay now be only 30 ms away.
8) display_frame() pops the first SpiceMetaFrame from the display_queue and
calls stream_display_frame() right on time.
9) display_frame() then frees the SpiceMetaFrame and the SpiceFrame and
decompressed frame with it.
So as I was saying earlier the comp
Code-wise this improves the separation between networking and the video
decoding.
It also makes it easier to reuse the latter should the client one day
receive video streams through other messages.
Signed-off-by: Francois Gouget
---
src/channel-display-gst.c | 128
Code-wise this improves the separation between networking and the video
decoding.
It also makes it easier to reuse the latter should the client one day
receive video streams through other messages.
Signed-off-by: Francois Gouget
---
src/channel-display-priv.h | 7 +++
src/channel-display.c
This makes it easier to reuse display_streams for other types of
video streams should the need arise.
Signed-off-by: Francois Gouget
---
src/channel-display.c | 110 --
1 file changed, 62 insertions(+), 48 deletions(-)
diff --git a/src/channel
he network messages leading to their creation /
destruction.
Francois Gouget (3):
streaming: Remove the display_stream dependency on SpiceMsgIn messages
streaming: Remove the video decoder's dependency on SpiceMsgIn
messages
streaming: Separate the network code from the display_stream
Signed-off-by: Francois Gouget
---
src/mspace.c| 8
src/qxl_mem.c | 2 +-
src/spiceqxl_display.c | 2 +-
src/spiceqxl_io_port.c | 2 +-
src/spiceqxl_main_loop.c| 2 +-
src/spiceqxl_spice_server.c | 2 +-
src/uxa/uxa.h | 2 +-
7
Signed-off-by: Francois Gouget
---
README | 2 +-
README.xspice | 2 +-
src/spiceccid/spice.pcsc.conf.template | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 5ae3a59..92bb579 100644
--- a
1 - 100 of 892 matches
Mail list logo
