[Bug 749517] New: gstaggregator won't start until all pads have a buffer
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Sun May 17 13:42:18 PDT 2015
https://bugzilla.gnome.org/show_bug.cgi?id=749517
Bug ID: 749517
Summary: gstaggregator won't start until all pads have a buffer
Classification: Platform
Product: GStreamer
Version: git master
OS: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: gst-plugins-bad
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: philippe_renon at yahoo.fr
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
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 at
least one pad has a buffer and was happy to see it start in a use case where it
previously was not. I can 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 pipeline 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 being 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 one pad has a buffer.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list