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 793917 - audioaggregator: Conversion API is confusing
audioaggregator: Conversion API is confusing
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal blocker
: 1.13.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 793933 793934
Blocks:
 
 
Reported: 2018-02-28 14:46 UTC by Sebastian Dröge (slomo)
Modified: 2018-02-28 23:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
audioaggregator: refactor conversion API (20.49 KB, patch)
2018-02-28 18:50 UTC, Mathieu Duponchelle
none Details | Review
audioaggregator: refactor conversion API (21.18 KB, patch)
2018-02-28 23:40 UTC, Mathieu Duponchelle
committed Details | Review

Description Sebastian Dröge (slomo) 2018-02-28 14:46:22 UTC
Currently audioaggregator always does conversion by default for the sinkpads and srcpad. Disabling this would require the convert_buffer vfunc to be NULL, which is what audiointerleave does.

In addition there is a GstAudioAggregatorConvertPad type. Using it does not decide whether conversion is possible, it only a) caches the converter (it is otherwise recreated for each buffer!) and b) provides a property to set the converter parameters.


To clear up this confusion I would propose the following:
1) Conversion is only decided by the existence of convert_buffer, and by default that's exactly what it does
2) GstAudioAggregatorPad already caches the converter, and equally a converter is cached for the srcpad. It makes no sense to recreate it all the time (but it should be flushed correctly when needed)
3) Let GstAudioAggregatorConvertPad only be there for the property. If you want the default conversion behaviour and the property, use that pad type. Otherwise not.


Thoughts?
Comment 1 Sebastian Dröge (slomo) 2018-02-28 14:58:10 UTC
basically the effect of my proposal would be to get rid of all the "if (GST_IS_AUDIO_AGGREGATOR_CONVERT_PAD (pad))" and always do that.
Comment 2 Sebastian Dröge (slomo) 2018-02-28 14:58:46 UTC
And documenting that the *only* use of the different pad class is the property, and everything else is controlled by the vfunc and conversion happens by default.
Comment 3 Sebastian Dröge (slomo) 2018-02-28 15:09:27 UTC
Ok, after some discussion with Mathieu on IRC, ignore the above. Instead:

1) Aggregator gets API to select the srcpad type
2) AudioAggregator only ever does conversion if AudioAggregatorConvertPad is used
2.1) convert_buffer vfunc moves to AudioAggregatorPad
2.2) AudioAggregatorConvertPad implements conversion
2.3) srcpad also becomes a AudioAggregatorConvertPad unless overridden by subclass

This is also closer to what VideoAggregator already does. And keeps concerns better separated than the confusion we have now.
Comment 4 Mathieu Duponchelle 2018-02-28 18:50:04 UTC
Created attachment 369111 [details] [review]
audioaggregator: refactor conversion API

For the rationale, see:

https://bugzilla.gnome.org/show_bug.cgi?id=793917

Also test audiomixer conversion of current output buffer
Comment 5 Mathieu Duponchelle 2018-02-28 23:40:41 UTC
Created attachment 369121 [details] [review]
audioaggregator: refactor conversion API

For the rationale, see:

https://bugzilla.gnome.org/show_bug.cgi?id=793917

Also test audiomixer conversion of current output buffer
Comment 6 Mathieu Duponchelle 2018-02-28 23:52:46 UTC
Attachment 369121 [details] pushed as 10835e9 - audioaggregator: refactor conversion API