[Bug 788754] New: block pipeline at PREROLLED in wayland

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

Bug ID: 788754
Summary: block pipeline at PREROLLED in wayland
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-bad
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@163.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---

Created attachment 361214
--> https://bugzilla.gnome.org/attachment.cgi?id=361214&action=edit
fix pipeline block at PREROLLED bug.

environment:
GST_GL_WINDOW=wayland
GST_GL_PLATFORM=egl

pipeline:
gst-launch-1.0 playbin uri=file:///home/ye/test.MOV video-sink=glimagesink

issue:
sometimes, pipeline block at PREROLLED, about one-twentieth probability.

try:
I found that "done" value changed too late because has entered the next
cycle, so I try to add little delay after dispatching queue, pipeline block
issue disappeared. detail please ref to patch.
it's a stupid solution since I'm clueless. Do you have any good ideal to fix
this issue?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

ChenglinYe <***@163.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@163.com

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

ChenglinYe <***@163.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|block pipeline at PREROLLED |sometimes block pipeline at
|in wayland |PREROLLED in wayland

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

Tim-Philipp Müller <***@zen.co.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@zen.co.uk
Summary|sometimes block pipeline at |gl: wayland: sometimes
|PREROLLED in wayland |block pipeline at PREROLLED

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

Nicolas Dufresne (stormer) <***@ndufresne.ca> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #361214|none |rejected
status| |

