GNOME Bugzilla – Bug 641151
lame: doesn't negotiate sample rate properly
Last modified: 2011-02-03 18:28:50 UTC
Created attachment 179798 [details] Dot png file Attached is a dotfile graph and gst-debug-log of a transmageddon transcoding. Wim looked at the issue a bit today and what we discovered is that the audio bitrate is not negotiated properly. flvmux no not accept bitrates higher than 44100, but the pipeline never changes the bitrate from the incoming 48000. Wim think the bug probably is in the lame encoder plugin. In addition to the bug it is also strange that we do not get an error printed on the console due to this.
Debug log at: http://www.linuxrising.org/old/output.txt.bz2
Reproduce with: gst-launch-0.10 audiotestsrc ! audio/x-raw-int,rate=48000 ! audioresample ! lamemp3enc ! flvmux ! fakesink Looks like lamemp3enc doesn't negotiate/proxy the get_caps properly. I think it should proxy the sample rate + channels fields. No idea if there's a reason why flvmux doesn't accept 48kHz audio or if it's just an oversight.
commit 7551d102f8b87446729a55c3909ebbc15296c26e Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Thu Feb 3 18:25:00 2011 +0000 tests: add unit test for lamemp3enc negotiation issue https://bugzilla.gnome.org/show_bug.cgi?id=641151 commit 7417ad6d5feb74696b030a179f390656ecaf7ac7 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Thu Feb 3 18:18:35 2011 +0000 lamemp3enc: implement sinkpad get_caps() function to proxy rate and channels restrictions from downstream The element downstream of mp3enc might only accept certain sample rates or channels, make sure we relay any restrictions that do exist to upstream when it does a get_caps() on the sink pad. That way upstream elements like audioresample or audioconvert can pick a sample rate / channel configuration that will be accepted, instead of just negotiating to the highest, which might then be rejected. https://bugzilla.gnome.org/show_bug.cgi?id=641151