[gst-devel] Audio RTP Depayloaders failing

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

I'm having some problems getting any audio rtp depayloaders to function
(namely rtpamrdepay and rtppcmudepay). I can get the H263 video rtp
depayloader to work fine (by specifying the necessary details in the
'caps' property of the udpsrc), however the same technique does not work
when applied to the audio depayloaders and I'm hoping someone can point
out where I'm going wrong. Below I've explained the tests I've been
running. Any help would be hugely appreciated.

What I've been trying to do is receive a stream of audio packets (AMR
(narrow band) rtp packets) and decode them for further use, but I seem
to be getting stuck at the depayloading stage (or at least that is what
the error message I receive suggests).

The first test scenario I was using is using the audio source to
generate a packet flow to a specified port, then from a separate
instance, attempt to receive and process the packets. I generate the
test data using:

gst-launch-0.10 -v audiotestsrc ! amrnbenc ! rtpamrpay ! udpsink
port=3D5002

This produces the test information:

/pipeline0/audiotestsrc0.src: caps =3D audio/x-raw-int,
endianness=3D(int)1234, signed=3D(boolean)true, width=3D(int)16,
depth=3D(int)16, rate=3D(int)8000, channels=3D(int)1
Pipeline is PREROLLING ...
/pipeline0/amrnbenc0.src: caps =3D audio/AMR, channels=3D(int)1,
rate=3D(int)8000
/pipeline0/amrnbenc0.sink: caps =3D audio/x-raw-int, =
endianness=3D(int)1234,
signed=3D(boolean)true, width=3D(int)16, depth=3D(int)16, =
rate=3D(int)8000,
channels=3D(int)1
/pipeline0/rtpamrpay0.src: caps =3D application/x-rtp,
media=3D(string)audio, payload=3D(int)96, clock-rate=3D(int)8000,
encoding-name=3D(string)AMR, ssrc=3D(guint)1203961403,
clock-base=3D(guint)1809714996, seqnum-base=3D(guint)19650,
encoding-params=3D(string)1, octet-align=3D(string)1
/pipeline0/rtpamrpay0.sink: caps =3D audio/AMR, channels=3D(int)1,
rate=3D(int)8000
/pipeline0/udpsink0.sink: caps =3D application/x-rtp, =
media=3D(string)audio,
payload=3D(int)96, clock-rate=3D(int)8000, encoding-name=3D(string)AMR,
ssrc=3D(guint)1203961403, clock-base=3D(guint)1809714996,
seqnum-base=3D(guint)19650, encoding-params=3D(string)1,
octet-align=3D(string)1
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock

Using the information provided here I thus configure the receiving
pipeline:

gst-launch-0.10 -v udpsrc port=3D5002 caps=3D"application/x-rtp,
media=3D(string)audio, payload=3D(int)96, clock-rate=3D(int)8000,
encoding-name=3D(string)AMR, ssrc=3D(guint)1203961403,
encoding-params=3D(string)1, octet-align=3D(string)1" ! rtpamrdepay !
fakesink

Which results in:

Setting pipeline to PAUSED ...
/pipeline0/udpsrc0.src: caps =3D application/x-rtp, =
media=3D(string)audio,
payload=3D(int)96, clock-rate=3D(int)8000, encoding-name=3D(string)AMR,
ssrc=3D(guint)1203961403, encoding-params=3D(string)1,
octet-align=3D(string)1, crc=3D(string)0, robust-sorting=3D(string)0,
interleaving=3D(string)0
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/pipeline0/udpsrc0.src: caps =3D application/x-rtp, =
media=3D(string)audio,
payload=3D(int)96, clock-rate=3D(int)8000, encoding-name=3D(string)AMR,
ssrc=3D(guint)1203961403, encoding-params=3D(string)1, =
octet-align=3D(string)1
/pipeline0/rtpamrdepay0.src: caps =3D audio/AMR, channels=3D(int)1,
rate=3D(int)8000
/pipeline0/rtpamrdepay0.sink: caps =3D application/x-rtp,
media=3D(string)audio, payload=3D(int)96, clock-rate=3D(int)8000,
encoding-name=3D(string)AMR, ssrc=3D(guint)1203961403,
encoding-params=3D(string)1, octet-align=3D(string)1
ERROR: from element /pipeline0/rtpamrdepay0: The stream is in the wrong
format.
Additional debug info:
gstbasertpdepayload.c(265): gst_base_rtp_depayload_chain ():
/pipeline0/rtpamrdepay0:
no clock rate was specified, likely incomplete input caps
Execution ended after 5222000 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
/pipeline0/rtpamrdepay0.src: caps =3D NULL
/pipeline0/rtpamrdepay0.sink: caps =3D NULL
/pipeline0/udpsrc0.src: caps =3D NULL
Setting pipeline to NULL ...
FREEING pipeline ...

Another scenario I would expect to work (by work I mean produce output
demonstrating processing), but it fails with the same message:

gst-launch-0.10 -v audiotestsrc ! amrnbenc ! rtpamrpay ! rtpamrdepay !
fakesink

The above scenario works for h263 video (i.e. piping the rtppayloader
straight into the rtpdepayloader).

In order to rule out the audiosource causing problems I have also
attempted to receive packets from a completely external AMR rtp source,
but again it complains that the stream is in the wrong format. I thought
I might have missed some complication introduced by the use of AMR
specifically, so tried all the tests again but this time using PCMU
(ulaw) as the audio format, but I still receive exactly the same
results. This leads me to suspect that either there is something that
specifically needs to be done to utilise the audio depayloaders, or else
there is some bug common to them.

Any assistance would be greatly appreciated.

Thanks

George
This e-mail message (including any attachment) is confidential. If you =
have received this email in error please notify the sender immediately =
and delete this email from your system without copying or disseminating =
it or placing any reliance upon its contents. Any opinions expressed in =
this email (including attachments) are those of the author only.  This =
message (including any attachments) does not create any legally binding =
rights or obligations. D2see Limited is a company registered in England =
and Wales no. 5836806. Registered Office: 10 Barley Mow Passage, London =
W4 4PH, UK. VAT registered, no. 888 1076 85.  Tel +44 20 8819 5710