--- Comment #1 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
Review of attachment 361214:
--> (https://bugzilla.gnome.org/review?bug=788754&attachment=361214)

This is just a hack. How do you reproduce this ?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

Nicolas Dufresne (stormer) <***@ndufresne.ca> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@ndufresne.ca

--- Comment #2 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
Actually, it just happened here locally ! According to the backtrace, it is
like you described, not a deadlock, but a stall.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #3 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
I must admit, I'm a bit clueless too. I wonder why the roundtrip code has been
made so horrible. If you compare with gst_wl_display_roundtrip() (same function
in waylandsink), the GL one is so complicated. I could not reproduce this issue
on waylandsink, so the extra complexity seems unjustified.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #4 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
I wonder why alt+tab "fixes" the issue.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #5 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
To my previous comment, because there was nothing queued to roundtrip with. In
fact, if I remove the roundtrip completly, the problem goes away.

Why do we added this roundtrip in the first place ?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #6 from Chenglin Ye <***@163.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #1)

Post by "GStreamer" (GNOME Bugzilla)
This is just a hack. How do you reproduce this ?

It's just a try, but I also can not explain why this issue disappeared after a
little delay, I am sorry for my clueless.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #7 from Chenglin Ye <***@163.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #3)

Post by "GStreamer" (GNOME Bugzilla)
I must admit, I'm a bit clueless too. I wonder why the roundtrip code has
been made so horrible. If you compare with gst_wl_display_roundtrip() (same
function in waylandsink), the GL one is so complicated. I could not
reproduce this issue on waylandsink, so the extra complexity seems
unjustified.

I will reference with gst_wl_display_roundtrip() (same function in
waylandsink). Thanks for your explaintion.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

Matthew Waters (ystreet00) <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #8 from Matthew Waters (ystreet00) <***@gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #3)

Post by "GStreamer" (GNOME Bugzilla)
I must admit, I'm a bit clueless too. I wonder why the roundtrip code has
been made so horrible. If you compare with gst_wl_display_roundtrip() (same
function in waylandsink), the GL one is so complicated. I could not
reproduce this issue on waylandsink, so the extra complexity seems
unjustified.

The roundtrip is complicated becuase
1. it deals with both the default-wl_queue and separate wl_queue cases
2. It attempts to solve a race where setting the wl_proxy races with others
reading the queue.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #9 from Matthew Waters (ystreet00) <***@gmail.com> ---
There is also a comment at the top relating to thread safety. Is the blocking
case breaking that case? If queue == NULL, the roundtrip should only be called
on the display thread. if queue != NULL them the thread must be the GL thread.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #10 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
I'm a bit too clueless to answer your questions. Normally, one will do a
roundtrip not to work around a race, but to ensure an asynchronous request get
processed before continuing (that's what waylandsink does). It's not clear that
there is anything really pending for sure when we do this round trip. Running
alt+tab generate 1 roundtrip, hence un-blocking the call.

How do you reproduce the race this roundtrip was supposedly fixing ? I haven't
had any issue yet removing the roundtrip completly. Another weird thing in the
code, is that the roundtrip happens in _show, after create, but never after any
other "create" calls. And the window create function is more like an "ensure"
function, maybe it has something to do with when the window is created ?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #11 from Matthew Waters (ystreet00) <***@gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #10)

Post by "GStreamer" (GNOME Bugzilla)
I'm a bit too clueless to answer your questions. Normally, one will do a
roundtrip not to work around a race, but to ensure an asynchronous request
get processed before continuing (that's what waylandsink does). It's not
clear that there is anything really pending for sure when we do this round
trip. Running alt+tab generate 1 roundtrip, hence un-blocking the call.
How do you reproduce the race this roundtrip was supposedly fixing ?

The race I mention is in the roundtrip function of most other wayland roundtrip
functions where setting the wl_queue of a wl_proxy can race with another thread
emptying the event queue and thus calling the callback on the default
wl_display queue rather than the meant to be set wl_queue.

Post by "GStreamer" (GNOME Bugzilla)
I haven't had any issue yet removing the roundtrip completly.

Are you only trying with GStreamer? The issues will come integrating with any
other wayland using library like Gtk, Qt, etc where the reproduction was that
GStreamer's surface was not displayed at all (until someone did a roundtrip
with resize, window switching, keypress, etc).

Post by "GStreamer" (GNOME Bugzilla)
Another weird
thing in the code, is that the roundtrip happens in _show, after create, but
never after any other "create" calls. And the window create function is more
like an "ensure" function, maybe it has something to do with when the window
is created ?

In short the roundtrip is processing all the asynchronous requests, not solving
a race.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #12 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
(In reply to Matthew Waters (ystreet00) from comment #11)

Post by "GStreamer" (GNOME Bugzilla)

Post by "GStreamer" (GNOME Bugzilla)
I haven't had any issue yet removing the roundtrip completly.

Are you only trying with GStreamer? The issues will come integrating with
any other wayland using library like Gtk, Qt, etc where the reproduction was
that GStreamer's surface was not displayed at all (until someone did a
roundtrip with resize, window switching, keypress, etc).

Yes, with GStreamer. It's funny, since this is exactly the description of the
bug we are facing here, which get fixed by removing the roundtrip.

Now, if this is racing, it means that external compoenent are also doing some
stuff on the queue from other threads. This is miss-use of wayland queues
really.

Post by "GStreamer" (GNOME Bugzilla)

Post by "GStreamer" (GNOME Bugzilla)
Another weird
thing in the code, is that the roundtrip happens in _show, after create, but
never after any other "create" calls. And the window create function is more
like an "ensure" function, maybe it has something to do with when the window
is created ?

In short the roundtrip is processing all the asynchronous requests, not
solving a race.

But it also waits if there is nothing to process, and that seems like the issue
we are facing.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #13 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
Btw, if you can find back such an application that would show that a roundtrip
inside _show() call is sometimes needed, that could unblock this issue. I think
user-input in full app is what makes this case less visible, but could easily
appear in kiosk or digital signage applications. This random roundtrip call
looks generally harmful and random.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #14 from Matthew Waters (ystreet00) <***@gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #12)

Post by "GStreamer" (GNOME Bugzilla)
Now, if this is racing, it means that external compoenent are also doing
some stuff on the queue from other threads. This is miss-use of wayland
queues really.

Precisely.

Post by "GStreamer" (GNOME Bugzilla)
But it also waits if there is nothing to process, and that seems like the
issue we are facing.

"nothing to process" is not quite correct. The wl_callback that is installed is
"something to process". It would only hang if the wl_callback is processed
somewhere else.

Post by "GStreamer" (GNOME Bugzilla)
But it also waits if there is nothing to process, and that seems like the
issue we are facing.

Which is why it's only safe to be called from the thread that will be reading
events from the specified wl_queue (as mentioned in the comment above
_roundtrip()) and thus my response in comment 9 asking for a backtrace if this
was the case or not when the hang occurs and if this is a problem in GStreamer
itself.

(In reply to Nicolas Dufresne (stormer) from comment #13)

Post by "GStreamer" (GNOME Bugzilla)
Btw, if you can find back such an application that would show that a
roundtrip inside _show() call is sometimes needed, that could unblock this
issue. I think user-input in full app is what makes this case less visible,
but could easily appear in kiosk or digital signage applications. This
random roundtrip call looks generally harmful and random.

IIRC, the gtk videooverlay examples in -bad exhibited the hang sporadically.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #15 from Matthew Waters (ystreet00) <***@gmail.com> ---
e.g. I can get the following stall on startup with
-bad/gl/gtk/filtervideooverlay/filtervideooverlay which is becuse mesa's
wayland GL handling doesn't take into account the race possible with setting a
wl_proxy's wl_queue in
https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c

(gdb) t a a bt

Thread 8 (Thread 0x7fffcbdfa700 (LWP 3633)):
#0 0x00007ffff219bc49 in syscall () at /usr/lib/libc.so.6
#1 0x00007ffff35be6b1 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007fffe9ee57f4 in gst_gl_window_default_send_message
(window=0x5555557ba040, callback=<optimized out>, data=<optimized out>) at
gstglwindow.c:603
#3 0x00007fffea131eb5 in gst_glimage_sink_redisplay
(gl_sink=***@entry=0x555555e31df0) at gstglimagesink.c:2377
#4 0x00007fffea132390 in gst_glimage_sink_show_frame (vsink=<optimized out>,
buf=<optimized out>) at gstglimagesink.c:1741
#5 0x00007ffff4a8f3ce in gst_base_sink_chain_unlocked
(basesink=***@entry=0x555555e31df0, obj=***@entry=0x5555557eae00,
is_list=***@entry=0, pad=<optimized out>) at gstbasesink.c:3546
#6 0x00007ffff4a90150 in gst_base_sink_chain_main (basesink=0x555555e31df0,
pad=<optimized out>, obj=0x5555557eae00, is_list=0) at gstbasesink.c:3672
#7 0x00007ffff479ff73 in gst_pad_chain_data_unchecked (data=0x5555557eae00,
type=4112, pad=0x555555e1d930) at gstpad.c:4215
#8 0x00007ffff479ff73 in gst_pad_push_data (pad=***@entry=0x555555e1d6f0,
type=***@entry=4112, data=***@entry=0x5555557eae00) at gstpad.c:4471
#9 0x00007ffff47a84e3 in gst_pad_push (pad=0x555555e1d6f0,
buffer=0x5555557eae00) at gstpad.c:4590
#10 0x00007ffff4a9c87f in gst_base_transform_chain (pad=<optimized out>,
parent=<optimized out>, buffer=<optimized out>) at gstbasetransform.c:2312
#11 0x00007ffff479ff73 in gst_pad_chain_data_unchecked (data=0x5555557eae00,
type=4112, pad=0x555555e1d4b0) at gstpad.c:4215
#12 0x00007ffff479ff73 in gst_pad_push_data (pad=***@entry=0x555555e1d270,
type=***@entry=4112, data=***@entry=0x5555557eae00) at gstpad.c:4471
#13 0x00007ffff47a84e3 in gst_pad_push (pad=0x555555e1d270,
buffer=0x5555557eae00) at gstpad.c:4590
#14 0x00007ffff4a9c87f in gst_base_transform_chain (pad=<optimized out>,
parent=<optimized out>, buffer=<optimized out>) at gstbasetransform.c:2312
#15 0x00007ffff479ff73 in gst_pad_chain_data_unchecked (data=0x5555557eae00,
type=4112, pad=0x555555e1d030) at gstpad.c:4215
#16 0x00007ffff479ff73 in gst_pad_push_data (pad=***@entry=0x555555e1cdf0,
type=***@entry=4112, data=***@entry=0x5555557eae00) at gstpad.c:4471
#17 0x00007ffff47a84e3 in gst_pad_push (pad=0x555555e1cdf0,
buffer=0x5555557eae00) at gstpad.c:4590
#18 0x00007ffff4a9c87f in gst_base_transform_chain (pad=<optimized out>,
parent=<optimized out>, buffer=<optimized out>) at gstbasetransform.c:2312
#19 0x00007ffff479ff73 in gst_pad_chain_data_unchecked (data=0x5555557eae00,
type=4112, pad=0x555555e1cbb0) at gstpad.c:4215
#20 0x00007ffff479ff73 in gst_pad_push_data (pad=***@entry=0x555555e421f0,
type=***@entry=4112, data=***@entry=0x5555557eae00) at gstpad.c:4471
#21 0x00007ffff47a84e3 in gst_pad_push (pad=***@entry=0x555555e421f0,
buffer=***@entry=0x5555557eae00) at gstpad.c:4590
#22 0x00007ffff478e04b in gst_proxy_pad_chain_default (pad=<optimized out>,
parent=<optimized out>, buffer=0x5555557eae00) at gstghostpad.c:127
#23 0x00007ffff479ff73 in gst_pad_chain_data_unchecked (data=0x5555557eae00,
type=4112, pad=0x555555e40050) at gstpad.c:4215
#24 0x00007ffff479ff73 in gst_pad_push_data (pad=***@entry=0x555555e1c970,
type=***@entry=4112, data=***@entry=0x5555557eae00) at gstpad.c:4471
#25 0x00007ffff47a84e3 in gst_pad_push (pad=0x555555e1c970,
buffer=0x5555557eae00) at gstpad.c:4590
#26 0x00007ffff4a9c87f in gst_base_transform_chain (pad=<optimized out>,
parent=<optimized out>, buffer=<optimized out>) at gstbasetransform.c:2312
#27 0x00007ffff479ff73 in gst_pad_chain_data_unchecked (data=0x5555557eacf0,
type=4112, pad=0x555555e1c730) at gstpad.c:4215
#28 0x00007ffff479ff73 in gst_pad_push_data (pad=***@entry=0x555555e1c4f0,
type=***@entry=4112, data=***@entry=0x5555557eacf0) at gstpad.c:4471
#29 0x00007ffff47a84e3 in gst_pad_push (pad=0x555555e1c4f0,
buffer=0x5555557eacf0) at gstpad.c:4590
#30 0x00007ffff4a9c87f in gst_base_transform_chain (pad=<optimized out>,
parent=<optimized out>, buffer=<optimized out>) at gstbasetransform.c:2312
#31 0x00007ffff479ff73 in gst_pad_chain_data_unchecked (data=0x5555557eacf0,
type=4112, pad=0x555555e1c2b0) at gstpad.c:4215
#32 0x00007ffff479ff73 in gst_pad_push_data (pad=***@entry=0x555555e1ddb0,
type=***@entry=4112, data=***@entry=0x5555557eacf0) at gstpad.c:4471
#33 0x00007ffff47a84e3 in gst_pad_push (pad=0x555555e1ddb0,
buffer=0x5555557eacf0) at gstpad.c:4590
#34 0x00007ffff4a9c87f in gst_base_transform_chain (pad=<optimized out>,
parent=<optimized out>, buffer=<optimized out>) at gstbasetransform.c:2312
#35 0x00007ffff479ff73 in gst_pad_chain_data_unchecked (data=0x5555557eacf0,
type=4112, pad=0x555555e1db70) at gstpad.c:4215
#36 0x00007ffff479ff73 in gst_pad_push_data (pad=***@entry=0x555555e1c070,
type=***@entry=4112, data=***@entry=0x5555557eacf0) at gstpad.c:4471
#37 0x00007ffff47a84e3 in gst_pad_push (pad=***@entry=0x555555e1c070,
buffer=0x5555557eacf0) at gstpad.c:4590
#38 0x00007ffff4a95855 in gst_base_src_loop (pad=0x555555e1c070) at
gstbasesrc.c:2918
#39 0x00007ffff47d4819 in gst_task_func (task=0x555555e4d170) at gsttask.c:332
#40 0x00007ffff3585f5b in () at /usr/lib/libglib-2.0.so.0
#41 0x00007ffff358b1eb in () at /usr/lib/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#42 0x00007ffff246908a in start_thread () at /usr/lib/libpthread.so.0
#43 0x00007ffff21a124f in clone () at /usr/lib/libc.so.6

