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 371969 - [Discoverer] Issues with demuxers that don't create pads straight away
[Discoverer] Issues with demuxers that don't create pads straight away
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-python
git master
Other Linux
: Normal normal
: 0.10.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-11-07 12:17 UTC by Edward Hervey
Modified: 2006-11-07 12:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Edward Hervey 2006-11-07 12:17:49 UTC 
With some formats (more specifically mpeg ones), the demuxers don't create the source pads straight away but only when they encounter the first chunk of data of the stream.
This causes issues in the discoverer where, for an audio/video mpeg file, the discoverer gives eroneous output (sometimes there's audio, sometimes there isn't).
Comment 1 Edward Hervey 2006-11-07 12:20:29 UTC 
One quick solution is to set the queues between decodebin and the fakesinks to buffer-up a given amount of data before outputting to the sinks, thereby delaying the pipeline switching to PAUSED.

This should give enough time for the demuxers to discover some more about the muxed stream and find new pads.
Comment 2 Edward Hervey 2006-11-07 12:24:43 UTC 
2006-11-07  Edward Hervey  <edward@fluendo.com>

	* gst/extend/discoverer.py: Make the queue buffer up 1s of data before
	outputting to the sinks. This should give time for some demuxers like
	mpegdemux or fluasfdemux to discover a bit more about the muxed
	stream and add the correct pads.
	Fixes #371969