RTMP协议

Real Time Messaging Protocol

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 works just like RTMPT, 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.

Operation

The raw TCP-based RTMP protocol 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 protocol 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 protocol 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][1]}

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.

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 can stream video and audio from RTMP servers. Recently, the open source media player XBMC has acquired preliminary support for playing RTMP streams in its SVN version (see the patch). Recent versions of the popular cross platform Free and Open Source media player Videolan (VLC) also support RTMP.

RTMP server software

Currently, the only full implementation RTMP servers are the Adobe Flash Media Server, Wowza Media Server and WebORB Integration Server (free and available for .NET, Java and ColdFusion) both commercial and closed source implementations.

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. There are some other RTMP-servers with basic functionality available over at Google Code

See also

Real Time Media Flow Protocol (RTMFP) based on User Datagram Protocol (UDP)

原文出处 http://www.openred5.com/bbs/viewthread.php?tid=188&extra=page%3D1

RTMP协议概述

介绍:

RTMP协议是被Flash用于对象,视频,音频的传输.该协议建立在TCP协议或者轮询HTTP协议之上.
RTMP协议就像一个用来装数据包的容器,这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据.
一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的.

网络连接(Connection)

一个Actionscrīpt连接并播放一个流的简单代码:
CODE:
var videoInstance:Video = your_video_instance;
var nc:NetConnection = new NetConnection();
var connected:Boolean = nc.connect("rtmp:/localhost/myapp");
var ns:NetStream = new NetStream(nc);
videoInstance.attachVideo(ns);
ns.play("flvName");

默认端口为1935

握手

Client → Server :向服务器发出握手请求.这不属于协议包一部分,该握手请求第一个字节为(0×03),其后跟着1536个字节.经管看上去这部分的内容对于RTMP协议来说并不是至关重要的,但也不可随意对待.
Server → Client :服务器向客户端回应握手请求.这部分的数据仍然不属于RTMP协议的部分.该回应的其实字节仍然为(0x03),但是后边跟着个长度为1536个字节(一共为3072 )的包块.第一个1536块看上去似乎可以是任意内容,甚至好像可以是Null都没有关系.第二个1536的代码块,是上一步客户端向服务器端发送的握手请求的内容.
Client→Server:把上一步服务器向客户端回应的第二块1536个字节的数据块.

至此客户端与服务器端的握手结束,下面将发送RTMP协议的包内容.

Client → Server :向服务器发送连接包.
Server → Client :服务器回应.
... .... 等等... ...

RTMP 数据类型

0×01	Chunk Size	changes the chunk size for packets
0×02	Unknown	anyone know this one?
0×03	Bytes Read	send every x bytes read by both sides
0×04	Ping	ping is a stream control message, has subtypes
0×05	Server BW	the servers downstream bw
0×06	Client BW	the clients upstream bw
0×07	Unknown	anyone know this one?
0×08	Audio Data	packet containing audio
0×09	Video Data	packet containing video data
0x0A - 0×11	Unknown	anyone know?
0×12	Notify	an invoke which does not expect a reply
0×13	Shared Object	has subtypes
0×14	Invoke	like remoting call, used for stream actions too.

Shared Object 数据类型

0×01	Connect
0×02	Disconnect
0×03	Set Attribute
0×04	Update Data
0×05	Update Attribute
0×06	Send Message
0×07	Status
0×08	Clear Data
0×09	Delete Data
0x0A	Delete Attribute
0x0B	Initial Data

RTMP包结构

RTMP包 包含一个固定长度的包头和一个最长为128字节的包体.包头可以是下面4种长度的任意一种:12, 8, 4, or 1 byte(s).
第一个字节的前两个Bit很重要,它决定了包头的长度.它可以用掩码0xC0进行"与"计算.下面的表格罗列了可能的包头长度:

Bits	Header Length
00	12 bytes
01	8 bytes
10	4 bytes
11	1 byte

我们在这里讨论关RTMP包结构的问题并不是非常的详细.我们在以后有时间会讨论关于AMF的问题(敬请期待...),其实RTMP包结构就是使用了AMF格式.

流

关于流的操作我们需要进一步研究,在论坛中的 http://www.openred5.com/bbs/viewthread.php?tid=175&extra=page%3D1这篇文章研究的还是不错的,大家可以参考.不过下面可以列一个关于客户端向服务器端发送流的流程:

Client→Server :发送一个创建流的请求.
Server→Client :返回一个表示流的索引号.
Client→Server :开始发送.
Client→Server :发送视音频数据包(这些包在同一个频道(channel)并用流的索引号来唯一标识).

 

From：

http://hi.baidu.com/xiejiangboblog/blog/item/38eb5a25499a8234c89559f9.html