多线程Gstreamer w / PyGTK崩溃（xcb_xlib_threads_sequence_lost） [英] Multithreaded Gstreamer w/ PyGTK crashing (xcb_xlib_threads_sequence_lost)

问题描述

我明白，不应该从 gtk 中的其他线程更新UI，或者面临后果，但我不知道如何避免使用 gstreamer 。

我的应用程序在视频流初始化过程中不时崩溃， b
$ b

  [xcb]处理队列时的未知序列号
 [xcb]很可能这是一个多线程客户端，并且尚未调用XInitThreads 
 [xcb]堕胎，对此感到遗憾。 
 python：../../src/xcb_io.c:274：poll_for_event：声明`！xcb_xlib_threads_sequence_lost'失败。 
  

在我的代码中，我添加了 gtk.thread_init（）在GUI类的开始调用权：

  import pygtk，gtk，gobject 
 gtk.gdk .threads_init（）
  

<我也试过 gobject.threads_init（），但这没有什么不同）。在一个单独的类中，它运行在一个单独的线程中，我开始一个gstreamer流到一个 tcpserversink （如果有人持续计数，这个gstreamer线程已经是第三个线程） 。然后另一个线程在最后将数据推送到 xvimagesink 之前接收这些数据。
$ b $ xvimagesink 需要一个视口，我相信这个gstreamer回调函数有时会让gtk变得疯狂，当我指定它：

  def on_sync_message（self，bus，message）：
 ... 
 if message_name ==prepare-xwindow-id：
 
＃指定视口
 imagesink = message.src 
 imagesink.set_property（force-aspect-ratio，True）
 imagesink.set_xwindow_id（self.window_handle.window.xid）
  

self.window_handle 是一个指向 self.movi​​e_window = gtk.DrawingArea（）的指针，在GUI初始化过程中分配。

TL; DR 使用gstreamer时有没有安全的方法，因为调用 gst.Pipeline（name）时无法避免线程化.set_state（gst.STATE_PLAYING）和view将是一个GTK绘图区域？

解决方案

您的问题是您正在访问取消保护的事实编辑Xlib / xcb来自2个线程 - 一次隐藏在你的Gtk + UI中，一次在执行gstreamer后端回调的线程中执行 - 默认情况下是你告诉gstreamer使用的主循环（或线程默认主循环）。

---

gtk.gdk.threads_init（）一旦类型系统被调用初始化（如果我记得正确，纠正我，如果我错了）。

---

使用 g_idle_add （或者使用具有更高优先级的 GSource ）（它们是线程安全的），并在Gtk主循环中调度UI更改（由<$ c运行） $ c> gtk_main（））。

I understand that one is not supposed to update the UI from other threads in gtk, or face consequences, but I am not sure how I can avoid that while using gstreamer.

My application crashes from time to time during video stream initialization with a following complaint:

[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.

In my code I have added gtk.thread_init() call right in the beginning of the GUI class:

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

(I have also tried gobject.threads_init(), but this doesnt seem any different). In a separate class, which is run in a separate thread, I start a gstreamer stream to a tcpserversink (this gstreamer thread is already a third thread, if someone is keeping count). And then another thread receives this data before pushing the data to xvimagesink in the end.

The xvimagesink needs a viewport, and I believe this gstreamer callback function is where sometimes gtk goes crazy, when I assign it:

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 is a pointer to self.movie_window = gtk.DrawingArea(), assigned during GUI initialization.

TL;DR Is there a safe way of using gtk with gstreamer, since I cannot avoid threading when calling gst.Pipeline("name").set_state(gst.STATE_PLAYING) and view will be a GTK drawing area ?

解决方案

I think your issue is the fact that you are accessing unprotected Xlib/xcb from 2 threads - once impicitly from your Gtk+ UI and once in the thread where your gstreamer backend callback is executed - which by default is the mainloop you told gstreamer to use (or the thread default mainloop).

---

gtk.gdk.threads_init() is already called once the type system is initialized (if I recall correctly, correct me if I am wrong).

---

Use g_idle_add (or use GSource with a higher priority) (which are threadsafe) with a callback which schedules UI changes in the Gtk mainloop (run by gtk_main()).

这篇关于多线程Gstreamer w / PyGTK崩溃（xcb_xlib_threads_sequence_lost）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！