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 730626 - Pipeline stuck
Pipeline stuck
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.2.3
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-05-23 10:04 UTC by morgan
Modified: 2016-02-21 23:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description morgan 2014-05-23 10:04:46 UTC
Pipeline stuck, if I run use matroskamux with audio and video sink pads.
But running main.c with only audio or video sink pad works fine.

Feel free to let me know, if you need more information.

[Detail Information on GitHub]
http://tinyurl.com/qx7n3hm
Comment 1 Tim-Philipp Müller 2014-05-23 10:42:04 UTC
Refering to https://github.com/MorganLu/Gstreamer/blob/master/pipeline.png:
Does it work without the outputselector and with just matroskamux ! fakesink ? If yes, the problem is that the pipeline won't preroll unless *all* sinks have received a buffer, which is not going to happen because of the output selector. Solution: set the sync that will not receive any buffers at the beginning to async=false.
Comment 2 morgan 2014-05-24 00:52:05 UTC
Thanks for your reply, and I tried the case you suggested.
It still not works when apply audio and video to matroskamux,
when you set state of it(play->ready->play).

Further information:

If running program with --gst-debug-level=5, 
program will stuck at gst_element_set_state(muxElnt, GST_STATE_READY);
and the last line of debug message is "stopping collect pads"

Is this situation meaning that there is a bug of matroskamux when apply both audio and video streams?
Comment 3 morgan 2014-05-24 01:08:11 UTC
Thanks for your reply, and I tried the case you suggested.
It still not works when apply audio and video to matroskamux,
when you set state of it(play->ready->play).

Further information:

If running program with --gst-debug-level=5, 
program will stuck at gst_element_set_state(muxElnt, GST_STATE_READY);
and the last line of debug message is "stopping collect pads"

Is this situation meaning that there is a bug of matroskamux when apply both audio and video streams?
Comment 4 Tim-Philipp Müller 2014-05-24 09:43:50 UTC
Could you please provide a minimal example that just shows the problem without any changes that have to be made to the code, or interaction by the user?
Comment 5 André Klapper 2015-01-05 01:51:10 UTC
morgan: Please answer comment 4.
Comment 6 Tim-Philipp Müller 2016-02-21 23:55:08 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!