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
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
___
Spice-devel
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
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
___
Spice-devel mai
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
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
---
src/channel-display-gst.c | 9
me 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
'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 named ones.
> And this patch is not fixing these macros.
It removes the LL suffix from NSEC_PER_SEC, thus making
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
o 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 bit.
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, spice
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.
https
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
+++ b/src
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
.
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 +-
3 files
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
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-gst.c | 105
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
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: Fix
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/gstreamer
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
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-display-gst.c | 105
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 we use
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/common
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
that 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 100644
nd 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 like it better.
I'
to 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
for 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
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 | 2
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 the LL
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
int32_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()
return a
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/server
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
ething we create with our hands? I mean, I know that current
> implementation will drop frames which we don't want but is it
> not a workaround of a bad implementation?
The answer depends in part on whether you consider the existing clients to
be a given that the server has to deal with, or so
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
___
ency 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
taken.
--
Francois Gouget
___
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
. 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?
--
Francois Gouget
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 <fgou...@codeweavers.com>
___
Spice-devel mailing list
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 <fgou...@codeweavers.com> commit 6a3bd17fa881c3d95c3c3e923161137e147660b6
Author: Francois Gouget <fgou...@codeweavers.com&
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
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 <fgou...@codeweavers.com>
__
contributors.
--
Francois Gouget <fgou...@codeweavers.com>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
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)(
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
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
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
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
Use the official case for Xfce.
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
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(-)
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
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..5
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
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:
* Aut
On Tue, 4 Apr 2017, Jonathon Jongsma wrote:
> Acked-by: Jonathon Jongsma <jjong...@redhat.com>
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 <fgou...@codeweavers.com>
&
On Tue, 4 Apr 2017, Jonathon Jongsma wrote:
> Acked-by: Jonathon Jongsma <jjong...@redhat.com>
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 <fgou...@codeweavers.com
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 <fgou...@codeweavers.com>
---
src/channel-display-gst.c
This makes it easier to reuse display_streams for other types of
video streams should the need arise.
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
src/channel-display.c | 110 --
1 file changed, 62 insertions(+), 48 del
This emphasizes that this structure is specific to the GStreamer
decoder.
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
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
alto
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 <fgou...@codeweavers.com>
---
src/channel-display-priv.h | 7 +++
src/channel-display.c
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
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
+++
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 SpiceGstFrame in the GStreamer
eue 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 compressed frame is freed in step 4 and
SpiceGstFrame, SpiceFrame and GstSample in step 9, many milliseconds
later.
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 <fgou...@codeweavers.com>
---
src/channel-display-gst.c
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 <fgou...@codeweavers.com>
---
src/channel-display-priv.
This makes it easier to reuse display_streams for other types of
video streams should the need arise.
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
src/channel-display.c | 110 --
1 file changed, 62 insertions(+), 48 del
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
management
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
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
Signed-off-by: Francois Gouget <fgou...@codeweavers.com>
---
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 5
ed to pass texture directly to VAAPI).
Interesting. Does it need the same type of GstVideoMeta data or some
other type of metadata?
Did you get the pipeline to work with VAAPI?
--
Francois Gouget <fgou...@codeweavers.com>
___
Spi
1 - 100 of 848 matches
Mail list logo
