BTW
It is also recommended to apply this hack to avoid the ~400ms latency
diff --git a/src/channel-display.c b/src/channel-display.c
index 45fe38c..b41093b 100644
--- a/src/channel-display.c
+++ b/src/channel-display.c
@@ -1534,6 +1534,7 @@ static void
display_handle_stream_data(SpiceChannel *channel, SpiceMsgIn *in)
}
st->num_input_frames++;
+ op->multi_media_time = mmtime;
latency = op->multi_media_time - mmtime;
if (latency < 0) {
CHANNEL_DEBUG(channel, "stream data too late by %u ms (ts: %u,
mmtime: %u), dropping",
On 03/11/2018 11:44 AM, Snir Sheriber wrote:
This patch utilize the GstVideoOverlay interface when the
client is running under x window system and it receives a
full-screen stream that is decoded using gstreamer (gst =>
1.9.0)
Some notes
- It currently checks for full screen but probably a msg
says it is streaming mode would make more sense (is it?
i think frediano has a patch for that)
- Would it be possible to avoid spice rendering if it is not
a full screen?
- Does rendering directly from the decoder (channel-element)
breaks spice architecture?
- This currently seems stable and working well, it decreases
cpu (no pixman-cairo stuff) mainly in high resolutions but
needs to be tested with different plugins, windows...
- Not sure what is needed in order to make it to support
multi-monitor in the future.
- Currently works only with x (xid is transferred from
spice-widget to spice-gst-decoder which sets the overlay)
I'd be happy to hear more comments, ideas, patches ;)
Thanks, Snir.
Snir Sheriber (1):
Gstreamer: Use GstVideoOverlay if possible
src/channel-display-gst.c | 71 +++++++++++++++++++++++++++++++++++++----------
src/channel-display.c | 54 +++++++++++++++++++++++++++++++++++
src/spice-widget.c | 46 ++++++++++++++++++++++++++++++
3 files changed, 156 insertions(+), 15 deletions(-)
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel