[gst-devel] AMR caps incompatibility between muxer and encoder

[Daniel Díaz]

Hello there!


On 10/25/06, Benoit Fouet <benoit.fouet at purplelabs.com> wrote:
> Hi
>
> 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
MIME header.

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.

Daniel Díaz
ddiaz at ti.com


> then compile and install back the library, and this should be ok :)
>
> Hope that helps,
>
> -- Ben