[Spice-devel] [PATCH v10 00/27] Add GStreamer support for video streaming

[Francois Gouget]

On Mon, 21 Mar 2016, Francois Gouget wrote:
[...]
> I think I have reproduced this though it's not systematic. Setting 
> GST_DEBUG=4 I noticed some messages indicating that the process is 
> running out of file descriptors. Indeed a look into /proc showed 4096 
> file descriptors open.

This was a red herring. The bug was in one of my local patches tracing 
the messages on the pipeline's bus. It was not unref-ing the messages, 
causing the whole pipeline to leak. I fixed that and hacked the code to 
recreate the pipeline for every frame and was able to play for a good 
hour with no visible leak. So at least I know the pipeline 'freeing' is 
ok.

Then I sometimes got Xspice to go into an infinite loop. I had seen that 
before but I have now confirmed that it is the expected behavior if the 
client stops responding ('killall -STOP spicy' or 'iptables -I INPUT -j 
DROP' for instance). My understanding is that's because when the client 
stops responding the channel gets full (1) in red_process_display(), 
causing it to stop processing QXL commands (2), so that the QXL ring 
gets full, causing the applications X operations to 'block' by means of 
a spin loop in qxl_ring_push() (3).
Yuck!

So then I found the race condition causing the client to freeze: we 
would schedule a call to display_frame(), but before that happened 
another frame came along with a different size, causing a pipeline 
rebuild. So when display_frame() was actually called the pipeline would 
still exist but would end up being short one decoded frame so that 
gst_app_sink_pull_sample() would block after a while.

So now I grab the sample in the pipeline callback and queue it in a 
GAsyncQueue. I would have liked to avoid this extra complexity but it's 
relatively modest. To make the most of it the GStreamer encoder now 
schedules the frames rendering itself which lets it adapt to mm-time 
changes. GStreamer now passes frames to our queuing immediately, thus 
minimising the number of frames stored in the pipeline that can be lost 
when rebuilding the pipeline.

So now hovering madly over the YouTube seek bar seems to work ok 
(i.e. it's as ugly as expected).


(1) red-worker.c: red_channel_max_pipe_size(RED_CHANNEL(worker->display_channel)) > MAX_PIPE_SIZE
(2) red-worker.c: red_qxl_get_command(worker->qxl, &ext_cmd) is no longer called
(3) qxl_ring.c: while (header->prod - header->cons == header->num_items)

-- 
Francois Gouget <fgouget at codeweavers.com>