[gst-devel] AMR caps incompatibility between muxer and encoder
mrchapp at gmail.com
Thu Oct 26 00:56:02 CEST 2006
On 10/25/06, Benoit Fouet <benoit.fouet at purplelabs.com> wrote:
> SP GLE wrote:
> > Hi,
> > I'm trying to link an 'amrnbenc' element and a 'ffmux_mov',
> > amrnbenc SRC caps are
> > Capabilities:
> > audio/AMR
> > rate: 8000
> > channels: 1
> > ffmux_mov SINK Caps are
> > audio/x-amr-nb
> > rate: [ 8000, 96000 ]
> > channels: [ 1, 2 ]
> > so linking seems incompatible, how can i link these elements ? Is there
> > a way to change capabilities ?
> > failed negotiation between pads is attached for the following cmd :
> > GST_DEBUG=4 GST_DEBUG_NO_COLOR=1 gst-launch audiotestsrc !
> > audioconvert ! amrnbenc ! ffmux_mov ! filesink location=/tmp/f.mov
> > Thanks.
> you have to change the source code of amr decoder, so that it is
> audio/x-amr-nb too on its sink pad.
Why was that, again?
As I understand it, audio/x-amr-nb-sh is "MIME-ful" AMR narrow band,
that is, with a header like this: `echo '#!AMR' > header.amr`.
Then, audio/AMR is "MIME-less" AMR information. Certainly, the output
of the amrnbenc is lacking such header because it is pure AMR data, no
That's why amrnbparse takes audio/x-amr-nb-sh and outputs audio/AMR.
See section 8.1 of RFC 3267, where it says that MIME type for AMR is
precisely audio/AMR, with audio/AMR-WB being used for wide band.
Also, I vaguely recall that one of the de/muxers needed such header
for AMR, or needed it not when coming from RTP. Or something
in-between :) But in any case, it is possible to have a complete
pipeline with those elements without changing the source code.
Hope that makes some sense.
ddiaz at ti.com
> then compile and install back the library, and this should be ok :)
> Hope that helps,
> -- Ben
More information about the gstreamer-devel