Playbin and changing video-sink

[Russel Winder]

I start a playbin. If I give it an MRL and set it to play, it plays.
Because this is a trivial use of playbin from a trivial gtk code
without any overlaying, the playbin starts a new window – which for
this experiment is fine.

        play_bin = ElementFactory.make("playbin");
        assert(play_bin !is null);
        play_bin.getBus().addWatch(delegate bool(Message m) { return onBusMessage(m); });
        …
        play_bin.setProperty("uri", Uri.isValid(path) ? path : Uri.filenameToUri(path));
        play_bin.setState(State.PLAYING);

OK, the potentially odd looking code syntax is because this is D code
using the GtkD bindings to Gtk+-3 and GStreamer-1.0. The point is
though it works entirely as expected. Until I click the close button on
the playbin window, then I get:

    Error: Output window was closed: xvimagesink.c(555): gst_xv_image_sink_handle_xevents (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0

    (foscam_client:22397): Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops != NULL' failed
    Error: GStreamer encountered a general stream error.: qtdemux.c(5319): gst_qtdemux_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0:
    streaming stopped, reason error

    (foscam_client:22397): Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops != NULL' failed

Is this what should be expected? GtkD has no mention of anything qt-ish
for obvious reasons, so this must be happening inside GStreamer. Given
the playbin window is being killed off, it sort of makes sense that the
pipeline should be stopped. However, if instead of terminating the
playbin window I try to change the video-sink:

        g_object_set(play_bin.getElementStruct(), Str.toStringz("video-sink"), video_sink.getElementStruct(), null);

and run the code, I get a "playbin" window with title "Gtk + GL
renderer" and the message:

    Error: GStreamer encountered a general stream error.: qtdemux.c(5319): gst_qtdemux_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0:
    streaming stopped, reason not-negotiated

    (foscam_client:22587): Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops != NULL' failed

very much the same message, so trying to replace the "video-sink"
property appears to be causing the stream termination. Again is this as
it should be?


(I am more or less assuming I am doing something wrong in controlling
the GStreamer subsystem, the GtkD binding is auto generated via the GIR
stuff. 

--
Russel.
=============================================================================
Dr Russel Winder      t: [phone]   voip: sip:[hidden email]
41 Buckmaster Road    m: [phone]   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


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

[Sebastian Dröge-3]

On Fr, 2016-03-11 at 20:05 +0000, Russel Winder wrote:

> I start a playbin. If I give it an MRL and set it to play, it plays.
> Because this is a trivial use of playbin from a trivial gtk code
> without any overlaying, the playbin starts a new window – which for
> this experiment is fine.
>
> play_bin = ElementFactory.make("playbin");
> assert(play_bin !is null);
> play_bin.getBus().addWatch(delegate bool(Message m) { return onBusMessage(m); });
> …
> play_bin.setProperty("uri", Uri.isValid(path) ? path : Uri.filenameToUri(path));
> play_bin.setState(State.PLAYING);
>
> OK, the potentially odd looking code syntax is because this is D code
> using the GtkD bindings to Gtk+-3 and GStreamer-1.0. The point is
> though it works entirely as expected. Until I click the close button on
> the playbin window, then I get:
>
>     Error: Output window was closed: xvimagesink.c(555): gst_xv_image_sink_handle_xevents (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0
>
>     (foscam_client:22397): Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops != NULL' failed
>     Error: GStreamer encountered a general stream error.: qtdemux.c(5319): gst_qtdemux_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0:
>     streaming stopped, reason error
>
>     (foscam_client:22397): Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops != NULL' failed
>
> Is this what should be expected? GtkD has no mention of anything qt-ish 
> for obvious reasons, so this must be happening inside GStreamer. Given
> the playbin window is being killed off, it sort of makes sense that the
> pipeline should be stopped.

qt here is quicktime, not the toolkit :)

The gtk_main_quit() assertions are something you should look into, it's
something wrong with either your GTK code or the D bindings.

The other thing is expected: when closing the window created by a video
sink, you'll get an error message. Also note that the automatically
created windows of video sinks are just there for debugging purposes,
you shouldn't use that in a real application but instead somehow create
windows/widgets yourself and embed the video in there.

>  However, if instead of terminating the
> playbin window I try to change the video-sink:
>
> g_object_set(play_bin.getElementStruct(), Str.toStringz("video-sink"), video_sink.getElementStruct(), null);
>
> and run the code, I get a "playbin" window with title "Gtk + GL
> renderer" and the message:
>
>     Error: GStreamer encountered a general stream error.: qtdemux.c(5319): gst_qtdemux_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0:
>     streaming stopped, reason not-negotiated
>
>     (foscam_client:22587): Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops != NULL' failed
>
> very much the same message, so trying to replace the "video-sink"
> property appears to be causing the stream termination. Again is this as
> it should be?

That's surprising, changing the video sink during PLAYING should have
no effect at all until the next time you go back to READY. But in
general, changing video sinks in playbin is not supported in
PAUSED/PLAYING state. It should not fail like this though, can you
report a bug about that with a small C testcase application?
  https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer

What is it that you're trying to do here? What's the goal of these
experiments? :)

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

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

[Russel Winder]

On Sat, 2016-03-12 at 13:04 +0200, Sebastian Dröge wrote:
[…]
> qt here is quicktime, not the toolkit :)

