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 387160 - [qtdemux] posts buffering message which can cause hangs
[qtdemux] posts buffering message which can cause hangs
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal blocker
: 0.10.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-12-18 14:55 UTC by Tim-Philipp Müller
Modified: 2006-12-18 17:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch, changes qtdemux to post an ELEMENT message instead of a BUFFERING message (1.79 KB, patch)
2006-12-18 14:57 UTC, Tim-Philipp Müller
committed Details | Review

Description Tim-Philipp Müller 2006-12-18 14:55:04 UTC
When operating in streaming mode, qtdemux posts BUFFERING messages on the bus if the stream headers are behind the movie data, to notify the user that something is happening while it reads the entire movie data into memory.

These BUFFERING messages can confuse applications like gst-launch or totem (which might change pipeline state based on them), causing 'hangs'.

qtdemux shouldn't post BUFFERING messages for this purpose.

Attached patch changes qtdemux to post element messages called "progress" instead that applications can catch separately if they want to.
Comment 1 Tim-Philipp Müller 2006-12-18 14:57:05 UTC
Created attachment 78568 [details] [review]
patch, changes qtdemux to post an ELEMENT message instead of a BUFFERING message
Comment 2 Tim-Philipp Müller 2006-12-18 17:12:25 UTC
 2006-12-18  Tim-Philipp Müller  <tim at centricular dot net>

       * gst/qtdemux/qtdemux.c: (gst_qtdemux_post_progress),
       (gst_qtdemux_chain):
         Don't post BUFFERING messages in streaming mode if the stream
         headers are behind the movie data, but post a "progress" element
         message instead as a temporary solution so that apps don't get
         confused by buffering messages from different sources (#387160).