GNOME Bugzilla – Bug 575929
faac cannot guess the correct rate if the stream if it is 8000
Last modified: 2009-03-19 11:43:39 UTC
Try this two pipelines: Sender: gst-launch-0.10 -v audiotestsrc ! mulawenc ! rtppcmupay ! udpsink Receiver: gst-launch-0.10 -v udpsrc ! application/x-rtp, media=audio, clock-rate=8000, payload=0 ! rtppcmudepay ! mulawdec ! audioresample ! audioconvert ! faac ! faad ! alsasink Then this is what happens: (...) /GstPipeline:pipeline0/GstFaac:faac0.GstPad:sink: caps = audio/x-raw-int, width=(int)16, depth=(int)16, endianness=(int)1234, signed=(boolean)true, rate=(int)8000, channels=(int)1 ERROR: from element /GstPipeline:pipeline0/GstFaac:faac0: Internal GStreamer error: negotiation problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. Additional debug info: gstfaac.c(640): gst_faac_chain (): /GstPipeline:pipeline0/GstFaac:faac0: failed to negotiate MPEG/AAC format with next element Workaround: gst-launch-0.10 -v udpsrc ! application/x-rtp, media=audio, clock-rate=8000, payload=0 ! rtppcmudepay ! mulawdec ! audioresample ! audio/x-raw-int, rate=44100 ! audioconvert ! faac ! faad ! alsasink Using caps seems to solve the problem, although faac according to its gst-inspect should be able to coupe with rates of 8000.
it's probably the bitrate of faac that is set wrongly for 8000Hz audio. It works fine with latest versions of faac. Try again with faac bitrate=48000. Since gst-plugins-bad 0.10.9, faac will automatically clamp the bitrate to the allowed bitrate for the samlerate (and emit a warning), earlier versions just produced an error. Closing, please reopen if the bitrate property did not fix it.