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 708867 - rtsp: stream does not start with playbin until all rtp sessions got data
rtsp: stream does not start with playbin until all rtp sessions got data
Status: RESOLVED DUPLICATE of bug 737231
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.2.0
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-26 19:16 UTC by Arnaud Vrac
Modified: 2015-09-03 11:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Arnaud Vrac 2013-09-26 19:16:03 UTC
I'm trying to play a stream from an RTSP server, which has elementary audio and video on separate rtp channels.

The stream plays fine in all cases when using a static pipeline, like this one:

gst-launch-1.0 rtspsrc location=rtsp://127.0.0.1:53923/211790253373785 name=src
  src. ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! xvimagesink
  src. ! rtpmp4gdepay ! aacparse ! avdec_aac ! audioconvert ! pulsesink

However playback does not start until audio is received when using playbin. The problem is that this stream has sparse audio, sometimes the server does not stream any audio, while audio is still advertised in the SDP. rtspsrc only calls gst_element_no_more_pads until all pads are exposed in the rtpmanager element, which only happens after data has been received on all input pads. Playbin does not preroll until no_more_pads has been called.

Is there an easy way to fix this ? I've tried calling no_more_pads very early in rtspsrc but if I do that no video nor audio is played.

Thanks
Comment 1 Jan Schmidt 2015-09-03 11:50:33 UTC
This is the same as bug #737231, which has a bit more discussion - so let's dupe this one to there, even though this bug was filed first.

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