GNOME Bugzilla – Bug 752147
glimagesink and textoverlay aren't friends on OS X
Last modified: 2018-05-05 11:55:16 UTC
Created attachment 307111 [details] Crash of gst-launch-1.0 videotestsrc ! textoverlay ! glimagesink I have crash after gst-launch-1.0 videotestsrc ! textoverlay ! glimagesink I have no crash for gst-launch-1.0 videotestsrc ! textoverlay ! fakesink or gst-launch-1.0 videotestsrc ! glimagesink Something related to font typefaces in cocoa window creation inside gst_gl_window_cocoa_create_window.
Created attachment 307285 [details] [review] WIP pango: init PangoFontMap and PangoContext when going to READY state videosink on osx may use NSFont to set title on their window: initWithContentRect:rect styleMask: NSTitledWindowMask This function will crash when using the custom NSApp loop in glimagesink and osxvideosink: [__NSCFType symbolicTraits]: unrecognized selector [__NSFontTypefaceInfo _postscriptName] The patch (even incomplete) seems to fix the problem. But I do not really understand what happens in the end :) I thought it was because textoverlay inits its pango fontmap and pango context before initializing the NSApp. So I defer this in textoverlay from init to NULL_to_READY. But then in a real cocoa app, even if I create textoverlay before the NSApp, the pipeline works and does not crash. So that's still not clear. Note that the patch is incomplete, it is to start discussion and best way to fix this. If we do this way (READY_to_NULL) we will need to apply same logic for other pango elements.
Should we mark this bug as blocker for 1.6 ? Since both osxvideosink and glimagesink crashes when pipeline contains textoverlay. (though osxvideosink is sometimes lucky)
Well, feel free to mark it as blocker, but it doesn't mean it will actually get solved. Someone has to investigate and understand what's actually happening first, and then make a proper patch.
Maybe let's integrate NSApp in Glib's main loop? gst-launch-1.0 videotestsrc ! tee name=t ! glimagesink t. ! glimagesink t. ! glimagesink
(In reply to Kyrylo V. Polezhaiev from comment #4) > Maybe let's integrate NSApp in Glib's main loop? Good point, that might be a solution and that could explain why nobody reported it before. If someone could try textoverlay ! glimagesink with cerbero that would be great (because it has the local NSApp/Glib fix locally https://bugzilla.gnome.org/show_bug.cgi?id=741450) Though I am still not convinced this is really the problem: "even if I create textoverlay before the NSApp, the pipeline works and does not crash. So that's still not clear" > > gst-launch-1.0 videotestsrc ! tee name=t ! glimagesink t. ! glimagesink t. ! > glimagesink You are missing queues, also it seems gst-launch-1.0 videotestsrc ! tee ! glimagesink does not work atm but was working recently. I think someone already reported the problem on IRC but feel free to open a bug.
oh, yes, forgot queues, shame for me.
Since pango provides 2 backend on osx (QUARTZ named coretext and FREETYPE named fontconfig) we could use the later which seems to work: "#if defined(__APPLE__) (and probably && !defined(GSTREAMER_GLIB_COCOA_NSAPPLICATION)) fontmap = pango_cairo_font_map_new_for_font_type (CAIRO_FONT_TYPE_FT)" instead of "fontmap = pango_cairo_font_map_get_default ();" here http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/ext/pango/gstbasetextoverlay.c#n319 See https://github.com/GNOME/pango/blob/master/pango/pangocairo-fontmap.c#L132 and https://github.com/GNOME/pango/blob/master/pango/pangocairo-fontmap.c#L74 Quick test: PANGOCAIRO_BACKEND=fontconfig gst-launch-1.0 videotestsrc ! textoverlay text="hello" font-desc="Verdana bold 80px" ! glimagesink
Oh, at least PANGOCAIRO_BACKEND=fontconfig helps here: https://bugzilla.gnome.org/show_bug.cgi?id=752148
Demoting this, I don't think this is a blocker bug and as far as I know we only build the fontconfig backend in our OS/X builds anyway. Not sure what to do about this. Is this really a bug in our plugin and not pango? Julien?
(In reply to Tim-Philipp Müller from comment #9) > Demoting this, I don't think this is a blocker bug and as far as I know we > only build the fontconfig backend in our OS/X builds anyway. > Are you sure ? I do not have a cerbero setup atm but http://cgit.freedesktop.org/gstreamer/cerbero/tree/recipes/cairo.recipe#n52 and nothing disable coretext backend in pango.recipe. (also https://github.com/GNOME/pango/blob/master/configure.ac#L372, https://github.com/GNOME/pango/blob/master/pango/pangocairo-fontmap.c#L85) I am sure I am missing something since nobody reported the problem with cerbero before. > Not sure what to do about this. Is this really a bug in our plugin and not > pango? Julien? I tend to say it is a bug in pango :) but honestly I do not know. I do not see how cerbero disables the coretext/quartz backend. But if it really does then we should just tell textoverlay to use fontconfig on all platform :). So that visual results would be more consistent for the user as well. And to avoid visual artifacts, see https://bugzilla.gnome.org/show_bug.cgi?id=752148
Created attachment 309772 [details] [review] pango: use fontconfig backend by default on all platforms If needed I can add a property named "cairo-backend" with values in {"auto", "coretext", "fontconfig", "win32"} (to be consistent with the getenv here https://github.com/GNOME/pango/blob/master/pango/pangocairo-fontmap.c#L74) "auto" being to call pango_cairo_font_map_get_default. The property "cairo-backend" would have "fontconfig" as default value.
FWIW, PANGOCAIRO_BACKEND=fontconfig will break gtk+3 apps in terrible ways. So don't set that by default or else you will get weird behavior and lots of these: Gtk-WARNING **: drawing failure for widget 'GtkBox': out of memory
The fontconfig backend is purely software, are you sure the issue you are seeing isn't another unrelated bug ?
Does anyone remember what should happen here, or has tested it lately?
I think the main conclusion is that the pango / OSX support is/was massively broken. Sounds like not a GStreamer issue, updating Pango/Cairo in cerbero might be needed though.
I can't reproduce this bug here with the 1.14.0 binaries shipped by HomeBrew. I've been watching movies with external sub files for months using Glide, it works fairly well in general :)