[Spice-devel] [spice v13 10/29] server: Handle and recover from GStreamer encoding errors

[Christophe Fergeau]

On Wed, May 04, 2016 at 11:21:13AM +0200, Francois Gouget wrote:
> On Tue, 3 May 2016, Christophe Fergeau wrote:
> [...]
> > And GStreamer GstBus/GstAppSink API tends to be async, while we need
> > encode_frame() to be sync, so there is indeed several useful APIs that
> > we cannot use without additional complexity. I'm wondering if the
> > simpler patch attached to this message could work too.
> 
> I had tried that but while it works you get a big warning that changing 
> the state of the pipeline from the streaming thread is not allowed:
> 
> (Xorg:29234): Spice-WARNING **: gstreamer-encoder.c:809:handle_pipeline_message: GStreamer error from element encoder: Can not initialize x264 encoder.
> gstreamer-encoder.c:809:handle_pipeline_message: GStreamer error from element encoder: Can not initialize x264 encoder.
> gstreamer-encoder.c:811:handle_pipeline_message: debug details: gstx264enc.c(1269): gst_x264_enc_init_encoder (): /GstPipeline:pipeline3/GstX264Enc:encoder
> 0:00:09.382605905 29234 0x7f3de0855e80 DEBUG             GST_STATES gstelement.c:2638:gst_element_set_state_func:<pipeline3> set_state to NULL
> [...]
> 0:00:09.384261060 29234 0x7f3de0855e80 WARN                    task gsttask.c:862:gst_task_join:<src:src> trying to join task from its thread
> 
> (Xorg:29234): GStreamer-WARNING **: 
> Trying to join task 0x7f3de00f7560 from its thread would deadlock.
> You cannot change the state of an element from its streaming
> thread. Use g_idle_add() or post a GstMessage on the bus to
> schedule the state change from the main thread.
> 
> 0:00:09.384286706 29234 0x7f3de0855e80 DEBUG               GST_PADS gstpad.c:5731:gst_pad_stop_task:<src:src> join failed
> 0:00:09.384291170 29234 0x7f3de0855e80 DEBUG                basesrc gstbasesrc.c:2854:gst_base_src_stop:<src> stopping source

Ugh that's bad :( Using gst_message_new_request_state() might avoid
this, but while the GstAppSink element is blocked waiting for data, I
don't know if state changes are going to be handled (ie I'm not sure
about GStreamer threading model and which thread the state change is
going to come from). I can try asking on #gstreamer if needed.

> 
> 
> > > Also I'm not convinced we really have a glib main loop in Xspice. If we 
> > > did I would expect APIs like g_idle_source_new() to work. See: 
> > > https://lists.freedesktop.org/archives/spice-devel/2016-March/027502.html
> > 
> > Yes, I addressed this in
> > https://lists.freedesktop.org/archives/spice-devel/2016-March/027550.html
> > « One gotcha though is that queueing an idle this way is currently not
> > working, you have to workaround it with g_timeout_source_new(1).
> 
> I had tried using g_timeout_add() but maybe I was missing the 
> g_timeout_source_new() call. In any case I'm not sure it would really 
> help.

g_timeout_add() would add the timeout to an hypothetical default glib
mainloop which indeed does not exist, neither in the QEMU nor in the
Xspice situation (or maybe it exists, but it would have to be
created/used by QEMU/Xorg). In this case, the display thread mainloop is
not going to run anyway as it's blocked calling into
gst_app_sink_pull_sample, so you are right, this is not helpful. I
initially was not 100% certain what was the exact scenario of the
blocking.

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20160504/e42b0a19/attachment.sig>