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 702495 - sdpdemux fails if not explicitly added to the pipeline
sdpdemux fails if not explicitly added to the pipeline
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2013-06-17 17:18 UTC by erik
Modified: 2018-11-03 13:15 UTC
See Also:
GNOME target: ---
GNOME version: ---

sdp file (194 bytes, application/vnd.stardivision.impress)
2013-06-17 17:18 UTC, erik

Description erik 2013-06-17 17:18:37 UTC
Created attachment 247054 [details]
sdp file

Steps to reproduce:
1. Create a send-pipeline with
gst-launch-1.0 videotestsrc ! x264enc ! h264parse ! rtph264pay ! udpsink host= port=5000

2. With the attached sdp-file launch this pipeline:
gst-launch-1.0 -v filesrc location=stream.sdp ! decodebin ! autovideosink

This won't show any video.
Same pipeline works with GStreamer 0.10.

Now lets add the a sdpdemux element to the pipeline:
gst-launch-1.0 -v filesrc location=stream.sdp ! sdpdemux ! decodebin ! autovideosink
Result: A Video is shown.

But for some reason with the original pipeline its not.
Comment 1 Sebastian Dröge (slomo) 2013-06-18 11:18:37 UTC
I can confirm this, also with latest git master.
Comment 2 Wim Taymans 2013-06-20 13:26:15 UTC
It is a known problem I have no fix for... The reason is that the live element is added dynamically to the pipeline and there is nothing in GStreamer to signal the pipeline that it should not wait for PREROLL but go to PLAYING right away.
Comment 3 Tim-Philipp Müller 2013-07-11 13:52:47 UTC
It's not entirely clear to me why this worked in 0.10 then - were there any changes in this area?
Comment 4 Olivier Crête 2013-09-20 18:33:28 UTC
In 0.10, in pull mode, typefind pulled from the source during the ready->paused transition, which caused decodebin2 to add sdpdemux, so it's there by the time the decodebin2 bin tries to go to paused and NO_PREROLL gets propagated. Using pushfile:// in 0.10 also causes it to fail.
Comment 5 Olivier Crête 2013-09-21 06:39:34 UTC
The solution might be to add a no-preroll GstMessage to unlock the parent bin ? And I guess this isn't 1.2 material so we shoudl probably rank sdpdemux back to 0 in the meantime.
Comment 6 Sebastian Dröge (slomo) 2013-09-23 14:19:28 UTC
commit f33a73b35950cd3dc53efd1b4fa316935836ab8e
Author: Sebastian Dröge <>
Date:   Mon Sep 23 16:18:43 2013 +0200

    sdpdemux: Change rank to NONE until it can be autoplugged properly
Comment 7 Olivier Crête 2013-09-23 14:47:00 UTC
Not a blocker anymore then
Comment 8 Marc Leeman 2015-01-12 13:58:28 UTC
Hm, a lot of this is implemented in rtpsrc/rtpsink; I'll see if I can adjust it to use those and add it in the relevant bug.
Comment 9 Christophe Lafolet 2015-11-22 16:47:58 UTC
problem is still present 
no correction available ?
Comment 10 Sebastian Dröge (slomo) 2015-11-24 14:03:25 UTC
No solution implemented yet, needs someone for which this is a big enough problem to work on it :)
Comment 11 Sebastian Dröge (slomo) 2016-02-29 10:03:01 UTC
See for a workaround (plus some additional functionality).
Comment 12 Edward Hervey 2018-05-12 08:15:19 UTC
Shall we close since there are alternatives now ?
Comment 13 GStreamer system administrator 2018-11-03 13:15:47 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: