RTSP Source URL Syntax

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[&paramN=valN]] 

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

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.

ip_address

The server's IP address (required). 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 an 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.

server_URL

The server's relative URL (required). Each RTSP server has its own relative URL, so you need to consult the server's manual to obtain it. See URLs for Various RTSP Servers 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
EnableSecurityUI Indicates whether to show or hide the username/password UI for RTSP servers requiring a username and password.
0 - Hides the username/password UI.
1 - Shows the username/password UI. This is the default value.
If set to 0, the RTSP source will fail to stream from RTSP servers using security, unless the correct username/password are entered in the URL. If the RTSP server requires a username/password and the URL does not contain the correct username/password, the filter will fail load or play the stream with the LTMM_E_RTSP_UNAUTHORIZED (0x80050037) error code.
To set this value programmatically, call the ILMRTSPSrc::EnableSecurityUI property.
G726Reversed 0 - Do not reverse the G.726 audio bit order. This is the default value.
1 - Reverse the G.726 audio bit order.
Use this parameter with 1 for sources that incorrectly reverse the G.726 audio bit order. For these sources, the audio sounds choppy and distorted, using a value of 1 could correct this problem.
Note: For good RTSP streams, ignore using this parameter.
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 sent through a unicast stream using UDP packets. This is the default value.
multicast - The data should be sent through a multicast stream using UDP packets. The server is responsible for picking the multicast address.
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 from getting through, so HTTP tunneling is the only way to stream the data.
Note: Both parameter and value are case sensitive, so you should use "Transport=multicast", not "transport=multicast".
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.
MaxTimeout The parameter is an integer value specifying the total 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 MaxTimeout at all.
This parameter is different than the Timeout parameter described below because it specifies the maximum timeout for all connections types (UDP, TCP, HTTP, etc). The Timeout parameter controls the timeout used for UDP connection.
See the Note below for a comparison between the Timeout and MaxTimeout parameters.
Timeout The parameter is an integer value specifying the amount of time in seconds the RTSP source should wait for a response and data using one connection method 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 to servers that are slow or to 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 time than the default timeouts. So in this case, you might have to increase the timeout to something like 10 seconds by adding ?Timeout=10 to URL passed to the RTSP Source.
See the Note below for a comparison between the Timeout and MaxTimeout parameters.
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.)

 

Transport Modes

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

Url Syntax for Unicast Transport

Selected with Transport=unicast or by excluding the Transport parameter.

Url Syntax for Multicast Transport

Selected with Transport=multicast parameter.

Url Syntax for RTSP Tunneling over HTTP Transport

Selected with Transport=HTTP parameter.

Examples of Valid Urls

Example Urls for Axis v5 Cameras

As shown above, it is possible to combine parameters in the URL query string, such as combining: videocodec=jpeg with a LEAD RTSP Source built-in parameter Transport=HTTP. Use the URL's query string starting with the ? character and add multiple options separated with the & character. The order of the parameters in the query string does not matter and provide the same result. For example, these two query strings have an identical outcome:

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 portion of the URL. If the server is bound to a different port, the :rtsp_port portion of the url after the server address must be specified. The following example assumes the server is listening on port 8003:

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

Each RTSP server implementation may have its own unique parameters. Consult each implementation's documentation to review its possible parameter and values. The following table lists some URLs for some RTSP servers that we tested.

URLs for Various RTSP Servers

RTSP Server URL 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

LEADTOOLS Media Server rtsp://192.168.1.49:7979/vod/sample.mp4 In this case, port 7979 is used to stream vod/sample.mp4. If you are using a different port or filename, adjust the URL as necessary.
American Dynamics Discover 700 rtsp://192.168.0.190/img/video.sav

rtsp://192.168.0.190/img/video.sav?resolution=2&quality_type=1&quality=3&framerate=15

Seems to stream H.264 video (no audio). Select different resolutions/frame rates by adding "resolution=X" type parameters to the URL.
Arecont Vision AV2115DNv1 rtsp://ip_address/h264.sdp

