RTMP: Real Time Messaging Protocol

 

 

Real Time Messaging Protocol

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Real Time Messaging Protocol (RTMP) was initially a proprietary protocol developed by Macromedia for streaming audio, video and data over the Internet, between a Flash player and a server. Macromedia is now owned by Adobe, which has released the specification of the protocol for public use.

The RTMP protocol has three variations:

1. The "plain" protocol which works on top of TCP and uses port number 1935 by default.
2. RTMPT which is encapsulated within HTTP requests to traverse firewalls.
3. RTMPS which is RTMPT over a secure SSL connection using HTTPS.

While the primary motivation for RTMP was to be a protocol for playing Flash video, it is also used in some other applications, such as the Adobe LiveCycle Data Services ES.

[edit] Operation

RTMP (except RTMFP) is a TCP-based procotol which maintains persistent connections and allows low-latency communication. To deliver streams smoothly and transmit as much information as possible, it splits streams into fragments and their size is negotiated dynamically between the client and server while sometimes it is kept unchanged: the default fragment sizes are 64-bytes for audio data, and 128 bytes for video data and most other data types. Fragments from different streams may then be interleaved, and multiplexed over a single connection. With longer data chunks the protocol thus carries only a one-byte header per fragment, so incurring very little overhead. However, in practice individual fragments are not typically interleaved. Instead, the interleaving and multiplexing is done at the packet level, with RTMP packets across several different active channels being interleaved in such a way as to ensure that each channel meets its bandwidth, latency, and other quality-of-service requirements. Packets interleaved in this fashion are treated as indivisible, and are not interleaved on the fragment level.

The RTMP defines several channels on which packets may be sent/received, and which operate independently of each other. For example, there is a channel for handling RPC requests and responses, a channel for video stream data, a channel for audio stream data, a channel for out-of-band control messages (fragment size negotiation, etc.), and so on. During a typical RTMP session, several channels may be active simultaneously at any given time. When RTMP data is encoded, a packet header is generated. The packet header specifies, amongst other matters, the id of the channel on which it is to be sent, a timestamp of when it was generated (if necessary), and the size of the packet's payload. This header is then followed by the actual payload content of the packet, which is fragmented according to the currently agreed-upon fragment size before it is sent over the connection. The packet header itself is never fragmented, and its size does not count towards the data in the packet's first fragment. In other words, only the actual packet payload (the media data) is subject to fragmentation.

At a higher level, the RTMP encapsulates MP3 or AAC audio and FLV1 video multimedia streams, and can make remote procedure calls (RPCs) using the Action Message Format. Any RPC services required are made asynchronously, using a single client/server request/response model, such that real-time communication is not required.^{[clarification needed][1]}

[edit] HTTP tunneling

RTMP packets can be exchanged via two HTTP tunneling protocols:

• In RTMP Tunneled (RTMPT), RTMP data is encapsulated and exchanged via HTTP, and messages from the client (the media player, in this case) are addressed to port 80 (the default for HTTP) on the server.
• In RTMP Secure (RTMPS), RTMP data is encapsulated and exchanged via HTTPS, and messages from the client are addressed to port 443 (the default for HTTPS) on the server. This also has a non-RTMPT mode 'native' in which the data is not encapsulated for transmission over HTTPS, but in which the data is simply encrypted with SSL.

While the messages in RTMPT and RTMPS are larger than the equivalent non-tunneled RTMP messages due to HTTP and HTTPS headers, RTMPT and RTMPS may facilitate the use of RTMP in scenarios where the use of non-tunneled RTMP would otherwise not be possible, such as when the client is behind a firewall that blocks non-HTTP and non-HTTPS outbound traffic.

[edit] Client software

The most widely adopted RTMP client is Adobe Flash Player, which supports playback of audio and video streamed from RTMP servers (when installed as a web browser plug-in).

Client software with only partial support for RTMP includes the open source media player XBMC, which has preliminary support for playing RTMP (but not RTMPE) streams.

The open-source command-line tool RTMPdump is designed to playback or save to disk the full RTMP stream including the RTMPE protocol Adobe uses for encryption. Originally supporting all versions of 32-bit Windows including Windows 98, from version 2.2 the software will run only on Windows XP and above (although earlier versions remain fully functional).

A fork of RTMPdump, without the code which Adobe claims violates the DMCA in the USA, has been released as FLVstreamer. This was developed as a direct response to Adobe's attempt in 2008 to suppress RTMPdump. FLVstreamer will save to disk ("download") a stream of audio or video content from any RTMP server, provided RTMPE is not enabled on the stream. It runs on Windows XP and above, but not on earlier versions of Windows.

Development of RTMPdump was restarted in October 2009, outside the United States, at the MPlayer site^[2]. The current version features greatly improved functionality, and has been rewritten to take advantage of the benefits of the programming language "C".

Gnash, an open source replacement for the Macromedia Flash Player on the Linux platform, intends to support RTMP streaming for Linux^[3].

Within the United States of America, software which contains measures for circumventing copy-protection code may be in breach of the U.S. Digital Millenium Copyright Act (DMCA). It is considered that only software which removes encryption from an RTMP stream (i.e. which unencrypts an RTMPE stream) is affected by that Act, and only if that software is used in, or hosted on a server within, the United States.

