RTSP Source URL Syntax

Show in webframe

The format of the string for RTSP streaming is as follows (optional components are enclosed in square brackets):

rtsp://[username[:password]@]ip_address[:rtsp_port]/server_URL[?param1=val1[&param2=val2]...[&paramN=valN]]

Descriptions of the parameters of the string for RTSP streaming are as follows:

ip_address	The server's IP address (mandatory). Typically, the RTSP servers use DHCP to obtain an IP address automatically. The servers usually provide a utility for detecting the server's IP address. This can be in the usual Ipv4 format (xx.xx.xx.xx), or it can be a valid host address accepted by the standard function inet_addr. For example, localhost is equivalent to 127.0.0.1. This is usually the IP address of the sending (server) computer. The IP address for the server should be unicast. While you might request a multicast connection to a RTSP server, the server's address is unicast. In multicast, connections, the server will open separate multicast connections for broadcasting the data. But when you connect to the server, you will connect to a unicast address.
rtsp_port	(Optional) The port number on which the server is listening for RTSP commands. The port must be a number from 1 to 65535. If absent, the default RTSP port (554) will be used.
username	(Optional) For servers that use authentication, you can pass a username as part of the connection string. Passing the username and password will avoid the message box asking for the username and password. If you pass the username and password but still get the message box, the server has rejected the supplied username and/or password.
password	(Optional) For servers that use authentication, you can pass a username and password as part of the connection string. Passing the username and password will avoid the message box asking for the username and password. If you pass the username and password but still get the message box, the server has rejected the supplied username and password.
server_URL	The server's relative URL (mandatory). Each RTSP server has its own relative URL, so you need to consult the server's manual to obtain it. See the Note at the end of this topic to view a list of server URLs for servers that we tested.
paramN=valN	(Optional) Extra parameters used to modify the filter or server's behavior. They can be filter parameters (eg: Transport=xxx) or server parameters (eg: compression=jpeg). They can be used to control the connection mode, compression, video size, etc. See the following examples for such parameters. The parameters used by the filter are in the following table. Any parameters not listed below are considered server-dependent and are passed along to the server:
	Parameter	Possible values
	Latency	An integer value representing the amount of data (in milliseconds) being buffered when playback starts. The default value is 100 (for 100ms, or 0.1 seconds). Specifying a value > 0 helps smooth out the jittering caused by the decoder pausing playback to wait for data to arrive from the server. A greater value will achieve smoother playback but will introduce a latency compared to live playback.
	Port	1024-65534 - Specifies the starting port used by the client when streaming UDP data. The default value is 1024. This is the starting value - the client will need two ports for each channel (one for data and another for RTCP packets). The client will automatically find the first available port. If the automatic detection fails, or you want port 1024 to be free for some reason, you can use this parameter to instruct the RTSP Source to look for the available UDP ports starting from a different value. For example, if you set Port to 2048, the RTSP Client will use ports 2048-2049 for 1st stream (eg: video) and 2050-2051 for 2nd stream (eg: audio)
	Transport	unicast - The data should be set through a unicast stream using UDP packets. This is the default, so you don't really need to use this value. multicast - The data should be set through a multicast stream using UDP packets. The server is responsible for picking the multicast address. Note: Both parameter and value are case sensitive, so you should use "Transport=multicast", not "transport=multicast". HTTP - The data is sent using RTSP through HTTP tunneling in TCP packets. The data for all the streams is sent though the same port, so the performance is not as good as using UDP packets. But in some situations the firewalls between the camera and the client might prevent the UDP packets for getting through, so HTTP tunneling is the only way to stream the data. Note: Not all the RTSP servers support HTTP tunneling. The LTMM_E_HTTP_GET_FAILED (0x8005003E) error code will be returned when you try to render the source stream if the server does not support HTTP tunneling.
	Timeout	The parameter is an integer value specifying the amount of time (in seconds) the RTSP source should wait for a response and data before giving up. The value should be greater than or equal to 0. The default value is 0, in which case the server picks the default timeouts for a command response and command data. Passing 0 is the same as not passing the Timeout at all. This parameter is useful for connecting for servers that are slow or for streaming points that take a long time to set up. For example, if you ask the LEAD RTSP Sink to stream a DVD, accessing the DVD and starting the conversion can take significantly more than the default timeouts. So in this case, you might have to increase the timeout to something like 10 seconds by adding a "?Timeout=10" suffix to URL passed to the RTSP Source.
	Trace	The parameter is an integer value indicating whether tracing should be enabled. Set this to 1 to create a trace file showing the commands sent to the RTSP server and the responses received. The name of the trace file is "c:\leadtrace.txt" You may have to disable UAC in order to allow leadtrace.txt to be created in "c:\". This parameter is useful for debugging purposes. The default value is 0 (no trace file is created.)

