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 734148 - hlsdemux: don't start playing if I use it from uridecodebin
hlsdemux: don't start playing if I use it from uridecodebin
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.4.0
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-08-01 22:30 UTC by m][sko
Modified: 2014-08-02 05:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description m][sko 2014-08-01 22:30:59 UTC 
If I use hls stream from uridecodebin, pipeline don't start  

gst-launch-1.0 uridecodebin uri="http://playertest.longtailvideo.com/adaptive/bbbfull/bbbfull.m3u8" name=demux \
 demux. ! 'video/x-raw' ! videoconvert ! videoscale ! autovideosink \
 demux. ! 'audio/x-raw' ! fakesink \
 2>&1
Comment 1 Thiago Sousa Santos 2014-08-02 05:21:17 UTC 
This is not a bug, there are 2 issues with this use with gst-launch

1) You need queues after demuxers to allow each sink to run on its own thread, otherwise a deadlock happens. Not only hls, with any demuxer.

2) Even when you use queues, hlsdemux will switch pads if it wants to use a new bitrate, causing new pads to be exposed that need to be handled by the application. gst-launch doesn't handle this case as it will only link the first pads that appear. Playbin can play as it will handle all pads at any time during the stream.