Thread 7 (Thread 0x7fffdab7c700 (LWP 3632)):
#0 0x00007ffff2196d4b in poll () at /usr/lib/libc.so.6
#1 0x00007ffff3596ed3 in () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff3597f42 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3 0x00007fffe9ec8847 in _event_thread_main (display=0x7fffcc002050) at
gstgldisplay.c:143
#4 0x00007ffff358b1eb in () at /usr/lib/libglib-2.0.so.0
#5 0x00007ffff246908a in start_thread () at /usr/lib/libpthread.so.0
#6 0x00007ffff21a124f in clone () at /usr/lib/libc.so.6

Thread 6 (Thread 0x7fffdb37d700 (LWP 3631)):
#0 0x00007ffff2196d4b in poll () at /usr/lib/libc.so.6
#1 0x00007ffff517a4ab in () at /usr/lib/libwayland-client.so.0
#2 0x00007ffff517bb8e in wl_display_dispatch_queue () at
/usr/lib/libwayland-client.so.0
#3 0x00007fffda160084 in () at /usr/lib/libEGL_mesa.so.0
#4 0x00007fffda152996 in eglSwapBuffers () at /usr/lib/libEGL_mesa.so.0
#5 0x00007fffe9ef396d in draw_cb (data=0x5555557ba040) at
gstglwindow_wayland_egl.c:507
#6 0x00007fffe9ee4b83 in _run_message_sync (message=0x7fffcbdf8ec0) at
gstglwindow.c:577
#7 0x00007fffe9ee4b22 in _run_message_async (message=0x555555b38160) at
gstglwindow.c:644
#8 0x00007ffff35950be in g_main_context_dispatch () at
/usr/lib/libglib-2.0.so.0
#9 0x00007ffff3596f69 in () at /usr/lib/libglib-2.0.so.0
#10 0x00007ffff3597f42 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#11 0x00007fffe9ee4c05 in gst_gl_window_default_run (window=0x5555557ba040) at
gstglwindow.c:503
#12 0x00007fffe9ecca39 in gst_gl_context_create_thread (context=0x7fffe40165b0)
at gstglcontext.c:1309
#13 0x00007ffff358b1eb in () at /usr/lib/libglib-2.0.so.0
#14 0x00007ffff246908a in start_thread () at /usr/lib/libpthread.so.0
#15 0x00007ffff21a124f in clone () at /usr/lib/libc.so.6

