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 499693 - [audioconvert] handle all conversions between raw audio formats
[audioconvert] handle all conversions between raw audio formats
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-11-26 08:17 UTC by Sebastian Dröge (slomo)
Modified: 2013-07-17 11:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2007-11-26 08:17:47 UTC
Hi,
currently audioconvert can only convert to different sample formats and different channel numbers/layouts. In most generic places where it is used (playbin for example) there is always an audioresample in the pipeline too to always get something that can be played by the sink.

IMHO we should do the following in the future:
- Move channel conversion and sample format conversion (i.e. float/integer, different depths/widths, endianess, etc) into separate elements
- Convert audioconvert to a bin that internally plugs everything (i.e. channel mixing, sample format conversion and resampling) that is require to come from the input format to the output format. This could of course be more intelligent than the current "audioconvert ! audioresample ! audioconvert" approach.

What do you think? This could also fix bug #385061 as one could make it easily use different resampling elements and let it chose the one that makes most sense or is the fastest or let it be chosen by an environment variable or ... :)
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2007-11-28 08:18:52 UTC
Great Idea!
Audioconvert already does a sequential format ! channel-mapping, so this would not cause severe performance loss. Subelements could be part of audioconvert plugin and named: audioformat, audiochannelmap.
Comment 2 Sebastian Dröge (slomo) 2007-12-09 05:16:54 UTC
According to Wim this is not a great idea because of the added complexity to negotiation, should probably be tested at some point if this is really not feasible.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2011-03-01 21:12:26 UTC
Maybe nowadays this would be a good candidate for dynamic orc code.
Comment 4 Tim-Philipp Müller 2012-10-02 23:02:35 UTC
I think we've basically rejected this on complexity grounds now? And we don't even use orc in audioresample. Not that it can't be done, but is anyone going to do it if nothing has happened for 5 years?
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2012-10-03 17:32:56 UTC
I would not rule it out at this point. Maybe this could be done in next years GSoC.
Comment 6 Tim-Philipp Müller 2012-10-03 23:15:23 UTC
I'm sure it could be done. The question is if anyone's willing to maintain it ;)
Comment 7 Sebastian Dröge (slomo) 2013-07-17 11:08:55 UTC
Yes, the complexity will be too high. Same reason why videoscale and videoconvert are separate. If anybody needs it, a bin can be created around them all.