Can stream JPEG over HTTP, but RTSP streams only H.264 video.

This camera has ONVIF support, so you can also stream from it using the LEAD ONVIF Source filter.

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 and JPEG video, and AAC audio. The first URL 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.

Axis Q1614
Axis P1354

rtsp://192.168.1.93/onvif-media/media.amp

H264

rtsp://192.168.1.93/onvif-media/media.amp?profile=profile_1_h264&sessiontimeout=60&streamtype=unicast

MJPEG

rtsp://192.168.1.93/onvif-media/media.amp?profile=profile_1_jpeg&sessiontimeout=60&streamtype=unicast

These cameras have ONVIF support, so you can also stream from them using the LEAD ONVIF Source filter.
D-Link DCS-5029L

H.264

rtsp://[admin:[password]@]ip address/live1.sdp

MJPEG

rtsp://[admin:[password]@]ip address/live2.sdp

This camera has ONVIF support, so you can also stream from it using the LEAD ONVIF Source filter.

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.

LEADTOOLS supports 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 video and audio compression of the file. We have successfully tested 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 H.264 video and AAC audio.

TENVIS TZ100

H.264 (1280x720)

rtsp://[admin:[password]@]ip address/11

H.264 (640x352)

rtsp://[admin:[password]@]ip address/12

TRENDNet TV-IP310PI

Main Video

rtsp://ip address

H.264

rtsp://ip address/streaming/channels/1

MJPEG

rtsp://ip address/streaming/channels/2

Difference Between Timeout and MaxTimeout Parameters

The default transport mode used for audio and video data is to use UDP packets. UDP packets have less overhead than TCP packets and will generally offer better performance. But the UDP packets will often fail to reach the client if the server and client are on different networks. For this reason, when you try to play a stream, the RTSP source will first try to receive data using UDP packets. If no data arrives in a certain amount of time (4 seconds or the amount of time specified in the Timeout parameter), the RTSP Source filter will try to receive data using TCP packets. When it tries to receive data using TCP packets, the RTSP Source filter will wait for a certain amount of time (20 seconds or the amount of time specified in the Timeout parameter) to receive audio or video data.

If you do not specify a Timeout or MaxTimeout parameter and leave the Transport to be the default (or UDP), the RTSP Source filter will do the following:

  1. Will wait for 4 seconds for UDP data
  2. Will wait for 20 seconds for TCP data

If you specify the Timeout parameter and you leave the Transport to be the default (or UDP), the filter will do the following:

  1. Will wait for Timeout seconds for UDP data
  2. Will wait for Timeout seconds for TCP data

For example, if you set Timeout to 10, the filter will wait for up to 20 seconds for data to arrive.

If you specify the Transport to be TCP and you set no Timeout or MaxTimeout the filter will wait for 20 seconds for TCP data.

If you specify the Transport to be TCP, set the Timeout, the filter will wait for Timeout seconds for TCP data.

A simpler way is to use the MaxTimeout parameter. This overrides any value set by Timeout and specifies the total maximum amount of time RTSP Source filter will wait to receive data. For example, if you set MaxTimeout to 18, the filter will do the following:

  1. Will wait for 4 seconds for UDP data
  2. Will wait for up to 14 seconds for TCP data. (This will actually be less than 14 seconds because it will take some time to tell the RTSP server to switch from UDP to TCP streaming)

During all this time, you can use the ILMRTSPSrc interface to set a callback that will be called at regular intervals asking you whether you wish to continue waiting for data. The LEADTOOLS Multimedia player object automatically does this and sends the ltmmEC_LOADSTATUS event with a ltmmAM_LOADSTATUS_WAITING_FOR_DATA notification. See the ltmmLoadStatusEventCode Constants topic for more information. You can use this mechanism to ask the user whether they wish to abort the wait.

Help Version 20.0.2020.5.7
Products | Support | Contact Us | Intellectual Property Notices
© 1991-2020 LEAD Technologies, Inc. All Rights Reserved.

LEADTOOLS Filters C API Help