多线程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 $
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.movie_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屋!