I never even thought of Quicktime, this being Linux!

> The gtk_main_quit() assertions are something you should look into,
> it's
> something wrong with either your GTK code or the D bindings.

I can definitely believe it my code, D bindings as well but much less
so. Sadly I am having to contemplate using C directly from D as the D
binding appear to have big difficulties with the Value type. Or this
maybe me just not appreciating how to do things properly.

> The other thing is expected: when closing the window created by a
> video
> sink, you'll get an error message. Also note that the automatically
> created windows of video sinks are just there for debugging purposes,
> you shouldn't use that in a real application but instead somehow
> create
> windows/widgets yourself and embed the video in there.

The initial target was to get xvimagesink overlaying in D rather than
C++, then the idea was to enforce the use of gtkglsink. So using the
automated window was indeed just for development purposes.

> That's surprising, changing the video sink during PLAYING should have
> no effect at all until the next time you go back to READY. But in
> general, changing video sinks in playbin is not supported in
> PAUSED/PLAYING state. It should not fail like this though, can you
> report a bug about that with a small C testcase application?
>   https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
>
> What is it that you're trying to do here? What's the goal of these
> experiments? :)

I am trying to never use C for anything to do with GTK and GStreamer :-
)

I'll write a C version of the code I have in D so as to remove a
variable. Once available, and showing the same problem (if it does),
I'll post a bug report.

--
Russel.
=============================================================================
Dr Russel Winder      t: [phone]   voip: sip:[hidden email]
41 Buckmaster Road    m: [phone]   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


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

[Sebastian Dröge-3]

On Sa, 2016-03-12 at 14:13 +0000, Russel Winder wrote:
> On Sat, 2016-03-12 at 13:04 +0200, Sebastian Dröge wrote:
> […]
> >
> > qt here is quicktime, not the toolkit :)
> I never even thought of Quicktime, this being Linux!

The .mov files :) It's what MP4 was based on. The demuxer is called
qtdemux for historical reasons but handled MOV/MP4/3GPP/etc.

> >
> > The gtk_main_quit() assertions are something you should look into,
> > it's
> > something wrong with either your GTK code or the D bindings.
> I can definitely believe it my code, D bindings as well but much less
> so. Sadly I am having to contemplate using C directly from D as the D
> binding appear to have big difficulties with the Value type. Or this
> maybe me just not appreciating how to do things properly.

You mean GValue? What's the problem there? Maybe take a look at how
it's handled in C#, it was quite convenient and nice to use there

