Explaining Gstreamer plugin example

[horai]

Dear all,

would anyone be so kind to explain me for what purpose this example exactly
is?
https://github.com/GStreamer/gst-plugins-bad/blob/master/tests/examples/waylandsink/wayland-threads.c

From the code, I would kind of assume that it is meant to show how the code
should be written in order to run two pipelines simultaneously on Wayland.
Simple, just creating pipeline and assigning waylandsink to multiple
pipelines is not enough to run them properly on top of Wayland actually it's
compositor Weston.

I have an application with 4 rendering wayland surfaces and all pipelines
run fine (without usage of code of the above mentioned example), but I am
experiencing problems with disposing rendering areas and also reloading
pipelines whenever I stop them and want to run them once more.
Whenever I want to restart all my 4 pipelines, I experience segmentation
fault in method:
wl_list_insert() resizing in wayland-client.c.
It randomly crashes on several spots in my code for example this method
which assigns context to waylandsink:
gst_element_set_context(GST_ELEMENT(GST_MESSAGE_SRC(message)), context);
(none of these variables are NULL).
On start of the application, this method runs fine for all 4 video
renderings, but when I stop all renderings and start them once more, it
crashes even though GST_ELEMENT(GST_MESSAGE_SRC(message)) is really
reference to one of 4 waylandsinks I am creating for each of pipeline and
context is a variable created by method:
GstContext *context =
gst_wayland_display_handle_context_new(display_handle);
I have asked several times about my problem if not being able to clear
rendering surface with set_render_rectangle method, therefore I made a
workaround with stopping all pipelines and unreferencing all of them. It
clears the rendering surfaces properly, but the downside is that I cannot
reuse the already created pipeline and unref forces me to create 4 pipelines
once more.
But it seems problems are not yet finished and this workaround has some
deeper issues.
Could this example be utilized in order to fix my problem?
If anyone has some more examples how to write gstreamer code on Wayland,
please share it with me.

Thank you very much
Best regards,
Ivo





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Wonchul Lee]

Hi Ivo,
There was a race condition in the wayland when multi-threaded clients
share wl_display/wl_surface. It could cause to set to the wrong
wayland queue.
The purpose of that example is to check that it fixes with this
change, https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/74

I think if you're using GStreamer 1.16 or later, you will not have the
same issue and don't need to do this way, so could you check the
version you are using?

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

[horai]

Ok, I have 1.14.4 installed from repository.
I left it intact without uninstalling. Downloaded source code version 1.16
of gstreamer-1.0, base,good,bad, compiled and installed.
Now it seems like when video is being rendered in eventBox where waylandsink
renders the event signal from mouse click is not propagated and the method
does not trigger at all so I am unable to event test whether I experience
race condition.
When no video is being rendered to eventBox (it is grey colored when empty)
GTK catches the event and maximizes it properly, I guess something wrong is
with waylandsink in 1.16.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[horai]

Just to note, I also recompiled GTK this way:
nice -20 ./autogen.sh --enable-wayland-backend --enable-gtk-doc=no
--enable-gtk-doc-html=no --enable-gtk-doc-pdf=no  --enable-broadway-backend
--enable-x11-backend --libdir=/usr/lib/x86_64-linux-gnu/

I am using --libdir=/usr/lib/x86_64-linux-gnu/  when configuring Gstreamer
compilation just to overwrite libraries of version 1.14. I know this is
rather messy mixing 1.14 deb packages with raw 1.16 libraries, but I hope
old libraries will be overridden and won't add any more problems saving some
time and making it easier when not building .deb packages.





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[horai]

Seriously,

when running running official gst-plugin-bad wayland example with mouse
button click signal hander attached to videoarea the following code written
way, the video runs but upon button click on video the signal is not
triggered, whey I don't set the pipeline to PLAYING state that means no
video is rendered, the signal triggers properly:

d->video_widget = GTK_WIDGET (gtk_builder_get_object (builder,
"videoarea"));
  g_signal_connect (d->video_widget, "draw",
      G_CALLBACK (video_widget_draw_cb), d);
    g_signal_connect(G_OBJECT(d->video_widget), "button_press_event",
button_press_event, d);

....
static void button_press_event(GtkWidget *widget, GdkEventButton *event,
DemoApp * d) {
        g_print("button Pressed ...\r\n");
}

Please, could anyone more skilled verify this and possibly claim problem on
my side or on waylandsink side?

Thank you






--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mer. 16 oct. 2019 10 h 55, horai <[hidden email]> a écrit :

Seriously,

