GStreamer and gjs

[Tony Houghton]

On Mon, 21 Sep 2020 at 17:10, Sebastian Dröge <sebastian at centricular.com>
wrote:

> On Mon, 2020-09-21 at 16:55 +0100, Tony Houghton wrote:
> > The first is that if I
> > call Gst.init(ARGV) it crashes with an attempt to free a block of
> > memory that isn't freeable. I solved that by simply passing null
> > instead, and I guess I could find a workaround if I really do need it
> > to process ARGV.
>
> Can you report that to gjs? That would be a bug on the bindings side
>   https://gitlab.gnome.org/GNOME/gjs


OK, I've done that: https://gitlab.gnome.org/GNOME/gjs/-/issues/350


> > First, note that although the API docs say you need to use
> > add_watch_full(), AFAICT you actually have to use add_watch() with
> > arguments as for add_watch_full(), because the latter doesn't exist
> > in gjs. This is something to do with the 'full' version shadowing the
> > other, which I don't fully understand, but I managed to work it out
> > by looking at the output of ts-for-gjs.
>
> That seems like a problem in the documentation indeed. The non-full
> version is not usable from bindings, so the full version is configured
> to shadow/hide the non-full one.
>
> Where is that in the documentation? Can you create an issue for that at
>   https://gitlab.freedesktop.org/gstreamer/gst-docs/


I've reported that too. I've included a link to the page where I found the
mistake in my report:
https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/72


> > The main problem though is that the pipeline only runs for a few
> > seconds, then crashes with this error:
> >
> > Trying to dispose element inputselector2, but it is in PLAYING
> > instead of the NULL state.
> >
> > I haven't tested whether this is specific to gjs, or also occurs in
> > python or even C, but I get the same error in OS X as well as Arch
> > Linux. Both are using gstreamer 1.18.0.
>
> Your code doesn't have any main loop or similar, so after setting the
> pipeline to PLAYING it simply exits. You probably want to wait in one
> way or another until the EOS (or ERROR) message is received from the
> bus.
>

Sorry, my code does include a GMainLoop, but I missed it out here for
brevity. Without the watch callback my code seems to work OK, but with the
callback it only runs for a few seconds (it does open a window and play
back the stream for a while) before stopping with the above error.

I've tried a few other things. Equivalents in C and python both run
successfully. The Javascript version also runs OK if I use add_signal_watch()
instead of add_watch(). So I think the problem is that gjs can't cope with
a callback being called off the main thread. This could theoretically cause
problems in python too, but I presume it works either because this has been
addressed in its custom Gst bindings, or at a lower level. I'm writing a
companion library in introspectable C for my app, so if I need synchronous
callbacks for something like embedding video in a window of my choice, I
can probably add support functions in the library.

-- 
TH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200921/020e0c68/attachment.htm>