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 791218 - Move GstAudioAggregator and audiomixer to -base
Move GstAudioAggregator and audiomixer to -base
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 757563 786344
Blocks:
 
 
Reported: 2017-12-04 18:45 UTC by Tim-Philipp Müller
Modified: 2018-02-13 17:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim-Philipp Müller 2017-12-04 18:45:49 UTC
Aggregator is in core now, so make a tracker bug for audio aggregator.

Mathieu mentions two things:

1) implement input conversion (bug #786344)

2) looping / non-flushing seeks should work (bug #757563)

Anything else?

The second isn't really a blocker if we know it just needs to be implemented and just requires new API, no backwards-incompatible changes. And I think that's the case (just new API)?
Comment 1 Tim-Philipp Müller 2017-12-08 17:53:26 UTC
I'm not convinced that looping/non-flushing seeks are a blocker that holds up a move to -base, especially since it looks like it wouldn't require API or other major backwards-incompatible changes.

So I'm inclined to move it once 1) is in.

Any objections or other comments, please shout now :)
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2017-12-23 20:30:54 UTC
If I can submit my patches before the move, that'd be great.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2017-12-23 20:32:18 UTC
The ones in https://bugzilla.gnome.org/show_bug.cgi?id=757563 to be clear. Any objections?
Comment 4 Tim-Philipp Müller 2018-01-27 11:35:28 UTC
If you want to get patches in before any move, now would be a good time (but they will still apply afterwards of course, so I guess it doesn't really matter).
Comment 5 Sebastian Dröge (slomo) 2018-02-05 08:00:36 UTC
I would suggest that we move it this cycle. The remaining patches don't change any existing behaviour but only fix bugs, and could be added at any time later once they're ready. And from what I understand, these patches are already somewhat ready, as in: they improve the non-flushing seek behaviour and make it work for many use-cases, but they don't solve everything yet. So the patches should probably also get in at this point, additional bugs can be fixed later.

The elements are already very useful as-is and in every regard better than adder.
Comment 6 Tim-Philipp Müller 2018-02-13 17:20:04 UTC
Done.