Thread 5 (Thread 0x7fffdbb7e700 (LWP 3630)):
#0 0x00007ffff2196d4b in poll () at /usr/lib/libc.so.6
#1 0x00007ffff3596ed3 in () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff3597f42 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3 0x00007fffe9ec8847 in _event_thread_main (display=0x5555557ea390) at
gstgldisplay.c:143
#4 0x00007ffff358b1eb in () at /usr/lib/libglib-2.0.so.0
#5 0x00007ffff246908a in start_thread () at /usr/lib/libpthread.so.0
#6 0x00007ffff21a124f in clone () at /usr/lib/libc.so.6

Thread 1 (Thread 0x7ffff7f98e00 (LWP 3612)):
#0 0x00007ffff219bc49 in syscall () at /usr/lib/libc.so.6
#1 0x00007ffff35be6b1 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007fffe9ee57f4 in gst_gl_window_default_send_message
(window=0x5555557ba040, callback=<optimized out>, data=<optimized out>) at
gstglwindow.c:603
#3 0x00007fffea131eb5 in gst_glimage_sink_redisplay (gl_sink=<optimized out>)
at gstglimagesink.c:2377
#4 0x00007fffea12ea60 in gst_gl_sink_bin_overlay_expose (overlay=<optimized
out>) at gstglsinkbin.c:448
#5 0x000055555555659f in expose_cb(GtkWidget*, cairo_t*, GstElement*)
(widget=0x555555e4d0f0, cr=0x555555b8e400, videosink=0x55555578baa0) at
main.cpp:105
#6 0x00007ffff76f4098 in () at /usr/lib/libgtk-3.so.0
#7 0x00007ffff784457d in () at /usr/lib/libgtk-3.so.0
#8 0x00007ffff387dc01 in g_signal_emit_valist () at
/usr/lib/libgobject-2.0.so.0
#9 0x00007ffff387e920 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#10 0x00007ffff7851963 in () at /usr/lib/libgtk-3.so.0
#11 0x00007ffff762694f in gtk_container_propagate_draw () at
/usr/lib/libgtk-3.so.0
#12 0x00007ffff7626a33 in () at /usr/lib/libgtk-3.so.0
#13 0x00007ffff785f9af in () at /usr/lib/libgtk-3.so.0
#14 0x00007ffff7851730 in () at /usr/lib/libgtk-3.so.0
#15 0x00007ffff785aee3 in () at /usr/lib/libgtk-3.so.0
#16 0x00007ffff76f2f5a in gtk_main_do_event () at /usr/lib/libgtk-3.so.0
#17 0x00007ffff71fc6f6 in () at /usr/lib/libgdk-3.so.0
#18 0x00007ffff720d03b in () at /usr/lib/libgdk-3.so.0
#19 0x00007ffff720e299 in () at /usr/lib/libgdk-3.so.0
#20 0x00007ffff720e499 in () at /usr/lib/libgdk-3.so.0
#21 0x00007ffff38656f5 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#22 0x00007ffff38790b0 in () at /usr/lib/libgobject-2.0.so.0
#23 0x00007ffff387d696 in g_signal_emit_valist () at
/usr/lib/libgobject-2.0.so.0
#24 0x00007ffff387e920 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#25 0x00007ffff720600a in () at /usr/lib/libgdk-3.so.0
#26 0x00007ffff71f07c3 in () at /usr/lib/libgdk-3.so.0
#27 0x00007ffff3593cb3 in () at /usr/lib/libglib-2.0.so.0
#28 0x00007ffff35950be in g_main_context_dispatch () at
/usr/lib/libglib-2.0.so.0
#29 0x00007ffff3596f69 in () at /usr/lib/libglib-2.0.so.0
#30 0x00007ffff3597f42 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#31 0x00007ffff76f211f in gtk_main () at /usr/lib/libgtk-3.so.0
#32 0x0000555555557097 in main(gint, gchar**) (argc=1, argv=0x7fffffffb3c8) at
main.cpp:292
(gdb)

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

Matthew Waters (ystreet00) <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO

--- Comment #16 from Matthew Waters (ystreet00) <***@gmail.com> ---
So, I guess the question is, is this actually our fault? As a result, a
backtrace would be most helpful in determining where the blame lies.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

Tim-Philipp Müller <***@zen.co.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
Component|gst-plugins-bad |gst-plugins-base

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

Matthew Waters (ystreet00) <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution|--- |DUPLICATE

--- Comment #17 from Matthew Waters (ystreet00) <***@gmail.com> ---


*** This bug has been marked as a duplicate of bug 758984 ***