GNOME Bugzilla – Bug 341562
audioconvert doesn't list formats in order of preference
Last modified: 2006-06-02 09:54:36 UTC
Audioconvert just returns its template caps from its transform_caps function. This means that it often won't make good choices about conversions in complex cases (I found this doing multichannel vorbis - in a forthcoming patch). I'll attach a preliminary patch changing this behaviour: feedback much desired!
Created attachment 65335 [details] [review] Preliminary patch
Created attachment 65338 [details] [review] Patch for multichannel vorbisenc This patch to vorbisenc will allow you to test multichannel vorbis encoding; it doesn't work right without the preceeding audioconvert bugfix. Putting it here so that people can have a useful testcase, I tested it with: gst-launch-0.10 filesrc location=51Test.wav ! wavparse ! audioconvert ! vorbisenc ! oggmux ! filesink location=/tmp/out2.ogg -v
Created attachment 65436 [details] [review] updated patch Updated audioconvert patch. Cleans up code, removes memory leaks, adds comments, and improves format selection.
Created attachment 65437 [details] [review] updated patch Updated patch; this time the right file.
dude, you should put this in now so we can get some testing
the vorbisenc patch looks weird; why not just define the sinkcaps as the padtemplate instead of dynamically create it in a getcaps function? Also it clears the sinkcaps when going to READY in a non-threasafe way. getcaps can be called at any time.
We can't define these caps as a pad template: they include audio positions. Pad templates get written to the registry, so then when something reads the registry, it fails - channel positions are defined in gst-plugins-base, not in core, so the type isn't registered when we read the registry. I did it as a pad template the first time, and ran into this problem Committing audioconvert now; will try to fix up vorbisenc patch for teh threadsafety thing when I have a moment.
ah yes. Not clearing the ->sinkcaps would be enough.