RTP Receiver sample

Subscribe to RSS news feed


Sample is based on TunaIPReceiver component, which does the following:

  • receives RAW/RTP audio packets from network
  • if stream is compressed, decodes it with specified decoder
  • passes decoded audio stream to consumer.

There are several different streaming modes, all are specified by the URI property.

RAW/RTP UDP Unicast streaming

In this mode target (destination) address and port is specified in URI, so receiver will be able to bind to the target address:port and receive data.

URI samples:


Receivers must also bind to port 1234. RTCP will use port 1235.

RAW/RTP UDP One-to-many streaming

In this mode receiver send a special packet to transmitter, so it will be aware of new destination.

URI samples:


Transmitter is running at RTCP will use port 1235.

NOTE for RAW streaming: this mode is NOT recommended, as there is no way to timeout dead receivers.

RAW/RTP UDP Multicast streaming

In this mode URI specifies multicast group address and port number to be used for streaming.

URI samples:


Receiver joins multicast group and wait for data at port 1234. RTCP will use port 1235.

RTSP Negotiation

To request audio stream from a RTSP server, URI must specify rtsp protocol, host name and stream id. Receiver will negotiate streaming parameters with RTSP server and will open a RTP channel for audio streaming.

URI samples:


Receiver will connect to RTSP server running at at default port 554 and request playback of stream name "song5.mp3". After successfull negotiation, new RTP channel will be created.

Icecast/SHOUTCast TCP streaming

In addition to UDP sockets, it is also possible to stream over TCP using SHOUTCast protocol. You should be running Icecast/DNAS server somewhere.

URI samples:

Receiver will connect to host at port 9000 and request "stream_name" to be streamed.

Payload format

Use SDP property to specify how audio should be encoded before transmitting. Or set doEncode property to False to disable any encoding.

Some SDP examples shows how to use it. In addition you can specify TTL for multicast streaming and bitrate for some codecs, as showm below:

m=audio 5004 RTP/AVP 14
a=rtpmap:14 mpa/44100/2
c=IN IP4 /2
a=fmtp:14; bitrate=256

Here 14 is pre-defined payload number for MPEG audio, "c=IN IP4 /2" specifies IP4 addressing and TTL=2, and bitrate is set to 256 kbps.

List of supported payloads, defined in RFC 3551:

  • 0 -- uLaw, 8000
  • 3 -- GSM, 8000
  • 5 -- DVI4, 8000
  • 6 -- DVI4, 16000
  • 8 -- ALaw, 8000
  • 10 -- L16, stereo, 44100
  • 11 -- L16, mono, 44100
  • 14 -- MPEG I/II Audio
  • 16 -- DVI4, 11025
  • 17 -- DVI4, 22050
  • 33 -- MP2T, MPEG-TS

In addition, IPReceiver is aware of the following dynamic payload numbers:

  • 110 -- Speex (NB, 8000)
  • 111 -- Speex (WB, 16000)
  • 112 -- Speex (UWB, 32000)
  • 113 -- t140 text
  • 114 -- OGG/Vorbis (not yet implemented)
  • 115 -- VDVI
  • 116 -- CELT 16000 mono
  • 117 -- CELT 24000 mono
  • 118 -- CELT 48000 stereo
  • 119 -- GSM49 - MS GSM
  • 120 -- G.722.1

MPEG-TS demuxer

Set mpegTS_aware property to True when receiving MPEG-TS either as RAW packets or encapsulated in RTP. IPReceiver will demux the transport stream into elementary streams.

The mpegTS_PID property must be set to PID of stream receiver should decode. Since PID is unknown, the sample will browse all streams and build a list of available programs/streams for end-user to choose from.


Precompiled binary of this sample is included in the Demos package.