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

[Deeptendu Bikash]

Hi Ben,

Can you tell me how you did it? I am trying to mux AMR audio into a mov
file, but all I get in output is a 182 byte file. I used the pipeline
filesrc ! audio/AMR,rate=8000,channels=2 ! ffmux_mov ! filesink.
(I checked that the file does indeed have a #!AMR header).

I even tried doing it in mp4 using a AAC file as input and ffmux_mp4. When I
tried to run the output file, the players show the duration as more than
8000 hours and are not able to play it at all! I am totally at a loss.

Would really appreciate some help here.

Deeptendu


On 10/25/06, Benoit Fouet <benoit.fouet at purplelabs.com> wrote:
that does :)
indeed, I modified a bit the amrnb- dec/enc stuff a bit here, so that it
handles the amr header.
(to avoid the use of the amr parser)
sorry for all the noise, it seems i told a lot of stupid things yesterday...

indeed, thanks for explanation Daniel !

Daniel Díaz wrote:
> > 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.
> >
> that does :)
> indeed, I modified a bit the amrnb- dec/enc stuff a bit here, so that it
> handles the amr header.
> (to avoid the use of the amr parser)
> sorry for all the noise, it seems i told a lot of stupid things
> yesterday...
>
> indeed, thanks for explanation Daniel !
>
> -- Ben
>
> > Daniel Díaz
> > ddiaz at ti.com
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20061106/5437e10f/attachment.htm>