Jump to content

Real-Time Messaging Protocol

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by StreamRecorder (talk | contribs) at 13:11, 5 March 2010 (RTMP server software). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Real Time Messaging Protocol (RTMP) is a proprietary protocol developed by Adobe Systems for streaming audio, video and data over the Internet, between a Flash player and a server.

The RTMP protocol has three variations:

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

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

On 20 January 2009 Adobe announced it will publish the RTMP specification.[1] On 21 May 2009 Adobe filed a DMCA removal request on a Sourceforge-hosted implementation of the protocol.[2][3]

On Monday, June 15, 2009 Adobe released the RTMP Specification

Operation

The raw TCP-based RTMP maintains a single persistent connection and allows real-time communication. To guarantee smooth delivery of video and audio streams, while still maintaining the ability to transmit bigger chunks of information, the protocol may split video and data into fragments. The size of the fragments used can be negotiated dynamically between the client and server, and even disabled completely if desired, although the default fragment sizes are 128 bytes for video and most other data types, and 64-bytes for audio data. Fragments from different streams may then be interleaved and multiplexed over a single connection. With longer data chunks, the protocol would then only carry a one-byte header per fragment, thus incurring very little overhead. In practice however, 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 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 dedicated 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 packetized, a packet header is generated. The packet header specifies, among other things, the id of the channel that it is to be sent on, the timestamp at which is was generated (if necessary), and the size of the packet payload. This is then followed by the packet payload, which is fragmented according to the currently agreed-upon fragment size before it is serialized 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 data is subject to fragmentation.

At a higher level, the RTMP encapsulates MP3 and Flash Video multimedia streams, and can make remote procedure calls (RPCs) using the Action Message Format.

Other RPC services are made asynchronously with a single client/server request/response model, so real-time communication is not necessary.[clarification needed][4]

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.

RTMP client software

The most well-known RTMP client is Adobe's Flash player which has full support for streaming video and audio from RTMP servers.

Other third-party players have partial support for RTMP, such as the open source media player XBMC which has acquired preliminary support for playing RTMP streams in its SVN version. rtmpdump is an open-source command-line tool that is designed to dump the full RTMP stream. It implements the RTMPE protocol, which Adobe believes to be an encryption and copyright protection scheme: however analysis of RTMPE shows that RTMPE is nothing of the kind. rtmpdump was removed from its original SourceForge page due to Adobe issuing a Digital Millennium Copyright Act takedown notice, which Sourceforge did not have the resources to contest, and could not place any other sourceforge projects at risk. flvstreamer is a fork of rtmpdump which removes all the code that Adobe believed was in violation of the DMCA (due to the belief by Adobe that RTMPE is an encryption mechanism). flvstreamer still allows users to download a stream of audio or video content from all RTMP servers, as long as RTMPE is not enabled on the server. rtmpdump development was restarted in October 2009 and is hosted at the MPlayer site[5]. It has much improved functionality and has been rewritten in C (was C++).

Gnash, an open source replacement for Adobe's Flash player, aims to support RTMP and is currently seeking donations for funding the necessary development[6].

RTMP server software

Currently, the only full implementation RTMP servers are:

  • Adobe Flash Media Server,
  • Onlinelib VCS Video Communication Server (including iPhone Support)
  • Wowza Media Server
  • WebORB Integration Server (free and available for .NET, Java and ColdFusion) both commercial and closed source implementations.
  • haXeVideo is a multithread FLV streaming server entirely written using the haXe programming language.
  • Red5 Media Server

There is a reverse engineered open source project called Red5 which aims to produce a feature-complete implementation written in Java. As of October 2007, the majority of the functionality is implemented, although the project is still in the beta stage. OneTeam Media Server has also been announced by ProcessOne[7]. C++ implementation is also available. It is called crtmpserver and is located here. There is Erlang implementation erlyvideo which has rather wide functionality: not only file streaming, but restreaming of MPEG-TS or Shoutcast to flash clients by RTMP.

RTMP recording software

Replay Media Catcher, the first RTMP downloader, was introduced by Applian Technologies in 2008. Nowadays there are more than a dozen of Stream recorders (for Windows/Mac OS/Linux) that can download or capture RTMP audio and video streams. Such streams can also be recorded using Screen video capture software. Stream recorders reproduce digital copies of videos bit by bit, while Screen video capture software re-compress videos.

RTMP Specification

Adobe has opened the Specification for the RTMP Protocol on June 15 of 2009 http://www.adobe.com/devnet/rtmp/

RTMFP Specification

See also

References

  1. ^ "Adobe to Open Flash Platform Messaging Protocol". Retrieved 2009-01-23. {{cite journal}}: Cite journal requires |journal= (help)
  2. ^ "Adobe has issued a DMCA removal request for rtmpdump". Linuxcentre. Retrieved 2009-05-22.
  3. ^ "Slashdot | Adobe Uses DMCA On Protocol It Promised To Open". Yro.slashdot.org. Retrieved 2009-05-22.
  4. ^ "Using RPC services in Flex Data Services 2". Retrieved 2007-04-16. {{cite journal}}: Cite journal requires |journal= (help)
  5. ^ "Updates:2009-11-01". Retrieved 2009-11-01.
  6. ^ "Linux Funding". Retrieved 2010-01-01.
  7. ^ Presentation made in Erlang Factory conference in San Francisco - 30 april 2009 - available on ProcessOne website and SlideShare