when running running official gst-plugin-bad wayland example with mouse
button click signal hander attached to videoarea the following code written
way, the video runs but upon button click on video the signal is not
triggered, whey I don't set the pipeline to PLAYING state that means no
video is rendered, the signal triggers properly:

d->video_widget = GTK_WIDGET (gtk_builder_get_object (builder,
"videoarea"));
  g_signal_connect (d->video_widget, "draw",
      G_CALLBACK (video_widget_draw_cb), d);
    g_signal_connect(G_OBJECT(d->video_widget), "button_press_event",
button_press_event, d);

....
static void button_press_event(GtkWidget *widget, GdkEventButton *event,
DemoApp * d) {
        g_print("button Pressed ...\r\n");
}

Please, could anyone more skilled verify this and possibly claim problem on
my side or on waylandsink side?

Are you using gnome-shell ? I have reported a bug about inputs and subsurface but it is likely just the tip of the iceberg. I believe they have low resources, and many issues to tackle. To make waylandsink work nicely, we need to start working on the compositors in general. Just need to find the time.

Thank you






--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
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

[horai]

Dear sir,

I am using Weston on Debian.




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[horai]

Dear all,

I used the version 1.16 and made a workaround instead of catching signals
upon mouse click on eventBox (which is not working in 1.16), I created a
button below the event box which worked, but I am still facing the same
problem described before with a bit different backtrace, but failing at the
same line in libwayland-client.so.0:

#0  0x00007ffff62b5bd0 in wl_list_insert () at
/lib/x86_64-linux-gnu/libwayland-client.so.0
#1  0x00007ffff62b2c4f in wl_display_read_events () at
/lib/x86_64-linux-gnu/libwayland-client.so.0
#2  0x00007ffff62b3169 in wl_display_dispatch_queue () at
/lib/x86_64-linux-gnu/libwayland-client.so.0
#3  0x00007ffff62b33b3 in wl_display_roundtrip_queue () at
/lib/x86_64-linux-gnu/libwayland-client.so.0
#4  0x00007ffff02e4615 in gst_wl_display_new_existing
    (display=0x5555555888d0, take_ownership=take_ownership@entry=0,
error=error@entry=0x7fffffffd338) at wldisplay.c:316
#5  0x00007ffff02e10cb in gst_wayland_sink_set_display_from_context
(sink=sink@entry=0x555555bd5d10, context=context@entry=0x5555559c4d20)
    at gstwaylandsink.c:311
#6  0x00007ffff02e26db in gst_wayland_sink_set_context
(element=0x555555bd5d10, context=0x5555559c4d20) at gstwaylandsink.c:442
#7  0x0000555555558232 in bus_sync_handler (bus=0x7fffe4011400,
message=0x7fff8c01cd30, user_data=0x5555559b90a0) at gstreamerHandler.c:159
#8  0x00007ffff7ea426b in gst_bus_post (bus=bus@entry=0x7fffe4011400,
message=message@entry=0x7fff8c01cd30) at gstbus.c:334
#9  0x00007ffff7eb9ad6 in gst_element_post_message_default
(element=element@entry=0x555555ab80c0, message=0x7fff8c01cd30) at
gstelement.c:1986
#10 0x00007ffff7e95c0d in gst_bin_post_message (element=0x555555ab80c0,
msg=0x7fff8c01cd30) at ../gst/gstmessage.h:369
#11 0x00007ffff7ebcc3a in gst_element_post_message
(element=element@entry=0x555555ab80c0, message=message@entry=0x7fff8c01cd30)
at gstelement.c:2029
#12 0x00007ffff7e95efe in gst_bin_handle_message_func (bin=0x555555ab80c0,
message=0x7fff8c01cd30) at gstbin.c:4058
#13 0x00007ffff7ee3c3c in gst_pipeline_handle_message (bin=0x555555ab80c0,
message=0x7fff8c01cd30) at gstpipeline.c:612
#14 0x00007ffff7e93848 in bin_bus_handler (bus=bus@entry=0x7fffa000ab90,
message=message@entry=0x7fff8c01cd30, bin=bin@entry=0x555555ab80c0)
    at gstbin.c:3276