> > That's surprising, changing the video sink during PLAYING should
> > have
> > no effect at all until the next time you go back to READY. But in
> > general, changing video sinks in playbin is not supported in
> > PAUSED/PLAYING state. It should not fail like this though, can you
> > report a bug about that with a small C testcase application?
> >   https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
> >
> > What is it that you're trying to do here? What's the goal of these
> > experiments? :)
> I am trying to never use C for anything to do with GTK and GStreamer :-)

That's certainly possible, people are doing that :)

> I'll write a C version of the code I have in D so as to remove a
> variable. Once available, and showing the same problem (if it does),
> I'll post a bug report.

Great, thanks! The D code is simple enough, there's not much the
bindings could do wrong there.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


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

[Mike Wey]

On 03/12/2016 03:13 PM, Russel Winder wrote:
> I can definitely believe it my code, D bindings as well but much less
> so. Sadly I am having to contemplate using C directly from D as the D
> binding appear to have big difficulties with the Value type. Or this
> maybe me just not appreciating how to do things properly.

 From the gtk_main_quit assertions i would say the gtk main loop isn't
running.
Are you using GApplication or calling gtk_main / Main.run ?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Russel Winder]

On Sat, 2016-03-12 at 16:14 +0100, Mike Wey wrote:
[…]
>  From the gtk_main_quit assertions i would say the gtk main loop
> isn't 
> running.
> Are you using GApplication or calling gtk_main / Main.run ?

Subclass of ApplicationWindow and a subclass of Application – I have
given up on Main.run, it's deprecated ;-)

I have managed to get overlaying working fine, but not with the default
videosink created by playbin (it's an xvimagesink), I have to put a
glimagesink in the pipeline forcibly before the play. This reflects
exactly the problems I am seeing with using the GStreamer C API from
C++. I suspect the error is in my code reinforcing the lessons from C++
in the D code, but…  

Trying to use a gtkglsink instead of a glimagesink in the same code
causes the error. Yes this is happening before the play is issued to
the playbin but the Glib mainloop must be running since the code is in
the ApplicationWindow subclass code constructor which is happening in
the activate signal handler of the Application subclass.

--
Russel.
=============================================================================
Dr Russel Winder      t: [phone]   voip: sip:[hidden email]
41 Buckmaster Road    m: [phone]   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


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

[Russel Winder]

In case anyone is interested in the actual code, I have created a Git
repository on GitHub ­at least temporarily. I haven't heard back from
Foscam as yet about whether code that uses their proprietary C API can
be released as FOSS.

https://github.com/russel/Foscam_Client

--
Russel.
=============================================================================
Dr Russel Winder      t: [phone]   voip: sip:[hidden email]
41 Buckmaster Road    m: [phone]   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


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

[Russel Winder]

On Sat, 2016-03-12 at 13:04 +0200, Sebastian Dröge wrote:
> […]
> That's surprising, changing the video sink during PLAYING should have
> no effect at all until the next time you go back to READY. But in
> general, changing video sinks in playbin is not supported in
> PAUSED/PLAYING state. It should not fail like this though, can you
> report a bug about that with a small C testcase application?
>   https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer

Is there a little C code template you can point me at that I could
amend so as to exhibit the issue?

-- Russel.=============================================================================Dr Russel Winder      t: [phone]   voip: sip:[e-mail]41 Buckmaster Road    m: [phone]   xmpp: [hidden email] SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

[Sebastian Dröge-3]

On Mo, 2016-03-14 at 10:13 +0000, Russel Winder wrote:

> On Sat, 2016-03-12 at 13:04 +0200, Sebastian Dröge wrote:
> >
> > […]
> > That's surprising, changing the video sink during PLAYING should
> > have
> > no effect at all until the next time you go back to READY. But in
> > general, changing video sinks in playbin is not supported in
> > PAUSED/PLAYING state. It should not fail like this though, can you
> > report a bug about that with a small C testcase application?
> >   https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
> Is there a little C code template you can point me at that I could
> amend so as to exhibit the issue?

You could base it on:
https://github.com/sdroege/gst-snippets/blob/master/app.c

That's what I'm usually using it for, testcases.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


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