Screen capture in GTK+ application

[David Woodhouse]

I tried using ximagesrc as a video source in Pidgin (which is still
using GTK2+, FWIW). It fell over:
 [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
 [xcb] Aborting, sorry about that.

Is ximagesrc just not expected to work in threaded GTK programs? That
might be worth mentioning in its documentation...

What's the sanest way to resolve it? Once upon a time, perhaps
ximagesrc could have had an option to use gdk_threads_enter() around
its XLib calls instead of just using its own mutex, perhaps? That
doesn't seem like a viable option now though, if it ever was.

Should I create a 'gdkwindowsrc' element which works directly through
GTK/GDK to do the captures from a given GdkWindow instead?

That might work nicely since from the application's point of view it
would abstract away the X/Wayland/Windows/OSX differences. It could
also be a home for a generic UI widget which allows the user to choose
*what* to capture (one app, one monitor, or the entire display).

Better ideas?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mardi 17 avril 2018 à 11:44 +0100, David Woodhouse a écrit :
> I tried using ximagesrc as a video source in Pidgin (which is still
> using GTK2+, FWIW). It fell over:
>  [xcb] Most likely this is a multi-threaded client and XInitThreads
> has not been called
>  [xcb] Aborting, sorry about that.
>
> Is ximagesrc just not expected to work in threaded GTK programs? That
> might be worth mentioning in its documentation...

It's exactly what the error says. Gtk does not call XInitThreads,
because it does not do concurrent access to the display object. You
must call this function in Pidgin, before you initialize Gtk and
GStreamer. The "threading" support in Gtk only works for Gtk calls.

>
> What's the sanest way to resolve it? Once upon a time, perhaps
> ximagesrc could have had an option to use gdk_threads_enter() around
> its XLib calls instead of just using its own mutex, perhaps? That
> doesn't seem like a viable option now though, if it ever was.
>
> Should I create a 'gdkwindowsrc' element which works directly through
> GTK/GDK to do the captures from a given GdkWindow instead?
>
> That might work nicely since from the application's point of view it
> would abstract away the X/Wayland/Windows/OSX differences. It could
> also be a home for a generic UI widget which allows the user to
> choose
> *what* to capture (one app, one monitor, or the entire display).
>
> Better ideas?
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Woodhouse]

On Tue, 2018-04-17 at 07:54 -0400, Nicolas Dufresne wrote:

> Le mardi 17 avril 2018 à 11:44 +0100, David Woodhouse a écrit :
> > I tried using ximagesrc as a video source in Pidgin (which is still
> > using GTK2+, FWIW). It fell over:
> >
> >  [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
> >  [xcb] Aborting, sorry about that.
> > 
> > Is ximagesrc just not expected to work in threaded GTK programs? That
> > might be worth mentioning in its documentation...
>
> It's exactly what the error says. Gtk does not call XInitThreads,
> because it does not do concurrent access to the display object ...
> The "threading" support in Gtk only works for Gtk calls.

Right. That is the kind of thing which could perhaps be documented
rather than left to an error message once you try it.

> You must call this function in Pidgin, before you initialize Gtk
> and GStreamer.

Except that (theoretically, haha) I'm not actually working on Pidgin;
I'm working on a protocol plugin for libpurple, and Pidgin just happens
to be one of the GUIs which use libpurple. My plugin is loaded *much*
too late for that, and is *supposed* to be entirely UI-agnostic — it
doesn't, and shouldn't, link against Xlib.

As a very short-term solution I can of course throw all the layering
and abstraction out the window, and it does seem that calling
XInitThreads() (from the main thread) right before instantiating the
ximagesrc does seem to work¹.

I do need to fix it properly, which means having the UI program (be it
Pidgin or Adium or something else) provide libpurple with a suitable
GstElement for screen capture. And a UI to select which window/monitor
to capture, too. But I think that a GdkWindowImageSrc (with associated
widgets) probably does make most sense for that, in the long run. 

-- 
dwmw2

¹ Meaning I can now turn my attention to the fact that xvimagesink is
  hosed for the majority of image sizes :)
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel