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 749515 - gstaggregator won't start until all pads have a buffer
gstaggregator won't start until all pads have a buffer
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-05-17 20:37 UTC by Philippe Renon
Modified: 2015-05-17 20:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philippe Renon 2015-05-17 20:37:21 UTC
gstaggregator won't start until all pads have a buffer Which is a shame really since it can handle all sorts of events (pads added/removed, format changes, ...).

I quickly hacked gst_aggregator_check_pads_ready() to make it return true if a at least one pad has a buffer and was happy to see it start in a use case where it previously was not. I cna give more details about the use case/pipeline.

My use case has 2 branches feeding into a GstCompositor element. Both branches do not start at the same time but I would like the pipeline to start anyways.
With the hack mentioned above the popeline will start in any case.

But depending on which branch starts first I get good or bad results.
I think it is due to clock or latency beeing improperly handled.

I am quite new to gstreamer development so I am seeking guidance/hints/help on how to improve gstaggregator so it can start whenever on pad has a buffer.