References ▼
The string for RTSP streaming uses the following syntax (optional components are enclosed in square brackets):
rtsp://\[username\[:password\]@\]ip\_address\[:rtsp\_port\]/server\_URL\[?param1=val1\[¶m2=val2\]...\[¶mN=valN\]\]
The parameters used in the string for RTSP streaming are described below.
(Mandatory) The server's IP address. Typically, RTSP servers use DHCP to obtain an IP address automatically. Servers usually provide a utility for detecting the server's IP address. The address 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 it is possible to request a multicast connection to an RTSP server, the server's address is unicast. In multicast connections, the server opens separate multicast connections for broadcasting the data. But when a client connects to the server, the connection is made as a unicast address.
(Optional) The port number on which the server is listening for RTSP commands. The port must be a number from 1 to 65535. If no number is present, the default RTSP port (554) is used.
(Optional) For servers that use authentication, it is possible to pass a username as part of the connection string. Passing the username and password avoids the message box asking for the username and password. If the username and password were passed but the message box appears anyway, the server has rejected the supplied username and password.
(Optional) For servers that use authentication, it is possible to pass a username and password as part of the connection string. Passing the username and password avoids the message box asking for the username and password. If the username and password were passed but the message box appears anyway, the server has rejected the supplied username and password.
(Mandatory) The server's relative URL. Each RTSP server has its own relative URL. Consult the server's manual to obtain it. See the List of Tested Servers at the end of this topic to view a list of server URLs for servers that have been tested by LEAD.
(Optional) Extra parameters used to modify the filter's or server's behavior. They can be filter parameters (e.g., Transport=xxx) or server parameters (e.g., 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 described 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. Greater values achieve smoother playback but 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 needs two ports for each channel (one for data and the other for RTCP packets). The client automatically finds the first available port. If automatic detection fails, or port 1024 needs to be free for some reason, use Port to instruct the RTSP Source to look for the available UDP ports starting from a different value. For example, setting the Port to 2048 causes the RTSP Client to use ports 2048-2049 for the 1st stream (e.g., video), and 2050-2051 for the 2nd stream (e.g., audio). |
| Transport | unicast -Sends the data through a unicast stream using UDP packets. This is the default value, so it is not really necessary to use this value. multicast - Sends the data 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 use "Transport=multicast", not "transport=multicast". HTTP - Sends the data using RTSP through HTTP tunneling in TCP packets. The data for all streams is sent though the same port, so the performance is not as good as when using UDP packets. But in some situations, the firewalls between the camera and the client can possibly prevent the UDP packets from getting through: in such cases 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 is returned when rendering the source stream is attempted, but the server does not support HTTP tunneling. |
| Timeout | 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 to servers that are slow, or for streaming points that take a long time to set up. For example, when asking 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, it can be good to increase the timeout to something like 10 seconds, by adding a "?Timeout=10" suffix to the URL passed to the RTSP Source. |
There are advantages and disadvantages for using the different transport modes, as follows:
Pros: Most efficient and most common. The data is streamed using UDP packets sent in unicast mode from the server to the destination 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 can possibly prevent the packets from getting through. Also, multiple clients connected to the server at the same time generate multiple packets for the same video frame being duplicated for each client.
Syntax:
rtsp://ip\_address\[:rtsp\_port\]/server\_URLrtsp://username:password@ip\_address\[:rtsp\_port\]/server\_URL
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 the destination 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 can get lost. Multicast packets are sent to each computer on the network, so network administrators sometimes disable multicast traffic. Syntax:
rtsp://ip\_address\[:rtsp\_port\]/server\_URL?Transport=multicastrtsp://username:password@ip\_address\[:rtsp\_port\]/server\_URL?Transport=multicast
Pros: The data is streamed using TCP packets sent in unicast mode from the server to the destination computer. TCP packets are more likely to go through firewalls, so this gives a better chance of streaming from an RTSP server located on another network.
Cons: All 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 throughput is reduced. Also, not all RTSP servers support this mode.
Syntax:
rtsp://ip\_address\[:rtsp\_port\]/server\_URL?Transport=HTTPrtsp://username:password@ip\_address\[:rtsp\_port\]/server\_URL?Transport=HTTP
Connect to an RTSP running on 192.168.6.100 at the "mpeg4/media.amp" URL and stream the data in multicast mode. The data is streamed using MPEG4 compression.
rtsp://192.168.6.100/mpeg4/media.amp?Transport=multicast Connect to an 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 is streamed using MPEG4 compression and sent using TCP packets.
rtsp://192.168.6.100/mpeg4/media.amp?Transport=HTTP
rtsp://192.168.0.164/axis-media/media.amp rtsp://192.168.0.164/axis-media/media.amp?Transport=multicast rtsp://192.168.0.164/axis-media/media.amp?Transport=HTTP Connect to an RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data is streamed using jpeg compression and Unicast over UDP.
rtsp://192.168.0.164/axis-media/media.amp?videocodec=jpeg Connect to an RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data is streamed using jpeg compression and HTTP tunneling over TCP.
rtsp://192.168.0.164/axis-media/media.amp?Transport=HTTP?videocodec=jpeg Connect to an RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data is streamed using JPEG compression and Unicast over UDP. This server is using authentication, and in order to avoid having to enter a username and password, the connection is made using the username 'root' and the password 'pass' .
rtsp://root:pass@192.168.0.164/axis-media/media.amp?videocodec=jpeg Connect to an RTSP server running on 192.168.0.164 at the "axis-media/media.amp" URL. The data is streamed using jpeg compression and HTTP tunneling over TCP. This server is using authentication, and by connecting as username 'root' and with the password 'pass', having to enter a username and password is bypassed.
rtsp://root:pass@192.168.0.164/axis-media/media.amp?Transport=HTTP&videocodec=jpeg 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 give the same result:
rtsp://192.168.0.164/axis-media/media.amp?Transport=HTTP&videocodec=jpegrtsp://192.168.0.164/axis-media/media.amp?videocodec=jpeg&Transport=HTTP
All 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, it is necessary 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 LEAD has tested.
rtsp://192.168.0.164/filename.ext Here, "filename.ext" represents the relative path of any file in the source folder (in which case, 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
rtsp://192.168.0.164/axis-media/media.amprtsp://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 command streams jpeg video.
It seems to support Unicast, Multicast, and HTTP modes.
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.
rtsp://192.168.0.172/live.sdprtsp://192.168.0.172/live2.sdprtsp://192.168.0.172/live3.sdprtsp://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.
The LEADTOOLS Transforms SDK supports H.264, MPEG4 and jpeg video and AAC/AMR audio.
It seems to support Unicast and Multicast modes. The HTTP mode does not seem to be supported.
rtsp://192.168.6.101/<filename.mp4> <filename.mp4> can be any file or playlist present on the server. Both video and audio compression are the same as the audio and video compression of the file. Playback of MPEG4 video and AAC/AMR audio files has been tested with success.
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 obtained when clicking View Video in the browser.
The server uses H264 video and AAC audio.