[edit] Server software

Some full implementation RTMP servers are:

• Adobe Flash Media Server,
• Adobe LiveCycle Data Services
• Amazon S3 & Amazon Cloudfront can stream using RTMP
• haXeVideo is a multithread FLV streaming server entirely written using the haXe programming language.
• RealNetworks' Helix Universal Server can support RTMP, RTMPT and RTMPS streaming for live and on-demand content
• Onlinelib VCS Video Communication Server (including iPhone Support)
• Red5 Media Server is a Java open source project which delivers a powerful video streaming and multi-user solution to the ©Adobe ©Flash Player and other exciting client technologies.
• Erlyvideo ^[4] has wide functionality: not only file streaming, but restreaming of MPEG-TS or Shoutcast to flash clients using RTMP.
• Unreal Media Server supports live RTMP streaming, in real-time and buffered modes.
• Wowza Media Server
• WebORB Integration Server (RTMP/RTMPT/RTMPS messaging and media streaming available for .NET and Java Enterprise, Community and Cloud editions)
• OneTeam Media Server has been announced on ProcessOne^[5].
• crtmpserver^[6] is a C++ implementation of rtmp server.
• FreeSWITCH RTMP media streaming available with mod_rtmp and allow interconnecting with other VoIP protocols (SIP, H.323) etc
• Netris iStream Video Server for services on demand from Netris

[edit] Specification

Adobe released what it claimed was the RTMP specification on 15th June 2009. That specification, however, omits crucial details of the protocol's implementation. It would be impossible to write a program incorporating the RTMP protocol based on the released specification alone; many essential details are omitted, and only limited additional facts can be determined by studying other implementations that use the protocol (such as librtmp), and by carrying out test TCP/IP packet captures.

The Adobe license to use this protocol requires that implementations of RTMP servers meet this specification.

Details missing from Adobe's published specification include:

• No word about the real RTMP handshake. If done incorrectly, a server implementation is unable to deliver h264/AAC content. Flash player silently fails the h264 content if the handshake is wrong. However, all client implementations will work because usually rtmp servers are more permissive in this regard (including FMS)
• Missing explanations about the format of an aggregate message.
• How each part of the aggregate message is encoded, omitting details of typeid (1 byte), length (big endian, 3 bytes), unknown (big endian, 3 bytes), unknown (big endian, 4 bytes), message (length bytes), and back pointer (big endian, 4 bytes).
• The fact that chunks are sent up to a maximum chunk size only; and that where a chunk exceeds that size it is still sent, with a header giving the total chunk size, but that after the maximum chunk size has been exceeded, a type 4 chunk header is then sent, starting the next part of the fragmented chunk.
• The fact that the message stream ID is encoded in little endian format, whilst almost every other integer value in the protocol is encoded in big endian.
• Explanations for some control messages for streams are missing (31 and 32). FMS sends them from time to time

The formal process^[7] is: the client software, such as rtmpdump, issues a request to the RTMP server for a connection, by sending a command including the requisite elements, thereby initiating the process of negotiating a connection. Such a command may be constructed using connection and authentication information obtained previously from the server by client software applications such as rtmpsrv.

[edit] On-demand Streams

In negotiating a connection, an RTMP client sends and receives a data stream containing multiple elements, as a single command line. An on-demand stream, using protocol 0 (not tunnelled, not encrypted), typically includes the following elements -^[8][9]

A. For a Limelight server

• --protocol : Protocol types include 0 (RTMP), 1 (RTMPT) [Tunnelled], or 3 (RTMPE) [Encrypted]
• --host : server address (a.k.a. domain address)
• -a : authentication elements (the alternative --app may be used instead)
  • Typically in the format -
    {application}?as={data}&av={data}&te={data}&mp={data}&et={data}&fmta-token={data}
  • application: A path address. For example, a1414/e3
  • as : For example, as=adobe-hmac-sha256
  • av : For example, av=1
  • te : For example, te=connect
  • mp : Typically, two or more comma-separated URL addresses, for alternative bitrate streams (mpeg format, mp3 or mp4)
  • et : Typically, a ten-character number (numerical)
  • fmta-token : Typically, a 64-character authentication (auth) string [i.e. an authentication token] (alphanumeric)
• -y : playpath (URL address of the desired bitstream, one of those specified in mp above)
  • Typically, in the format mp3:{path}/{filename}.mp3 or mp4:{path}/{filename}.mp4
• -o : Output filename

The foregoing are typically the only elements (or "switches") that are essential to a connection, if neither Tunnelling nor Encryption are in use by the server. Although other elements may be encountered in practice, they are normally non-essential.

Hence the following elements are typically sent by the client software^[10] application, as a single command line -

    program.exe --protocol 0 --host xxxxxxxx.fcod.llnwd.net
   -a path?as=data&av=data&te=data&mp=data&et=data&fmta-token=data
   -y mp4:URL/filename.mp4 -o file_mp4.flv

The parts comprising the -a (or --app) element must be incorporated in it in the order shown above, as the sequence in which its parts are received by the RTMP server is critical.

The authentication strings (et= and fmta-token=) contain session information, so will change on each fresh connection made to the server (which in practice typically means they will expire if a new session is begun, not literally on every attempt to resume a connection), but the other elements will not usually vary from session to session.

B. For an Akamai server

The command line is typically as above, except that the -a (or --app) element contains the following parts instead -

• • auth : Typically, a 62-character authentication (auth) string [i.e. an authentication token] (alphanumeric)
  • aifp : For example, aifp=v001
  • slist : Typically, the URL address of the stream

Hence the following elements are typically sent by the client software application^[10], as a single command line -

    program.exe --protocol 0 --host xxxxxxx.edgefcs.net
   -a ondemand?auth=data&aifp=data&slist=data
   -y mp3:URL/filename -o file_mp3.flv

The parts comprising the -a (or --app) element must be incorporated in it in the order shown above, as the sequence in which its parts are received by the RTMP server is critical.

The authentication string (auth=) contains session information, so will change on each fresh connection made to the server (typically, if a new session is begun, e.g. the computer is restarted, not literally on every attempt to resume a connection). The other parts will not usually vary from session to session.

Note - The above describes the simplified form, whereby the stream is first saved to the user's hard disk, to be played back thereafter in a media player capable of playing an FLV encoded file (H.263 or H.264 encoding), such as GOM Player. If it's desired, instead, to play the stream directly from the RTMP server, thus giving immediate playback, additional elements will be needed in the command line including -

-f : This specifies the version of the Flash plugin installed on the user's computer. For example, -f "WIN 9,0,260,0" would indicate the user has the Windows version of Flash Player 9, release 260

-W : The capital W command. This is the URL address of the SWF player used to play the stream, as indicated by the web page from which the stream is derived. For example, path/9player.swf?revision=18269_21576

[edit] Live Streams

The command line for a live stream, using protocol 0 (not Tunnelled, not Encrypted), typically includes the following elements -^[8][9]

A. For an Akamai server

The command line is typically as for an Akamai on-demand stream. But the -a (or --app) element contains the following parts

• auth : Typically, a 62-character authentication (auth) string [i.e. an authentication token] (alphanumeric)
• aifp : For example, aifp=v001
• slist : Typically, the URL address of the stream, in the format xxxxx_x_@xxxx (e.g. Radio_7_Int@6463); or more than one URL if more than one bitrate is available [see note]

Note - If the slist string contains two or more alternative streams (i.e. offers a choice of streams at alternative bitrates), the playpath element (--playpath or -y) specifies the one chosen by the user, as the identifier item.

Hence the following sequence is typically sent by the client software application^[10], as a single command line -

rtmpdump.exe --live --protocol 0 --host xxxxxxx.live.edgefcs.net
-a live?auth=data&aifp=data&slist=data
--playpath {identifier}?auth=data&aifp=data&slist=data -o output.flv

All these items are mandatory, and must be included in the order shown above. The string following the ? (question mark) in both the
-a and --playpath elements will typically be identical. The identifier item will typically be a sub-set of the slist data (if the latter offers a choice), otherwise they too will be identical. The -o element can specify an output filename chosen by the user.

Specifying the complete playpath is unnecessary, as that element is constructed in memory by the client application. Typically, in memory it takes the following form -

   -y rtmp://xxxxxxx.live.edgefcs.net/xxxxx_x_@xxxx?auth=[62 characters]&aifp=v001&slist=xxxxx_x_@xxxx,xxxxx_x_@xxxx

[edit] RTMFP

• Researchers at crtmpserver are reverse engineering the rtmfp protocol. This is currently a work-in-progress.
• Blue5 - A project to create open source versions of RTMPE and RTMFP.

[edit] See also

• Orbit Downloader for Windows XP
• Protected Streaming Info about RTMPS and RTMPE
• Real Time Media Flow Protocol (RTMFP), based on UDP

[edit] References

This article's citation style may be unclear. The references used may be made clearer with a different or consistent style of citation, footnoting, or external linking. (September 2009)

1. ^ Using RPC services in Flex Data Services 2. Archived from the original on 2007-04-03. http://web.archive.org/web/20070403192843/http://www.adobe.com/devnet/flex/articles/rpc_service_02.html. Retrieved 2007-04-16. 
2. ^ "Updates:2009-11-01". http://www.mplayerhq.hu/design7/news.html. Retrieved 2009-11-01. 
3. ^ "Linux Funding". http://linuxfund.org/projects/gnash/. Retrieved 2010-01-01. 
4. ^ erlyvideo website
5. ^ Presentation in Erlang Factory conference in San Francisco - 30 april 2009 - available on ProcessOne website and SlideShare
6. ^ crtmpserver
7. ^ [1]
8. ^ ^{a b} RTMPdump developer page
9. ^ ^{a b} RTMP tutorial
10. ^ ^{a b c} RTMPdump client software

[edit] External links

• Adobe Developer page - RTMP - official specification
• OSFlash - RTMP OS

Retrieved from " http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol"

Categories: Adobe Flash | Multimedia | Network protocols