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