GStreamer 总线发送无消息答案

【问题标题】：GStreamer bus sends None messageGStreamer 总线发送无消息
【发布时间】：2011-08-10 01:50:56
【问题描述】：

我一直在一个项目中使用 pygst，它运行良好。我正在尝试将其迁移到新的自省系统 (GI)，但我得到了不同的行为。

在旧的 pygst 中我有这样的东西：

... # other imports
import pygst
pygst.require('0.10')
import gst
... # other imports

gobjects.threads_init()

...

def my_handler(bus, message):
    # handle the message

...

player = gst.element_factory_make('playbin2', 'my_player')
bus = player.get_bus()
bus.connect('message', my_handler)
bus.add_signal_watch()
...
player.set_state(gst.STATE_PLAYING)
# start the main Glib loop

message 参数有一个属性.type，可用于选择性处理（我只对流结束（EOS）和错误感兴趣）。使用我拥有的新系统：

... # other imports
from gi.repository import Gst
import glib
import gobject
.... # other imports

gobject.threads_init()

loop = glib.MainLoop(None, False)

def bus_handler(bus, message):
    print message
    # handle the message
...

Gst.init_check(None)
player = Gst.ElementFactory.make('playbin2', 'my_player')
player.set_property('uri', 'file:///home/kenji/button.ogg')
bus = player.get_bus()
bus.connect('message', bus_handler)
bus.add_signal_watch()
player.set_state(Gst.State.PLAYING)
# start the main loop

但是，处理程序总是将参数 message 接收为 None。我已经尝试过滤掉这些，但我仍然一无所获（即所有消息都是无）。

我已经阅读了很多 GStreamer 文档（尤其是关于 GstBus、add_signal_watch() 和 playbin2），但我没有找到与此行为相关的任何内容。我检查了 Gst gir 文件，发现 add_watch() 不能自省，所以这是一条死胡同。上面这个例子中的 glib 主循环只是为了在没有完整的 GTK 例子的情况下使事情变得更短，但真正的事情使用 Gtk.main() （给出完全相同的行为）。

我在 Arch Linux 64 上使用 GStreamer 0.10.35.0（由 Gst.version() 告知），但我在 Ubuntu 11.04 32 位上的 GStreamer 0.10.32.0 上测试了相同的行为。

是否有任何替代 bus.connect() 的方法？我是否以错误的方式使用它？我已经花了好几个小时来寻找这个错误，我真的很感激对此的任何见解。谢谢！ =)

【问题讨论】：

我发现了这个bug：bugzilla.gnome.org/show_bug.cgi?id=631901 基本上还没有实现。
我可以确认这在 gstreamer 1.0 中已修复。

标签： python gstreamer

【解决方案1】：

我很确定接受的答案不正确。 add_signal_watch_full 和add_signal_watch 之间的唯一区别是前者允许您设置事件源的优先级，而后者只是用G_PRIORITY_DEFAULT 调用前者。您可以在 C source code 行号 940 中验证这一点。优先级仅影响事件触发的顺序，不应该影响是否被触发，当然也不影响信号消息的内容，这就是这里的问题。我什至用各种优先级值对其进行了测试，如果有一种方法可行，我会吃掉我的帽子。 :-)

真正的答案是它不起作用。 PyGObject 和 GStreamer 0.10 不能很好地协同工作。见：

后者说：“请注意，尽管您可以排序将 GStreamer0.10 与 PyGI 一起使用，但关键功能从根本上被破坏并且永远不会在 GStreamer0.10 中修复（因为它需要 API破损）。”

那么，您的选择是：

需要 GStreamer 1.0。
使用旧的 PyGST 绑定。
将 PyGObject 与 GStreamer 0.10 一起使用，但无法检查 EOS 等消息。只有非常基本的东西有效。

【讨论】：

【解决方案2】：

我最终使用了add_signal_watch_full()，不幸的是它更加冗长。不过它工作正常，我可以在我的处理程序上接收消息。

【讨论】：

不幸的是，这对我不起作用。能否提供一些示例代码？
add_signal_watch_full(1) 对我有用。我不知道为什么需要“1”参数。

【解决方案3】：

如果您不打算将 GTK 与该程序一起使用，则必须运行 gobject.Mainloop() 才能从总线获取消息。这和任何其他主循环一样，会冻结整个程序（如果它没有线程化），所以我通常会写一些类似的东西：

g_loop = threading.Thread(target=gobject.MainLoop().run)
g_loop.daemon = True
g_loop.start()

在不需要 GUI 但需要 Gstreamer 的程序结束时。

【讨论】：

这没有回答问题。从示例代码的最后一行，注释表明 Kenji 知道需要一个主循环。而且您的解决方案无法解决问题。

【解决方案4】：

我遇到了同样的问题，但在 C 语言中。

经过漫长的调试，我发现这是因为我的可执行文件通过我使用的其他共享库间接链接到 0.10 和 1.0。

删除链接到 0.10 的共享库解决了我的问题。

【讨论】：