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 690146 - Cannot transit to PLAY state with a new sink bin that composed of two sink elements
Cannot transit to PLAY state with a new sink bin that composed of two sink el...
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.0.3
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-12-13 09:03 UTC by pklai
Modified: 2012-12-14 10:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Create a sink bin (1.65 KB, text/plain)
2012-12-13 09:03 UTC, pklai
Details

Description pklai 2012-12-13 09:03:13 UTC
Created attachment 231451 [details]
Create a sink bin

I create a new sink bin that composes of an autoaudiosink element and an appsink elemnet. The appsink is used for capturing raw PCM data. The newly create sink bin is attached to the playbin's "audio-sink" path. It works fine on gstreamer-0.10. However, when I port it to gstreamer-1.0, it just hang without transit to PLAY state. When only one of the sink element (that is, only use one of the "tee" output) is used, it works and can enter PLAY state:- for appsink, it can get new sample; for autoaudiosink, it can output sound. I don't know what is going wrong, can you give me a hand?

Attached is the code that I used to create the sink bin.

Regards,
Colman
Comment 1 Tim-Philipp Müller 2012-12-13 13:17:43 UTC
Have you tried putting a queue in front of each sink? Only using one queue makes assumptions about the order in which tee pushes buffers, which you can't really do (not in 0.10 either).
Comment 2 pklai 2012-12-14 01:59:19 UTC
Thank you. After adding the queue, it works now. But I don't know why it can work in 0.10.

Colman
Comment 3 Tim-Philipp Müller 2012-12-14 10:12:16 UTC
Pure luck really. In 0.10 it probably first pushed on the pad where you connected the queue, whereas in 1.0 it first pushes on the pad without queue for some reason. The 0.10 behaviour might have changed at any point as well.

Anyway, great to hear it works now.