带有 PyGTK 崩溃的多线程 Gstreamer (xcb_xlib_threads_sequence_lost)

Question

据我所知，一个是不应该更新从其他线程的UI gtk，否则将面临后果，但我不知道在使用我如何能够避免这种情况gstreamer。

我的应用程序在视频流初始化期间不时崩溃，并出现以下抱怨：

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

在我的代码中，我gtk.thread_init()在 GUI 类的开头添加了call：

import pygtk, gtk, gobject
gtk.gdk.threads_init()

（我也试过gobject.threads_init()，但这似乎没有什么不同）。在一个单独的类中，它在一个单独的线程中运行，我启动一个 gstreamer 流到 a tcpserversink（这个 gstreamer 线程已经是第三个线程，如果有人在计数的话）。然后另一个线程在将数据推送到xvimagesink最后之前接收此数据。

在xvimagesink需要视，我相信这GStreamer的回调函数就是有时GTK都疯了，当我为它分配：

def on_sync_message(self, bus, message):
...
if message_name == "prepare-xwindow-id":

  # Assign the viewport
  imagesink = message.src
  imagesink.set_property("force-aspect-ratio", True)
  imagesink.set_xwindow_id(self.window_handle.window.xid)

的self.window_handle是一个指针self.movie_window = gtk.DrawingArea()，GUI初始化期间分配的。

TL;DR是否有一种将 gtk 与 gstreamer 一起使用的安全方法，因为在调用gst.Pipeline("name").set_state(gst.STATE_PLAYING)和视图将是 GTK 绘图区域时我无法避免线程化？

Answer 1

我认为你的问题是你正在从 2 个线程访问不受保护的 Xlib/xcb - 一次是从你的 Gtk+ UI 隐式访问，一次是在执行 gstreamer 后端回调的线程中 - 默认情况下是你告诉 gstreamer 使用的主循环（或线程默认主循环）。

gtk.gdk.threads_init()一旦类型系统初始化就已经被调用了（如果我没记错的话，如果我错了，请纠正我）。

使用g_idle_add（或使用GSource更高优先级）（线程安全的）回调来安排 Gtk 主循环中的 UI 更改（由 运行gtk_main()）。