There are advantages and disadvantages for using the different transport modes, as follows:

Unicast (selected with Transport=unicast or by leaving it out):

Pros: Most efficient and most common. The data is streamed using UDP packets sent in Unicast mode from the server to your computer. Each stream uses a different port and the client picks which port it should receive the data on.
Cons: If the server is on a different network, firewalls between the server and the client might prevent the packets from getting through. Also, multiple clients connected to the server at the same time will generate multiple packets for the same video frame being duplicated for each client.

Syntax:

rtsp://ip_address[:rtsp_port]/server_URL

rtsp://username:password@ip_address[:rtsp_port]/server_URL

Multicast (selected with Transport=multicast)

Pros: Efficient for situations in which multiple clients are connected to the server at the same time. The data is streamed using UDP packets sent in Multicast mode from the server to your computer. Each stream uses a different port and the server picks which port it should send the data to.
Cons: If the client and the server are not connected to the same router, the multicast packets might get lost. Multicast packets are sent to each computer on the network, so network administrators will sometimes disable multicast traffic.

Syntax:

rtsp://ip_address[:rtsp_port]/server_URL?Transport=multicast

rtsp://username:password@ip_address[:rtsp_port]/server_URL?Transport=multicast

RTSP Tunneling over HTTP (selected with Transport=HTTP):

Pros: The data is streamed using TCP packets sent in Unicast mode from the server to your computer. TCP packets are more likely to go through firewalls, so this gives a better chance of streaming from a RTSP server located on another network.
Cons: All the streams are sent through the same port and are using TCP packets. TCP packets are guaranteed to get through, but this also adds extra overhead compared to UDP so the throughput is reduced. Also, not all RTSP servers support this mode.

Syntax:

rtsp://ip_address[:rtsp_port]/server_URL?Transport=HTTP

rtsp://username:password@ip_address[:rtsp_port]/server_URL?Transport=HTTP

Examples of valid strings:

rtsp://192.168.6.100/mpeg4/media.amp?Transport=multicast - Connect to a RTSP running on 192.168.6.100 at the "mpeg4/media.amp" url and stream the data in multicast mode. The data will be streamed using the MPEG4 compression.

rtsp://192.168.6.100/mpeg4/media.amp?Transport=HTTP - Connect to a RTSP running on 192.168.6.100 at the "mpeg4/media.amp" url and stream the data using RTSP over HTTP tunneling mode. The data will be streamed using the MPEG4 compression and sent using TCP packets.

Examples of various forms of valid strings for a particular camera (an Axis v5 camera):

rtsp://192.168.0.164/axis-media/media.amp - Connect to a RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data will be streamed using the default compression (H264) and Unicast over UDP.

rtsp://192.168.0.164/axis-media/media.amp?Transport=multicast - Connect to a RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data will be streamed using the default compression (H264) and Multicast over UDP.

rtsp://192.168.0.164/axis-media/media.amp?Transport=HTTP - Connect to a RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data will be streamed using the default compression (H264) and HTTP tunneling over TCP.

rtsp://192.168.0.164/axis-media/media.amp?videocodec=jpeg - Connect to a RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data will be streamed using the jpeg compression and Unicast over UDP.

