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

我知道不应该从其他线程更新 UIgtk，或面临后果，但我不确定在使用时如何避免这种情况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 类的开头调用：

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

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

The 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)

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

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

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

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

Use g_idle_add（或使用GSource具有更高的优先级）（这是线程安全的），并带有一个回调，该回调在 Gtk 主循环中安排 UI 更改（由gtk_main()).