#15 0x00007ffff7ea426b in gst_bus_post (bus=bus@entry=0x7fffa000ab90,
message=message@entry=0x7fff8c01cd30) at gstbus.c:334
#16 0x00007ffff7eb9ad6 in gst_element_post_message_default
(element=0x555555bd5d10, message=0x7fff8c01cd30) at gstelement.c:1986
#17 0x00007ffff7ebcc3a in gst_element_post_message
(element=element@entry=0x555555bd5d10, message=message@entry=0x7fff8c01cd30)
at gstelement.c:2029
#18 0x00007ffff02e12a5 in gst_wayland_sink_find_display
(sink=0x555555bd5d10) at gstwaylandsink.c:347
#19 0x00007ffff02e27e5 in gst_wayland_sink_change_state
(element=0x555555bd5d10, transition=<optimized out>) at gstwaylandsink.c:382
#20 0x00007ffff7ebdc2e in gst_element_change_state
(element=element@entry=0x555555bd5d10,
transition=transition@entry=GST_STATE_CHANGE_NULL_TO_READY)
    at gstelement.c:2952
#21 0x00007ffff7ebe34e in gst_element_set_state_func
(element=0x555555bd5d10, state=GST_STATE_READY) at gstelement.c:2906
#22 0x00007ffff7e9b807 in gst_bin_element_set_state
    (next=GST_STATE_READY, current=GST_STATE_NULL, start_time=0,
base_time=0, element=0x555555bd5d10, bin=0x555555ab80c0) at gstbin.c:2605
#23 0x00007ffff7e9b807 in gst_bin_change_state_func (element=0x555555ab80c0,
transition=GST_STATE_CHANGE_NULL_TO_READY) at gstbin.c:2947
#24 0x00007ffff7ebdc2e in gst_element_change_state
(element=element@entry=0x555555ab80c0,
transition=transition@entry=GST_STATE_CHANGE_NULL_TO_READY)
    at gstelement.c:2952
#25 0x00007ffff7ebe34e in gst_element_set_state_func
(element=0x555555ab80c0, state=GST_STATE_PLAYING) at gstelement.c:2906
#26 0x0000555555558d0d in hideWindow (widget=0x5555559936c0,
event=0x7fffe800a5d0, streamDataArray=0x5555559b90a0) at gui.c:204
#27 0x00007ffff79be61b in _gtk_marshal_BOOLEAN__BOXED




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[horai]

That was a backtrace in case of creating 4 pipelines again and running them
via GST_STATE_PLAYING (after leaving single camera view)
Sometimes I also experience backtrace when going from 4 camera view mode to
single camera fullscreen mode this backtrace:
malloc_consolidate(): invalid chunk size

Thread 257 "GstWlDisplay" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff9dffb700 (LWP 2033)]
0x00007ffff62b5be3 in wl_list_insert () from
/lib/x86_64-linux-gnu/libwayland-client.so.0
(gdb) bt
#0  0x00007ffff62b5be3 in wl_list_insert () at
/lib/x86_64-linux-gnu/libwayland-client.so.0
#1  0x00007ffff62b2c4f in wl_display_read_events () at
/lib/x86_64-linux-gnu/libwayland-client.so.0
#2  0x00007ffff02e40a9 in gst_wl_display_thread_run (data=0x555555b2d020) at
wldisplay.c:265
#3  0x00007ffff7d61415 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ffff6b2bfa3 in start_thread (arg=<optimized out>) at
pthread_create.c:486
#5  0x00007ffff6c554cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

If you have any clue, please let me know as I am totally lost



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[horai]

Dear sir,

was the race condition related to the code of waylandsink or somewhere in
core of Gstreamer?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[horai]

Dear sir,

Well, does it mean that the problem lies in Weston (wayland compositor) ?
I assumed due to the fact waylandsink is in gst-plugins-bad, it is not fully
ready yet and I also assumed that gstVideoOverlay is just a glue layer to
give commands to waylandsink to behave the way we it is ordered via
gstVideoOverlay methods, lets say, we want to clear (destroy) the area
waylandsink is rendering video into, we call
gst_video_overlay_set_render_rectangle and it passes the arguments in a
exact way to waylandsink and it is up to waylandsink how it will negotiate
this request with wayland display server. Therefore, if it communicates in a
wrong way, then waylandsink does not fullfill the request and this method
will fail as I experienced in this case:
http://gstreamer-devel.966125.n4.nabble.com/gst-video-overlay-set-render-rectangle-td4691801.html.
Could my assumption be correct?
If I understand it correctly, that race-condition is just another case where
waylandsink fails to do something correctly when talking to wayland server
as in my case multiple pipelines need to be disconnected from the server.
And this fails randomly, not always since according to Gstreamer
documentation there is no extra need to take care of threads when having
multiple pipeline in single application.
Could it be possible that the problem really lies in waylandsink improper
communication and not in compositor (Weston) code? If my assumption is
correct, I guess following this documentation we could try to fix it to suit
our needs:
https://wayland.freedesktop.org/docs/html/apb.html




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel