The RTSP Source Element handles media streams stored on servers supporting the Real-Time Streaming Protocol (RFC 2326).
Module Name | Streamer RTSP Source Element |
---|---|
File Name | librtspelement.so |
Class Count | 1 |
RTSP Source element at beginning of pipeline.
The RTSP Source Element is a general implementation of the Real-Time Streaming Protocol (RTSP) described in RFC 2326. The element supports most RTSP features used by popular RTSP servers on the market.
Name | RTSP Source Descriptor |
---|---|
Version | 1 |
Interface Name | IElementDescriptor |
Binding | C++ |
Name | RTSP Source |
---|---|
Type | Source |
Priority | 500 |
Output Formats | Raw |
This element accepts URL strings on the form:
rtsp://<address>[:<port>]/<path>
where <address> is the network address given either as an IPv4 address in standard dot notation or as a host name. The <port> is optional and defaults to the standard RTSP port 554. The entire <path> section after the third slash is not used by the RTSP element. The path is forwarded without modification to the server.
Examples:
rtsp://clips.example.com:554/presentation.ts rtsp://212.214.69.146/directory/file
Since the element is a source element all metadata is produced by the element itself.
Key | Input | Output |
---|---|---|
_ConnectionType | Produced | Committed |
_StreamUrl | Produced | Committed |
_PlaybackMode | Produced | Committed |
_SourcePosition | Produced | Committed |
_SourcePace | Produced | Committed |
_StreamPlayTime | Produced | Committed |
_SourceServer | Produced | Committed |
The RTSP source element supports the full range of user operations, including fast forward and rewind. Winding may be performed in a user-defined speed provided the server supports the requested speed.
The RTSP element is effectively an RTSP client as described by RFC 2326 capable of on-demand playback of stored content. However, in some areas RFC 2326 presents several optional methods for performing a specific operation, and in others it is rather vague about relevant details. The element implements a particular subset of RFC 2326 that has proven to work properly with common RTSP servers.
Some RTSP servers require the use of custom headers in methods sent by the client. Every time it establishes a connection with a server, the RTSP element tries to determine the make and model of the server so that it can later customize the method calls for that particular server.
The RTSP element uses TCP for the stream control channel, i.e. a single persistent transport connection is used for transmitting the entire dialog of RTSP method requests and responses between client and server. Pipelining of method requests is not used. If the TCP connection is closed by the server the element will assume that the session ended and will tear it down on the client side as well. Connectionless mode is not supported and consequently the RTSP element does not accept the rtspu: URL scheme.
The RTSP element supports unicast stream transport only, and uses UDP as lower-transport protocol. It provides a UDP port to which the server sends the media stream. All stream data received on that port is committed without modification to the output pad of the RTSP element. Because of the inherently unreliable nature of UDP, packet loss or reordering may occur, and those conditions must be handled by other elements later in the pipeline, preferably at the format discovery stage.
End-of-stream handling is an area where the RFC 2326 is a bit vague. The RTSP element supports the use of the ANNOUNCE method request with a Notify or x-notify header, sent from server to client. This is a de-facto extension of the RTSP protocol used by some RTSP servers. Using this extension, the ANNOUNCE method may signal end-of-stream and beginning-of-stream conditions. However, sending ANNOUNCE requests is not the only way of signalling stream boundary situations. In some pipeline configurations there are other elements capable of decoding in-band signalling information carried by protocols like DSM-CC (ISO/IEC 13181-6). In-band signalling is more reliable than out-of-band signalling like ANNOUNCE, so in-band signalling has precedence when it is available.
RTSP is still evolving. Work is in progress within the IETF MMUSIC working group to write a new RFC to replace RFC 2326. The RTSP element is designed with today's requirements in mind. It has been designed and tested to work properly with common RTSP servers available on the market today but it does not provide a full implementation of RFC 2326. There is a good chance that it will work properly with other RTSP servers with which it has not been tested before but error free operation cannot be guaranteed in those cases.
The video servers supported by this element are listed in the "Statement of Compliance KreaTV TV Software" document. Observe that the Bitband server uses its own element even though recent versions implement the RTSP protocol.