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 663263 - gst-launch stuck in buffering for local sources
gst-launch stuck in buffering for local sources
Status: RESOLVED DUPLICATE of bug 655790
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-11-02 20:19 UTC by Jonas Larsson
Modified: 2012-01-23 18:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jonas Larsson 2011-11-02 20:19:45 UTC
gst-launch stays in PAUSED for ever if pipeline finishes buffering quickly. This happens for example with playbin2 using a local source.

gst-launch -m playbin2 uri=file:///local.mp4 video-sink="texturesink internalGL=true" audio-sink=fakesink flags=native-audio+native-video+buffering+download

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ..
GstMessageBuffering, buffer-percent=(int)0
....
GstMessageBuffering, buffer-percent=(int)100
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Prerolled, waiting for buffering to finish...

At this point the preroll frame is shown but playback never starts. If using a network source so buffering is slower it works fine. Not passing the buffering flag for local sources also work fine. The reason for setting buffering flag is a goal of having one generic pipeline for all URI:s and network buffering is required.

(texturesink is a closed source element, but should be irrelevant for gst-launch buffering handling)
Comment 1 Vincent Penquerc'h 2012-01-23 18:21:41 UTC

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