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 784657 - aggregator: when live, don't wait for non-started pads.
aggregator: when live, don't wait for non-started pads.
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-07-07 15:55 UTC by Mathieu Duponchelle
Modified: 2018-11-03 12:41 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
aggregator: when live, don't wait for non-started pads. (3.47 KB, patch)
2017-07-07 15:55 UTC, Mathieu Duponchelle 		reviewed Details | Review

Description Mathieu Duponchelle 2017-07-07 15:55:29 UTC 
[API]: gst_aggregator_pad_is_started

This allows adding new pads and letting them negotiate, before
letting data flow through them.
Comment 1 Mathieu Duponchelle 2017-07-07 15:55:32 UTC 
Created attachment 355101 [details] [review]
aggregator: when live, don't wait for non-started pads.
Comment 2 Olivier Crête 2017-07-07 21:23:17 UTC 
Review of attachment 355101 [details] [review]:

I don't understand how this is different from checking if the queue is empty or not ? Which the subclasses already do? If we're live, we'll get a timeout if you add new pads that have no data yet, and since the timeout flag is set when the aggregate function is called, the pads with no data will be ignored.
Comment 3 Mathieu Duponchelle 2017-08-01 15:59:43 UTC 
The idea here is that we don't want to operate on the limit of the timeout, this makes any latency set on the aggregator to cope with uneven upstream data flow irrelevant. The use case is a situation where I request a new pad, connect it to let negotiation happen while blocking data flow, ensuring the pad is then ready to start providing data at a latter time, as "immediately" as possible.
Comment 4 Olivier Crête 2017-08-07 14:18:58 UTC 
Hmm, if we want to move aggregator to the core, then we need to settle this first, as otherwise it would be an API break.

But this doesn't affect the latency for upstream data flow, if you have a problem, it means you dont have enough latency downstream..
Comment 5 GStreamer system administrator 2018-11-03 12:41:51 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/243.