rtsp://192.168.0.164/axis-media/media.amp?Transport=HTTP?videocodec=jpeg - Connect to a RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data will be streamed using the jpeg compression and HTTP tunneling over TCP.

rtsp://root:pass@192.168.0.164/axis-media/media.amp?videocodec=jpeg - Connect to a RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data will be streamed using the JPEG compression and Unicast over UDP. This server is using authentication, and we are connecting as username 'root' and with the password 'pass' in order to avoid having to enter a username and password.

rtsp://root:pass@192.168.0.164/axis-media/media.amp?Transport=HTTP&videocodec=jpeg - Connect to a RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data will be streamed using the jpeg compression and HTTP tunneling over TCP. This server is using authentication, and we are connecting as username 'root' and with the password 'pass' in order to avoid having to enter a username and password.

rtsp://192.168.0.164/axis-media/media.amp?Trace=1 - Connect to a RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. Debugging information containing the RTSP commands and their responses will be written to a trace file located in c:\leadtrace.txt.

One of the above URLs shows how to combine a server parameter (videocodec=jpeg) with a LEAD RTSP Source built-in parameter (Transport=HTTP). In general, options are added to the regular URL by using the '?' character. Multiple options are separated using the '&' character. The order of the options does not matter, so the following two commands will give the same result:

rtsp://192.168.0.164/axis-media/media.amp?Transport=HTTP&videocodec=jpeg

rtsp://192.168.0.164/axis-media/media.amp?videocodec=jpeg&Transport=HTTP

All of the above examples assume the server is listening to the default RTSP port (554). So they omit the port when they specify the URL. If the server is set to respond to a different port number, you will need to add the optional ":rtsp_port" after the server address. The following example assumes the server is listening on port 8003:

rtsp://192.168.0.164:8003/axis-media/media.amp

Each RTSP server can have its own URL. Consult each server's documentation to find out its URL. The following table lists some URLs for some RTSP servers that we tested.

Note: RTSP URLs for servers that we tested

RTSP server	Command	Notes
LEAD RTSP Sink	rtsp://192.168.0.164/filename.ext	Where filename.ext is the relative path of any file in the source folder (in which you replace backslashes with forward slashes). For example, if the source folder in the server is "c:\ServerFiles", then the file in "c:\ServerFiles\Folder1\Filename2.avi" would be streamed with rtsp://192.168.0.164/Folder1/Filename2.avi
Axis v5 platform	rtsp://192.168.0.164/axis-media/media.amp rtsp://192.168.0.164/axis-media/media.amp?videocodec=jpeg	This server can stream H.264/jpeg video and AAC audio. The first command streams H.264, while the second streams jpeg video. It seems to support Unicast, Multicast and HTTP modes.
Axis v4 platform (eg: 214 PTZ camera)	rtsp://192.168.6.100/mpeg4/media.amp	Streams mpeg4 video and G.711 audio. G.726 audio is not supported It seems to support Unicast, Multicast and HTTP modes.
Vivotek VS8102	rtsp://192.168.0.172/live.sdp rtsp://192.168.0.172/live2.sdp rtsp://192.168.0.172/live3.sdp rtsp://192.168.0.172/live4.sdp	This server can set up to 4 types of streams. Select the video and audio compression for each stream. We support H.264, MPEG4 and jpeg video and AAC/AMR audio. It seems to support Unicast and Multicast modes. The HTTP mode did not seem to be supported.
Darwin Streaming Server	rtsp://192.168.6.101/<filename.mp4>	<filename.mp4> can be any file or playlist present on the server. The video and audio compression is the same as the audio and video compression of the file. We have tested successfully playback of MPEG4 video and AAC/AMR audio files.
CISCO RTSP	rtsp://192.168.0.172/StreamingSetting?version=1.0&action=getRTSPStream &sessionID=<session_id>&ChannelID=1&ChannelName=Channel1	<session_id> is the session id obtained from the url you get when clicking on View Video in the browser. The server uses H264 video and AAC audio.