Our full-service platform can power any workflow — with reliability to boot. All rights reserved. Terms Privacy Trademarks Legal. Subscribe and stay up to date Learn about all the codecs and protocols, the latest live streaming trends, and more.
Learn More. Never Miss a Beat Subscribe to Blog. Her background is in streaming and network infrastructure. Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.
Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law. If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information informit.
On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email.
Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature. We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form. Pearson automatically collects log data to help ensure the delivery, availability and security of this site.
We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources. Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site.
While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson but not the third party web trend services to link information with application and system log data.
Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services. This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising.
Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site. Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.
Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time. If a user's personally identifiable information changes such as your postal address or email address , we provide a way to correct or update that user's personal data provided to us.
This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service informit.
Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. Connection: A transport layer virtual circuit established between two programs for the purpose of communication.
Container file: A file which may contain multiple media streams which often comprise a presentation when played together. RTSP servers may offer aggregate control on these files, though the concept of a container file is not embedded in the protocol. Continuous media: Data where there is a timing relationship between source and sink; that is, the sink must reproduce the timing relationship that existed at the source.
The most common examples of continuous media are audio and motion video. Continuous media can be real-time interactive , where there is a "tight" timing relationship between source and sink, or streaming playback , where the relationship is less strict. Entity: The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity- body, as described in Section 8.
This includes such things as clockrates, color tables, etc. Any transport- independent information which is required by a client for playback of a media stream occurs in the media initialization phase of stream setup.
Media parameter: Parameter specific to a media type that may be changed before or during stream playback. Media server: The server providing playback or recording services for one or more media streams. Different media streams within a presentation may originate from different media servers. A media server may reside on the same or a different host as the web server the presentation is invoked from. Media stream: A single media instance, e. Message: The basic unit of RTSP communication, consisting of a structured sequence of octets matching the syntax defined in Section 15 and transmitted via a connection or a connectionless protocol.
Participant: Member of a conference. A participant may be a machine, e. Presentation: A set of one or more streams presented to the client as a complete media feed, using a presentation description as defined below. In most cases in the RTSP context, this implies aggregate control of those streams, but does not have to.
Presentation description: A presentation description contains information about one or more media streams within a presentation, such as the set of encodings, network addresses and information about the content. The presentation description may take several different formats, including but not limited to the session description format SDP.
If an HTTP response is meant, that is indicated explicitly. If an HTTP request is meant, that is indicated explicitly. Transport initialization: The negotiation of transport information e. Secure: RTSP re-uses web security mechanisms. One may also reuse transport or network layer security mechanisms. Multi-server capable: Each media stream within a presentation can reside on a different server. The client automatically establishes several concurrent control sessions with the different media servers.
Media synchronization is performed at the transport level. Control of recording devices: The protocol can control both recording and playback devices, as well as devices that can alternate between the two modes "VCR". Separation of stream control and conference initiation: Stream control is divorced from inviting a media server to a conference. The only requirement is that the conference initiation protocol either provides or can be used to create a unique conference identifier.
In particular, SIP [12] or H. Presentation description neutral: The protocol does not impose a particular presentation description or metafile format and can convey the type of format to be used.
Proxy and firewall friendly: The protocol should be readily handled by both application and transport-layer SOCKS [14] firewalls. Appropriate server control: If a client can start a stream, it must be able to stop a stream. Servers should not start streaming to clients in such a way that clients cannot stop the stream. Transport negotiation: The client can negotiate the transport method prior to actually needing to process a continuous media stream.
Capability negotiation: If basic features are disabled, there must be some clean mechanism for the client to determine which methods are not going to be implemented. This allows clients to present the appropriate user interface. For example, if seeking is not allowed, the user interface must be able to disallow moving a sliding position indicator. An earlier requirement in RTSP was multi-client capability.
However, it was determined that a better approach was to make sure that the protocol is easily extensible to the multi-client scenario. Stream identifiers can be used by several control streams, so that "passing the remote" would be possible.
The protocol would not address how several clients negotiate access; this is left to either a "social protocol" or some other floor Schulzrinne, et. It is up to the creators of presentation descriptions not to ask the impossible of a server. This is equivalent to adding new parameters to an HTML tag. If the client needs negative acknowledgement when a method extension is not supported, a tag corresponding to the extension may be added in the Require: field see Section If the recipient of the message does not understand the request, it responds with error code Not implemented and the sender should not attempt to use this method again.
The overall presentation and the properties of the media the presentation is made up of are defined by a presentation description file, the format of which is outside the scope of this specification.
The presentation description file may be obtained by the client using Schulzrinne, et. For the purposes of this specification, a presentation description is assumed to describe one or more presentations, each of which maintains a common time axis. For simplicity of exposition and without loss of generality, it is assumed that the presentation description contains exactly one such presentation. A presentation may contain several media streams.
The presentation description file contains a description of the media streams making up the presentation, including their encodings, language, and other parameters that enable the client to choose the most appropriate combination of media.
In this presentation description, each media stream that is individually controllable by RTSP is identified by an RTSP URL, which points to the media server handling that particular media stream and names the stream stored on that server. Several media streams can be located on different servers; for example, audio and video streams can be split across servers for load sharing.
The description also enumerates which transport methods the server is capable of. Besides the media parameters, the network destination address and port need to be determined. Several modes of operation can be distinguished: Unicast: The media is transmitted to the source of the RTSP request, with the port number chosen by the client.
Alternatively, the media is transmitted on the same reliable stream as RTSP. Multicast, server chooses address: The media server picks the multicast address and port. This is the typical case for a live or near-media-on-demand transmission. Multicast, client chooses address: If the server is to participate in an existing multicast conference, the multicast address, port and encryption key are given by the conference description, established by means outside the scope of this specification.
Therefore, the server needs to maintain "session state" to be able to correlate RTSP requests with a stream. The state transitions are described in Section A. Many methods in RTSP do not contribute to state.
The RTSP session ceases to exist on the server. It also may interact with HTTP in that the initial contact with streaming content is often to be made through a web page. The current protocol specification aims to allow different hand-off points between a web server and the media server implementing RTSP. HTTP is an asymmetric protocol where the client issues requests and the server responds. In RTSP, both the media client and media server can issue requests.
RTSP requests are also not stateless; they may set parameters and continue to control a media stream long after the Schulzrinne, et. Re-using HTTP functionality has advantages in at least two areas, namely security and proxies. The requirements are very similar, so having the ability to adopt HTTP work on caches, proxies and authentication is valuable. RTSP assumes the existence of a presentation description format that can express both static and temporal properties of a presentation containing several media streams.
For brevity, [HX. Y] is to be taken to refer to Section X. All the mechanisms specified in this document are described in both prose and an augmented Backus-Naur form BNF similar to that used in [H2. It is described in detail in RFC [17], with the difference that this RTSP specification maintains the "1 " notation for comma-separated lists. In this memo, we use indented and smaller-type paragraphs to provide background and motivation.
This is intended to give readers who were not involved with the formulation of the specification an understanding of why things are the way that they are in RTSP. Note that fragment and query identifiers do not have a well-defined meaning at this time, with the interpretation left to the RTSP server. The scheme rtsp requires that commands are issued via a reliable protocol within the Internet, TCP , while the scheme rtspu identifies an unreliable protocol within the Internet, UDP.
If the port is empty or not given, port is assumed. A presentation or a stream is identified by a textual media identifier, using the character set and escape conventions [H3.
URLs may refer to a stream or an aggregate of streams, i. Accordingly, requests described in Section 10 can apply to either the whole presentation or an individual stream within the presentation. Note that some request methods can only be applied to streams, not presentations and vice versa. This does not imply a standard way to reference streams in URLs. The presentation description defines the hierarchical relationships in the presentation and the URLs for the individual streams.
A presentation description may name a stream "a. This decoupling also allows presentation descriptions to be used with non-RTSP media control protocols simply by replacing the scheme in the URL. They can contain any octet value.
The conference identifier MUST be globally unique. For H. These conferences are created by protocols outside the scope of this specification, e. Instead of the RTSP client explicitly providing transport information, for example, it asks the media server to use the values in the conference description instead.
Linear white space must be URL-escaped. See Section The time code has the format hours:minutes:seconds:frames. For the "frames" field in the time value can assume the values 0 through The difference between 30 and If the frame value is zero, it may be omitted. Subframes are measured in one-hundredth of a frame. The timestamp consists of a decimal fraction. The part left of the decimal may be expressed in either seconds or hours, minutes, and seconds.
The part right of the decimal point measures fractions of a second. The beginning of a presentation corresponds to 0. Negative values are not defined.
The special constant now is defined as the current instant of a live event. It may be used only for live events. It is often digitally displayed on a VCR. The npt-sec notation is optimized for automatic generation, the ntp-hhmmss notation for consumption by human readers. The "now" constant allows clients to request to Schulzrinne, et. This is needed since neither absolute time nor zero time are appropriate for this case.
Fractions of a second may be indicated. These tags are used in Require Section The name MUST not contain any spaces, control characters or periods. Text-based protocols make it easier to add optional parameters in a self-describing manner. Since the number of parameters and the frequency of commands is low, processing efficiency is not a concern. Text-based protocols, if done carefully, also allow easy implementation of research prototypes in scripting languages such as Tcl, Visual Basic and Perl.
This is also the encoding used for RTCP. ISO translates directly into Unicode with a high-order octet of zero. ISO characters with the most-significant bit set are represented as x 10xxxxxx. It was designed to control the streams without downloading any files. When a video stream is started, a device using the protocol sends an RTSP request to the media server that initiates the setup process.
I will give you some example requests in the following section. After that, a user can watch, sort or turn off the stream. RTSP maintains an end-to-end connection with TCP and achieves a high throughput over this stable connection without requiring any local download or caching. The protocol does not support content encryption or retransmission of lost packets, as RTSP is connected to a dedicated server for streaming and relies on RTP to transmit real media.
These limitations along with scaling problems, led to a drop in overall RTSP usage. When negotiating and controlling media streams, RTSP usually uses the following commands usually sent from the client to the server:. You can find more information here. The critical point here is that each protocol has its own unique purpose, features, and way of working. After this section, you will be able to choose the best alternative to RTSP streaming protocol for your needs and use case.
RTMP streaming protocol, Transmission Control Protocol-based technology, was developed by Macromedia for streaming audio, video, and data over the Internet, between a Flash player and a server. Macromedia was purchased by its rival Adobe Inc. WebRTC stands for web real-time communications. WebRTC is a very exciting, powerful, and highly disruptive cutting-edge technology and streaming protocol.
And you can do that without the need of any prerequisite of plugins to be installed in the browser. Thanks to WebRTC video streaming technology, you can embed the real-time video directly into your browser-based solution to create an engaging and interactive streaming experience for your audience without worrying about the delay.
WebRTC video streaming is just changing the way of engagement in the new normal.
0コメント