GNOME Bugzilla – Bug 663417
Overlay Widget Not Working...
Last modified: 2011-11-08 20:19:44 UTC
I was told to use a Gtk.Overlay widget to overlay objects over a GStreamer video (playing in a Gtk.DrawingArea). However, when I do so, I can hear, but not see, the video. When I have no objects overlaying, I can see the video in the Gtk.Overlay just fine. But, again, once I have any objects added via overlay.add_overlay(widget), the video disappears. How do I fix this? I really need a Gtk.Fixed container to overlay my video. Code below. -- from gi.repository import Gtk, Gdk, GdkPixbuf, GdkX11 import pango import pygst pygst.require('0.10') import gst import Trailcrest import os, sys import cairo from math import pi class Video: def __init__(self): def on_message(bus, message): if message.type == gst.MESSAGE_EOS: # End of Stream player.seek(1.0, gst.FORMAT_TIME, gst.SEEK_FLAG_FLUSH, gst.SEEK_TYPE_SET, 5000000000, gst.SEEK_TYPE_NONE, 6000000000) elif message.type == gst.MESSAGE_ERROR: player.set_state(gst.STATE_NULL) (err, debug) = message.parse_error() print "Error: %s" % err, debug def on_sync_message(bus, message): if message.structure is None: return False if message.structure.get_name() == "prepare-xwindow-id": Gdk.threads_enter() Gdk.Display.get_default().sync() win_id = videowidget.get_property('window').get_xid() imagesink = message.src imagesink.set_property("force-aspect-ratio", True) imagesink.set_xwindow_id(win_id) Gdk.threads_leave() def click_me(event, data=None): player.seek(1.0, gst.FORMAT_TIME, gst.SEEK_FLAG_FLUSH, gst.SEEK_TYPE_SET, 5000000000, gst.SEEK_TYPE_NONE, 6000000000) win = Gtk.Window() win.set_resizable(False) win.set_decorated(False) win.set_position(Gtk.WindowPosition.CENTER) overlay = Gtk.Overlay() win.add(overlay) overlay.show() videowidget = Gtk.DrawingArea() overlay.add(videowidget) videowidget.set_halign (Gtk.Align.START) videowidget.set_valign (Gtk.Align.START) videowidget.set_size_request(640, 480) videowidget.show() fixed = Gtk.Fixed() overlay.add_overlay(fixed) fixed.show() pixbuf = GdkPixbuf.Pixbuf.new_from_file_at_size("IMG/IMG-MPG-LOGO.png", 250, 50) imgMPL = Gtk.Image() imgMPL.set_from_pixbuf(pixbuf) eb_imgMPL = Gtk.EventBox() eb_imgMPL.set_visible_window(False) eb_imgMPL.add(imgMPL) fixed.put(eb_imgMPL, 10, 10) imgMPL.show() eb_imgMPL.show() win.show_all() # Setup GStreamer player = gst.element_factory_make("playbin", "MultimediaPlayer") bus = player.get_bus() bus.add_signal_watch() bus.enable_sync_message_emission() #used to get messages that GStreamer emits bus.connect("message", on_message) #used for connecting video to your application bus.connect("sync-message::element", on_sync_message) player.set_property("uri", "file://" + os.getcwd() + "/VID/BGA-HABT-001.ogv") player.set_state(gst.STATE_PLAYING) if __name__ == "__main__": Gdk.threads_enter() Video() Gtk.main()
First can you ask a gstreamer person if this is the correct way to use the overlays? PyGObject developers may not know gstreamer very well and it is best to confirm that the bug does not lay somewhere in the technical areas of gstreamer (e.g. it would be nice to see code for a working example, even if it is in C, so we can debug the expected result). Second, I'm not even sure pygst works with Gtk 3 and pygobject introspection. You are mixing static bindings with introspected bindings and results may vary. If it even touches GLib and initializes a new version underneath pygobject, there could be fireworks. On the other hand gstreamer is fairly lowlevel in its usage of GLib so it may not blow up. In any case it isn't a supported combination. Introspected GStreamer 1.0 is the way to go and some of the basic functions of Introspected GStreamer 0.10 should work (e.g. I've gotten playbin to play a video file in the past). For pygst I would stick with PyGTK for now. In any case if you do attach a working test code I can look into it further.
I ran a test using only Gtk 3 objects, and this has nothing to do with GStreamer, which, for the record, functions perfectly and without the slightest issue. Gtk.Overlay does not work.
*** This bug has been marked as a duplicate of bug 663589 ***