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@xxxxxxxxxxxxxxx>
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel