After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 724484 - gst_element_send_event blocks when sent directly to x264enc
gst_element_send_event blocks when sent directly to x264enc
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
1.x
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-16 14:18 UTC by xlinkz0
Modified: 2014-11-24 17:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Testcase (6.54 KB, text/plain)
2014-02-16 17:42 UTC, xlinkz0
Details

Description xlinkz0 2014-02-16 14:18:36 UTC
I'm trying to remove a GstBin ( x264enc -> mp4mux -> filesink ) from the pipeline ( videotestsrc -> queue -> savebin ) from inside a blocking buffer probe callback.

I send EOS to the bin on line 159 in the attached file. The ghostpad that arrives on corresponds to the x264enc sink pad. The send_eos function never returns.

gdb output : http://codepad.org/TTssPnDD

GST_DEBUG="*enc*:6" output : http://codepad.org/F6CByGxI
Comment 1 Tim-Philipp Müller 2014-02-16 14:33:47 UTC
Could you provide a small test program that demonstrates the problem?
Comment 2 xlinkz0 2014-02-16 17:42:59 UTC
Created attachment 269317 [details]
Testcase
Comment 3 xlinkz0 2014-02-16 17:43:54 UTC
Sorry, thought i did when i submited the bug.
Comment 4 Tim-Philipp Müller 2014-02-17 00:23:36 UTC
You remove the bin from the pipeline, but then wait for the EOS message from the now-removed filesink on the pipeline bus. That's not going to happen if the element is not inside the pipeline.

Not sure why you set sync=true on filesink. But I think you want to set async=FALSE instead.
Comment 5 xlinkz0 2014-02-17 07:33:55 UTC
Thanks for pointing that out. I tried making a much more simplified testcase ( i removed the pad probe and send EOS from a timeout callback, i had the same behaviour ).

Then i tried simplifying it even further and didn't send EOS at all, just let the pipeline be with the savebin. It hangs in the same way without me sending anything or blocking anything. My guess is that there is something wrong with the savebin but I don't see it.. hopefully someone else will.

http://codepad.org/k6dXgbWu
Comment 6 Tim-Philipp Müller 2014-11-24 17:48:27 UTC
Yes, that's because you have an unlinked fakesink in the pipeline (and an unlinked x264enc).

Not sure what you expect. The gstreamer-devel list might be a better place to get help debugging such issues.

Also, please attach sample code as attachment to the bug in future, thanks!