RTMP协议简介

专题报告：RTMP

协议

目录

专题报告：RTMP协议 (1)

一：什么是rtmp (3)

二：RTMP消息格式 (5)

三：RTMP握手过程 (10)

三．协议控制消息 (21)

四：消息交换的例子 (25)

写在前面红色字体是重点必读，蓝色字体是分点便于区分，绿色字体是次分点便于区分一：什么是rtmp

RTMP协议

Real Time Messaging Protocol（实时消息传送协议协议)实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。它有三种变种：

1)工作在TCP之上的明文协议，使用端口1935；

2)RTMPT封装在HTTP请求之中，可穿越防火墙；

3)RTMPS类似RTMPT，但使用的是HTTPS连接；

介绍:

RTMP协议是被Flash用于对象,视频,音频的传输.该协议建立在TCP协议或者轮询HTTP协议之上.

RTMP协议就像一个用来装数据包的容器,这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据.

一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的.

RTMP中定义了两种通信单元：消息（message）和消息块（chunk）.RTMP消息是协议中实现各种流媒体控制和应用的基本逻辑信息单元，消息从种类上可以分为协议控制消息、用于发送音频数据的音频消息、用于发送视频数据的视频消息、发送用户数据的数据消息、共享对象消息以及命令消息，属于相同逻辑通道的消息组成一个消息流，这个逻辑通道通过消息格式中的“消息流ID”字段来标识。

作为应用层协议，RTMP协议架构在TCP层之上，但RTMP消息并不是直接封装在TCP中，而是通过一个被称为消息块的封装单元进行传输。消息在网络上发送之前往往要分割成多个较少的部分，这些较小的部分就是消息块，属于不同消息流的消息块可以在网络上交叉发送。这样做可以保证各个消息流中的高优先级消息块能够严格按照时间顺序达到通信的对端。比如某个较长消息的实时性要求比较低，如果不进行消息块处理，等长消息都发送完毕后再发送实时性要求高的短消息，则会对流媒体的播放质量造成影响。

二：RTMP消息格式

RTMP消息包含两个部分，包头和有效负载。包头包含时间戳、消息长度、消息类型以及消息流ID。有效负载是包含在消息中的实际数据，例如：它可以是一些音频样本或者压缩的视频数据。

(1)、时间戳delta（timestamp delta）：消息的时间戳，占3个字节

(2)、消息长度（message length）：3个字节。消息的有效负载的长度，如果消息头不能被省略，他应该包含在长度中，这个字段在消息块包头中。注意这一般和消息块的有效负载长度是不一样的。消息块的有效负载长度是除了最后一个消息块外其他所有消息块都取消息块大小的最大值（通常默认为128字节）。

(3)、消息类型id（message type id）：1个字节。协议控制消息的类型字段的范围是被保留的，这些传播信息的消息被RTMP消息块和高层协议处理，所有其他的类型ID可被高层协议使用，被RTMP消息块当做不透明的值

(4)消息流ID（message stream id）：4个字节。消息流ID可以是任意值，不同的消息复用成同一消息块流以及解复用都是基于消息流ID。

消息分块

(1)、在握手以后，连接一个或者多个复用消息块，每个消息块流负载来自消息流中同一类的消息，每一个消息块的产生配有一个唯一的ID，被称为消息块流ID，消息块流在网络上传输。传输的时候每一个消息块在下一个消息块之前必须完全被发送，当接收结束，消息块基于消息块流ID被组装成消息。消息分块允许高层协议的大的消息被分割成小的消息，消息分块也允许小的消息被传送时带有小的包头，消息块的包头包含了信息的压缩表示，否则信息必须在消息自身中包含。

(2)、消息块的字节顺序：

RTMP的字节序和大多数网络协议一样是大端序，也有一些字段是小端序的，不过都有特殊的说明。

1).RTMP的head组成

RTMP的head在协议中的表现形式是chunk head，前面已经说到一个Message+ head 可以分成一个和多个chunk，为了区分这些chunk，肯定是需要一个chunk head的，具体的实现就把Message head的信息和chunk head的信息合并在一起以chunk head的形式表现。

一个完整的chunk的组成如下图所示

Chunk basic header：1 to 3

该字段包含chunk的stream ID和type 。chunk的Type决定了消息头的编码方式。该字段的长度完全依赖于stream ID，该字段是一个可变长的字段。

chunk basic head的长度为1~3个字节，具体长度主要是依赖chunk stream ID的长度，所谓chunk stream ID是flash server用来管理连接的客户端的信令交互的标识，协议最大支持65597个streamID 从3~65599。ID 0，1，2为协议保留，0代表ID是64~319（第二个byte + 64）；1代表chunk stream ID为64~65599（（第三个byte）* 256 + 第二个byte + 64）（小端表示）；2代表该消息为低层的协议（在RTMP协议中控制信令的chunk stream ID都是2）。3~63的chunk stream ID就是该byte的值。没有附加的字段来标识chunk stream ID。目前chunk basic head的长度一般为1个字节。这一个字节由两部分组成

fmt占两个bit用来标识紧跟其后的chunk Msg Header的长度，cs id占六个bit。

两位的fmt取值为0~3，分别代表的意义如下：

case 0：chunk Msg Header长度为11；

case 1：chunk Msg Header长度为7；

case 2：chunk Msg Header长度为3；

case 3：chunk Msg Header长度为0；所以只有一个字节的chunk basic header取值为chunk basic header = (fmt << 6) | (cs id).

其他的两种的字节情况分别为：

Chunk Msg Header：0, 3 ,7, 11

该字段包含了将要发送的消息的信息（或者是一部分，一个消息拆成多个chunk的情况下是一部分）该字段的长度由chunk basic header中的fmt决定。共有四种类型

类型0：11个字节的完整包头，如图所示

Timestamp：3bytes

对于type 0的chunk，绝对时间戳在这里表示，如果时间戳值大于等于0xffffff（16777215），该值必须是0xffffff,且时间戳扩展字段必须发送，其他情况没有要求。

message length：3bytes

Message的长度，注意这里的长度并不是跟随chunk head其后的chunk data（Payload）的长度，而是前文提到的一条信令或者一帧视频数据或音频数据的长度。前文提到过信令或者媒体数据都称之为Message，一条Message可以分为一条或者多条chunk。

message type id：1byte

message stream id：4bytes

message stream id的字节序是小端序，这个字段是为了解复用而设计的

类型1：7 个字节的chunk head

该类型不包含stream ID，该chunk的streamID和前一个chunk的stream ID是相同的，变长的消息，例如视频流格式，在第一个新的chunk以后使用这种类型，注意其中时间戳部分是相对时间，为与上一个绝对时间之间的差值如图所示：

类型2：3 字节的chunk head

该类型既不包含stream ID 也不包含消息长度，这种类型用于stream ID和前一个chunk相同，且有固定长度的信息，例如音频流格式，在第一个新的chunk以后使用该类型。如图所示：

类型3：0字节的chunk head:

这种类型的chunk从前一个chunk得到值信息，当一个单个消息拆成多个chunk时，这些chunk 除了第一个以外，其他的都应该使用这种类型。

Extend Timestamp：0 ,4 bytes

该字段发送的时候必须是正常的时间戳设置成0xffffff时，当正常时间戳不为0xffffff时，该字段不发送。当时间戳比0xffffff小该字段不发送，当时间戳比0xffffff大时该字段必须发送，且正常时间戳设置成0xffffff。

Chunk Data实际数据（Payload），可以是信令，也可以是媒体数据。

三：RTMP握手过程

握手

一个RTMP通信以握手开始，握手不像其他的协议，他包含三个固定长度的消息块。

客户（初始化通信的终端）和服务器每放发送同样的三个消息块，说明一下，被客户段发送的消息块被指定为C0，C1，C2，被服务器端发送的消息被指定为S0，S1，S2。

握手的顺序

握手以客户端发送C0和C1消息块位开始，客户端必须等到S1到达在发送C2。客户端必须等到S2接收到才可以发送其他的数据；服务端必须等到C0到达才发送S0和S1，在C1之后也会等待。服务端必须等到C1到达才发送S2，服务端必须等到C2到达后才发送其他数据。

阶段描述

未初始化协议版本在这个阶段中被发送，客户端个服务端没有初始化，客户端

在C0中发送协议版本，如果服务端支持版本，就在回应中发送S0和

S1，如果不能，服务端通过适当的行为进行恢复，在RTMP中，这个

行为是连接结束

版本发送在未初始化阶段以后客户端个服务端在版本发送阶段，客户端等待S1

包，服务端等待C1包，当接收到想要的包，客户端发送C2，服务端

发送S2，此时阶段变成了ACK的发送。

ACK发送客户端和服务端分别等待S2和C2

握手完成客户端和服务交换消息。

C0和S0格式

C0和S0包长8个字节

版本：8比特

在C0中，这个字段识别客户端需求的RTMP的版本，在S0中，这个字段识别服务器端选择的RTMP的版本，被定义的是版本3，0到2是被早前的版本使用的，4到31保留被用作未来的用途，32到255还没有被允许。不能区分客户的请求的版本的服务应该以3返回，客户端或许会选择3一下的版本，或者放弃握手。

C1和S1的格式：

C1和S1的数据包有1536个字节长，由以下几个字段组成。

时间：4个字节

这个字段包含时间戳，被当做以后消息块从终端发送的时间点，也许是0，或者一些任意的值，用来同步多重的消息块流，终端或许希望发送其他消息块流的时间戳的当前值。

0：4个字节

这个字段必须全0。

随机数据：1528个字节

这个字段可以包含任何任意的值，因为每个终端必须区分自己初始化的握手的返回数据和对方初始化的握手的返回数据，这个数据应该发送一些随机数。但是没有必要密码保护随机数和动态值。C2和S2的格式

C2和S2数据有1536字节长度，近似S1和C1的回声，由一下几个字段组成。

时间：4个字节

这个字段必须包含由每方发送的S1（对应C2）或者C1（对应S2）的时间戳.

时间2：4个字节

这个字段必须包含先前的由每一方发送数据包（S1或者C1）被读到的时间戳。

随机返回：1528个字节

这个字段必须包含在每方发送的S1（对应C2）或者S2（对应C1）的随机数据字段。每一方可以利用时间和时间2字段和当前时间戳组成作为连接的带宽或者延迟的评估。但是似乎没有用。

命令消息

RTMP服务器和客户端通过命令消息传递双方的命令信息，这些命令信息均采用AMF编码

方式。AMF编码方式是Adobe公司开发出的一种通信协议，它采用二进制形式，为基于Flash

的播放器和远端服务器提供一种轻量级的、高效能够的通信方式。目前AMF已经从AMF0

版本发展到了AMF3版本。通过命令消息，用户可以执行连接、创造流、发布、播放、暂停

的操作，接受方也可以通过命令消息向操作方发送返回命令的状态。发送方还可以通过命令

消息来向接收方请求远程成语调用

下面是在连接命令的命令对象中使用的名值对的描述：

属性类

型

描述示例值

App 字

符

串

客户端要连接到的服务应用名Testapp

Flashver 字

符

串Flash播放器版本。和应用文档中getversion（）函数返回的字符串相同。

FMSc/1.0

SwfUrl 字

符

串

发起连接的swf文件的url file://C:/ FlvPlayer.swf

TcUrl 字

符

串服务url。有下列的格式。

protocol://servername:port/appNam

e/appInstance

rtmp://localhost::1935/testap

p/instance1

fpad 布

尔

值

是否使用代理true or false

audioCode cs 数

字

指示客户端支持的音频编解码器SUPPORT_SND_MP3

videoCode cs 数

字

指示支持的视频编解码器SUPPORT_VID_SORENSON

pageUrl 字

符

串SWF文件被加载的页面的Url http://

somehost/sample.html

objectEnco ding 数

字

AMF编码方法

kAMF3

Connect命令的流程控制描述如下：

1.客户端发送连接命令给服务器，请求与服务器上的一个应用程序建立连接

Connect

windows acknowledgement size- set peer bandwidth- user control message(begin 0)- result(connect response)

2.服务器收到连接命令后，服务器发送窗口确认大小的消息给客户端。服务器也与连接命令

中提到的应用程序建立连接。

3.服务器发送设置带宽的消息给客户端。

windows acknowledgement size- set peer bandwidth- user control message(begin 0)- result(connect response)

4.客户端收到设置带宽的消息后，发送窗口确认大小的消息给服务器。

5.服务器在发送另一个用户控制消息给客户端，比如streambegin

6.服务器载发送一个控制命令通知客户端连接状态。这个消息也包括了一些特殊属性，比如

Flash流媒体服务器的版本、能力等。

Play命令的流程描述如下：

客户端在收到creatstream命令后向服务器发送play命令。

服务器收到play命令后发送协议控制消息来设置消息块的大小。

服务器发送另一个用户控制消息，说明“StreamRecorder”以及相关消息流ID

服务器发送另一个用户控制消息，通过“streambegin“向客户端表示流已经开始。

如果客户端前面的play命令发送成功。服务器在发送onstatus的命令消息。如果play命令请求的相关流媒体没有找到，服务器会在onstatus的命令消息中显示相关信息。

在以上信息交互完成后，服务器就开始向客户端发送视频和音频数据。

rtmp流媒体协议

H5视频直播扫盲 1 H5到底能不能做视频直播 当然可以， H5火了这么久，涵盖了各个方面的技术。 对于视频录制，可以使用强大的webRTC（Web Real-Time Communication）是一个支持网页浏览器进行实时语音对话或视频对话的技术，缺点是只在PC的chrome上支持较好，移动端支持不太理想。 对于视频播放，可以使用HLS(HTTP Live Streaming)协议播放直播流，ios和android都天然支持这种协议，配置简单，直接使用video标签即可。 webRTC兼容性： video标签播放hls协议视频：

1 2 3 4

Your browser does not support HTML5 video. 2 到底什么是HLS协议 简单讲就是把整个流分成一个个小的，基于HTTP的文件来下载，每次只下载一些，前面提到了用于H5播放直播视频时引入的一个.m3u8的文件，这个文件就是基于HLS协议，存放视频流元数据的文件。 每一个.m3u8文件，分别对应若干个ts文件，这些ts文件才是真正存放视频的数据，m3u8文件只是存放了一些ts文件的配置信息和相关路径，当视频播放时，.m3u8是动态改变的，video标签会解析这个文件，并找到对应的ts文件来播放，所以一般为了加快速度，.m3u8放在web服务器上，ts文件放在cdn上。 .m3u8文件，其实就是以UTF-8编码的m3u文件，这个文件本身不能播放，只是存放了播放信息的文本文件： 1 2 3 4 5#EXTM3U m3u文件头 #EXT-X-MEDIA-SEQUENCE 第一个TS分片的序列号#EXT-X-TARGETDURATION 每个分片TS的最大的时长#EXT-X-ALLOW-CACHE是否允许cache #EXT-X-ENDLISTm3u8文件结束符

rtmp协议

RTMP：Real Time Messaging Protocol 实时消息传送协议 字节序：大端 Message Format： Timestamp：4 bytes Length：3 bytes Type ID：1 bytes Message Stream ID：4 bytes 小端 Handshake three static_sized chunks client：C0 C1 C2 server：S0 S1 S2 simple handshake： handshake sequence 握手开始于客户端发送C0、C1块 客户端在发送C2块之前必须等待直到S1块被接收 客户端在发送任何其他数据之前必须等待直到S2块被接收 服务器在发送S0、S1之前必须等待直到C0被接收或是C1被接收服务器在发送S2之前必须等待直到C1被接收 服务器在发送任何其他数据之前必须等待直到C2被接收 C0和S0格式 一个字节（8bits） 本版本是3 C1和S1格式 1536个字节

C2和S2格式 1536个字节，是C1和S1的回复响应 time：必须包含对等段发送的时间戳（对C2来说是S1，对S2来说是C1）time2：必须包含先前发送的被对端读取的包（S1或C1）的时间戳 handshake diagram

Complete handshake Chunking Chunk format A header and data +--------------+----------------+--------------------+----------+ | Basic Header | Message Header | Extended Timestamp | Chunk Data| +--------------+----------------+--------------------+----------+ | | |<------------------- Chunk Header ----------------->| Chunk Format Basic header：1-3bytes，chunk stream ID and chunk type(fmt) 长度可变type depend on the format of the encoded message header the length depend on the chunk stream ID ID:3-65599,0\1\2 reserved 0:2bytes,ID range 64-319 (the second byte+64) 1:3bytes,ID range 64-65599(the third byte*256+the second byte+64) 2:low-level protocol 2-63: 64-319:

RTMP协议

RTMP Protocol Connect NetConnect.connect() Flash Play 通过NetConnect.connect连接到RTMP Server时,首先进行握手,再发送connect的参数. 1) 握手过程有三步: Step 1, Flash Player 至RTMP Server : 1个byte(0x03)+1536个byte数据. Step 2, RTMP Server至Flash Player : 1个byte(0x03)+1536个byte数据(Server的握手数据) + 1536个byte数据(通过和随机数hash得出, 详见附录) Step 3, Flash Player 至RTMP Server : 1536个byte数据(RTMP Server计算出来的). 注意:这个数据块没有1个byte的0x03. 2) 接下是connect参数 RTMP Server <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

RTMP Server >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Flash Player RTMP协议步骤 Step 1 发送一个0x05的包,即ServerBW, (channel 0x02) (0x00 26 25 a0) Step 2 发送一个0x06的包,即ClientBW, (channel 0x02) (0x00 26 25 a0) + (0x02) Step 3 发送一个0x14的包,即Invoke, (channel 0x03) (body超过128的长度就要分包, 用0xc3来) string (“_result”) + number (0x3F F0 00 00 00 00 00 00) + Object string (“capabilities”) ; number (31.0) string (“fmsV er”) ; string (随便填) (“RubyIZUMI/0,1,2,0”) End Of Object (0x00 00 09) //(connect status) + Object string (“code”) ; string (“NetConnection.Connect.Success”) string (“level”) ; string (“status”) string (“description”) ; string (“Connection Succeeded.”) End Of Object (0x00 00 09) RTMP Server <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

课题_nginx搭建rtmp协议流媒体服务器总结

nginx搭建rtmp协议流媒体服务器总结 最近在ubuntu12.04上搭建了一个rtmp服务器，感觉还挺麻烦的，所以记录下。 大部分都是参考网络上的资料。 前提： 在linux下某个目录中新建一个nginx目录。 然后进入该目录去下载搭建环境所需要的一些资源包。 此处在/root/ 目录下新建一个nginx目录即： /root/nginx/ ==================================== 1、安装依赖包: #yum -y install gcc glibc glibc-devel make nasm pkgconfig lib-devel openssl-devel expat-devel gettext-devel libtool mhash.x86_64 perl-Digest-SHA1.x86_64 2、安装相关工具包 1). git # mkdir soft-source # cd soft-source # wget ://https://www.sodocs.net/doc/fe9319583.html,/projects/git-snapshots/git/git-latest.tar.xz # xz -d git-latest.tar.xz # tar xzvf git-latest.tar # cd git-2014-06-27 # autoconf # ./configure # make && make install # git --version git version 2.0.0.GIT # cd .. 2). zlib # wget ://https://www.sodocs.net/doc/fe9319583.html,/zlib-1.2.8.tar.gz # tar -zxvf zlib-1.2.8.tar.gz cd zlib-1.2.8 # ./configure # make # make install # cd .. 3). pcre # wget ://exim.mirror.fr/pcre/pcre-8.12.tar.gz # tar zxvf pcre-8.12.tar.gz # cd pcre-8.12 # ./configure # make && make install # cd .. 4). yadmi yadmi的作用是为flv文件添加关键帧，才能实现拖动播放 # wget ://https://www.sodocs.net/doc/fe9319583.html,/projects/yamdi/files/yamdi/1.4/yamdi-1.4.tar.gz/download # tar xzvf download # cd yamdi-1.4 # make && make install # cd .. 使用方法： # yamdi -i input.flv -o out.flv 给input.flv文件添加关键帧，输出为out.flv文件 5). OpenSSL # wget ://https://www.sodocs.net/doc/fe9319583.html,/source/openssl-1.0.1c.tar.gz # tar -zxvf openssl-1.0.1c.tar.gz # ./config # make # make install 3、安装ffmpeg及其依赖包： 1). Yasm # wget ://https://www.sodocs.net/doc/fe9319583.html,/projects/yasm/releases/yasm-1.2.0.tar.gz # tar xzvf yasm-1.2.0.tar.gz

实时流煤体协议概述v1.0

实时流煤体协议概述v1.0

实时流煤体协议概述 流媒体传输类型： 流媒体传输分两类：实时流媒体和顺序流媒体 一般来说，如果视频为现场直播，或使用专用的流媒体服务器，或应用如RTSP等专用实时协议，即为实时流媒体传输； 如果使用普通的HTTP服务器，将音视频数据以从头至尾方式发送，则为顺序流媒体传输。 实时流传输既可传输实况直播，也可传输完整的音视频文件（专用协议流式）。 顺序流媒体不可用于实况直播，仅能传输完整的音视频文件（HTTP渐进式）。 主流的流媒体协议 主流的流媒体协议主要有：RTMP，HLS，RTSP等。

附：流媒体播放实现流程 一，h ttp渐进式下载原理（仅支持文件播放）http边下载边播放，严格意义上讲，不是实况直播协议。他的原理是先下载文件的基本信息，音频视频的时间戳，再下载音视频数据，以播放mp4为例，先下载文件头，根据文件头指引下载文件尾，然后再下载文件的音视频数据。 播放方式：1. 浏览器调用系统播放器播放； 2. 使HTML5的Video标签，浏览器内部支持直接播放。

二，苹果支持的hls原理（支持文件播放和实况直播）HLS的文件点播 1.使用“文件分段器”将基于H264和AAC或MP３的MPEG4分段， 生成.ts和.m3u8文件，存储于普通服务器上。 2.苹果应用程序或苹果浏览器可以通过访问.m3u8文件获取到索引， 并下载所需要的数据片段来播放。 HLS的实况直播 1.使用“流分段器”将基于H264、AAC、MP3的MPEG2传输 流分段， 2.可使用其它工具将MPEG4音视频文件加载到MPEG2传输流当中。 3.生成.ts和.m3u8文件，存储于普通服务器上。 4.苹果应用程序或苹果浏览器可以通过访问.m3u8文件获取到索引， 并下载所需要的数据片段来播放。 三，A dobe Flash 支持的RTMP协议（支持文件播放和实况直播） 必须采用Flash服务器FMS(Flash Media Server) 或 RED5. FMS的文件点播 1. 服务器（FMS或RED5）将F4v 或 Flv文件转化为RTMP流或HTTP流 2. 客户端（Flash插件或应用程序）获取RTMP流，提取相应的Flv 或 F4v文件片段进行播放。 FMS的实况直播 1.设备端（摄像头）将数据转化为F4v片段，通过RTMP流上传到服务器 2. 服务器（FMS或RED5）转发RTMP流到客户端 3. 客户端（Flash插件或应用程序）获取RTMP流，提取数据片段播放。 四，R TSP协议 RTSP为纯粹的传输控制协议。 RTSP协议本身不与它负载的媒体数据相关。 RTSP协议需要自定义客户端向服务器发送RTSP命令。

PANABIT支持协议库

Panabit V9.08（战国r3）专业版支持协议列表 (2009.10.16) 类别 应用协议 客户端 发布日期 版本号/注释 HTTP协议 WWW Web音乐 FLASH HTTP代理 HTTP下载 HTTP分块传输 伪IE下载 其他下载主要是“另存为” 土豆网https://www.sodocs.net/doc/fe9319583.html, Web视频 酷6 https://www.sodocs.net/doc/fe9319583.html, 6间房 https://www.sodocs.net/doc/fe9319583.html, 优酷https://www.sodocs.net/doc/fe9319583.html, Youtube https://www.sodocs.net/doc/fe9319583.html, HULU网https://www.sodocs.net/doc/fe9319583.html, 我乐网https://www.sodocs.net/doc/fe9319583.html, Sina视频https://www.sodocs.net/doc/fe9319583.html, Sohu视频 腾讯宽频 波波虎https://www.sodocs.net/doc/fe9319583.html, 其他Web视频 凤凰网https://www.sodocs.net/doc/fe9319583.html, CCTV点播https://www.sodocs.net/doc/fe9319583.html, Viewgood https://www.sodocs.net/doc/fe9319583.html, 常用协议 电子邮件 SMTP POP3 IMAP 终端类 VNC PCAnyWhere SSH Telnet 远程桌面 文件传输 FTP TFTP RSync 缺省端口873 NFS

CVS MSDS Microsoft-DS DNS DHCP NNTP SNMP NTP UPNP NETBIOS DAYTIME 端口为13 SYSLOG 缺省端口514 DECRPC LDAP NAT端口映射 网络管理 ISA控制协议 HTTPS Socks4/5 L2TP PPTP IPSEC GRE 网络安全 OpenVPN 360更新 Nod32更新 Windows更新 软件更新 卡巴斯基更新 流媒体协议 RTSP MMS QuickTime QuickTime 7 Windows MediaPlayer Windows MediaPlayer 11 Real Player Real Player 11 BBSee 1.3 磊客https://www.sodocs.net/doc/fe9319583.html, 新浪奥运视频 网易奥运视频 QQ奥运视频 CCTV央视高清 RTMP P2P下载 BitComet 2009.06.22 1.13 BT BitSpirit 2009.07.27 V 3.6.0.135

RTSP协议转换RTMP直播协议

RTSP协议转换RTMP直播协议 RTSP协议也是广泛使用的直播/点播流媒体协议，最近实现了一个RTSP协议转换RTMP直播协议的程序，为的是可以接收远端设备或服务器的多路RTSP直播数据，实时转换为RTMP直播协议，推送到FMS、Red5、wowza server等RTMP 服务器，以实现flash观看RTSP直播源的需求。程序同时也具备从FLV文件获取输入数据并转换RTMP直播。实现的思路分享如下。 要点分析 首先，程序的主要目的，是从多路RTSP输入源中提取AAC编码的音频和H.264编码视频数据，并生成RTMP数据包，然后组装RTMP推送协议，并发往RTMP 服务器。在发送的过程中，要求可以从RTSP数据源切换到具有相同h.264和aac 编码的FLV文件中，并不影响RTMP直播。因此，本程序的关键点有以下部分： 1.RTSP直播流的读取 2.H.264和AAC编码数据的分析、处理 3.FLV文件数据的提取及与RTSP直接的切换和衔接 4.RTMP数据包封装 5.RTMP推送协议 有了关键点，就可以一项一项的去分析。 设计思路 根据上面分析的要点，首先要选择RTSP直播协议的读取。我们不需要从零做起，网络上有很多和RTSP相关的开源项目可以使用或借鉴，我选择了Live555。 Live555是一个跨平台的流媒体解决方案，主要支持RTSP协议，好像也支持SIP（这个也是我马上研究的重点，之后会写文章研究SIP相关的技术实现）。Live555实现了RTSP包括服务器-客户端的整套结构，是很知名的一个开源项目。网上有很多关于Live555学习和使用的文章，我就不具体介绍了。

flex视频播放器(支持rtmp协议)开发代码

Flex视频播放器(支持rtmp协议)开发代码 开发工具:flash builder4.5 + red5服务器 建议参考之前阶段代码: (1)flex视频播放器开发初级阶段代码:https://www.sodocs.net/doc/fe9319583.html,/detail/ll_jj_yy/ (2)支持rtmp协议,播放red5服务器上的flv视频文件. 直接来代码:

RTSP协议转换RTMP直播协议

RTSP协议转换RTMP直播协议

RTSP协议转换RTMP直播协议 RTSP协议也是广泛使用的直播/点播流媒体协议，最近实现了一个RTSP协议转换RTMP直播协议的程序，为的是可以接收远端设备或服务器的多路RTSP 直播数据，实时转换为RTMP直播协议，推送到FMS、Red5、wowza server等RTMP 服务器，以实现flash观看RTSP直播源的需求。程序同时也具备从FLV文件获取输入数据并转换RTMP直播。实现的思路分享如下。 要点分析 首先，程序的主要目的，是从多路RTSP输入源中提取AAC编码的音频和H.264编码视频数据，并生成RTMP数据包，然后组装RTMP推送协议，并发往RTMP服务器。在发送的过程中，要求可以从RTSP数据源切换到具有相同h.264和aac 编码的FLV文件中，并不影响RTMP直播。因此，本程序的关键点有以下部分： 1.RTSP直播流的读取 2.H.264和AAC编码数据的分析、处理 3.FLV文件数据的提取及与RTSP直接的切换和衔接 4.RTMP数据包封装 5.RTMP推送协议 有了关键点，就可以一项一项的去分析。 设计思路 根据上面分析的要点，首先要选择RTSP直播协议的读取。我们不需要从零做起，网络上有很多和RTSP相关的开源项目可以使用或借鉴，我选择了Live555。 Live555是一个跨平台的流媒体解决方案，主要支持RTSP协议，好像也支持SIP（这个也是我马上研究的重点，之后会写文章研究SIP相关的技术实现）。Live555实现了RTSP包括服务器-客户端的整套结构，是很知名的一个开源项目。

网上有很多关于Live555学习和使用的文章，我就不具体介绍了。 H.264和AAC数据的分析处理，这个对于从没做过相关项目开发的人来说，应该是一个难点，主要是相关概念的理解。好在我一直在做这块，也比较好弄。 第4和第5点，可以参照文章“RTMP协议发送H.264编码及AAC编码的音视频（https://www.sodocs.net/doc/fe9319583.html,/haibindev/archive/2011/12/29/2305712.html），实现摄像头直播”的技术方法，来加以实现。因此，主要需要处理的就是RTSP 直播流数据的获取，以及对其中H.264和AAC编码数据的处理。 于是可以画出大体结构如下： RtmpThread的主要工作就是发送音频数据流的解码信息头和视频数据流的解码信息头，并不断从DataBufferQueue中取出数据，封装为RTMP Packet，发送出去。流程如下列代码所示：（process_buf_queue_，即是上图中的DataBufferQueue）

RTMP头RTMP协议封包 参考Red5

RTMP头RTMP协议封包参考Red5 RTMP协议封包由一个包头和一个包体组成,包头可以是4种长度的任意一种:12, 8, 4, 1 byte(s).完整的RTMP包头应该是12bytes,包含了时间 戳,AMFSize,AMFType,StreamID信息, 8字节的包头只纪录了时间 戳,AMFSize,AMFType,其他字节的包头纪录信息依次类推。包体最大长度默认为128字节,通过chunkSize可改变包体最大长度,通常当一段AFM数据超过128字节后,超过128的部分就放到了其他的RTMP封包中,包头为一个字节. 完整的12字节RTMP包头每个字节的含义: 用途大小(Byte)含义 Head_Type1包头 TiMMER3时间戳 AMFSize3数据大小 AMFType1数据类型 StreamID4流ID 一、Head_Type 第一个字节Head_Type的前两个Bit决定了包头的长度.它可以用掩码0xC0进行"与"计算: Head_Type的前两个Bit和长度对应关系： Bits Header Length 0012 bytes 018 bytes 10 4 bytes 11 1 byte Head_Type的后面6个Bit和StreamID决定了ChannelID。 StreamID和ChannelID对应关系：StreamID=(ChannelID-4)/5+1 参考red5 ChannelID Use 02Ping 和ByteRead通道 03Invoke通道我们的connect() publish()和自字写的NetConnection.Call() 数据都

RTMP协议

RTMP协议介绍 一．概述 RTMP是Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP 是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。 RTMP又是Routing Table Maintenance Protocol（路由选择表维护协议）的缩写。在AppleTalk 协议组中，路由选择表维护协议（RTMP，Routing Table Protocol）是一种传输层协议，它在AppleTalk 路由器中建立并维护路由选择表。RTMP 基于路由选择信息协议（RIP）。正如RIP 一样，RTMP 使用跳数作为路由计量标准。一个数据包从源网络发送到目标网络，必须通过的路由器或其它中间介质节点数目的计算结果即为跳数。 RTMP(Real Time Messaging Protocol)实时消息传送协议是Adobe Systems公司为Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。 它有多种变种： 1)RTMP工作在TCP之上，默认使用端口1935； 2)RTMPE在RTMP的基础上增加了加密功能； 2)RTMPT封装在HTTP请求之上，可穿透防火墙； 3)RTMPS类似RTMPT，增加了TLS/SSL的安全功能； 二．协议介绍 RTMP协议(Real Time Messaging Protocol)是被Flash用于对象,视频,音频的传输.这个协议建立在TCP协议或者轮询HTTP协议之上. RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据. 一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的. 网络连接(Connection)

Rtmp协议中文介绍

RTMP（real time messaging protocol）协议 1，介绍 这篇文档详细说明了RTMP消息块流，它位高层多媒体流协议提供多路技术和包服务 RTMP消息块流是为RTMP协议设计的，他可以处理任何传送消息流的协议，每一个消息包含时间戳合有效负载类型标示，RTMP消息块流和RTMP一起适用于多样性音视频应用程序，从一对一和一对多向视频点播服务器直接广播到交互式会议应用程序。 当用到实时传输协议就像TCP，RTMP消息块流提供可靠地规则时间戳的端到端全信息传送。穿过多层流，RTMP消息块流不提供任何控制的优先级别和相似形式，但是可以用于高层协议提供这样的优先级，例如：一段实时视频服务会选择丢弃给于缓慢的客户的视频信息确保音频信息可以及时被接收。 RTMP消息块流包含它自己的入队协议控制消息，也提供一个高层协议机制用于嵌入用户的控制消息。 2.定义 有效负载： 包含在包中的数据，就像音频样本或者压缩的视频数据。 包： 一个数据包由固定的包头和有效负载数据组成，一些底层协议或许需要包的封装来被定义。 端口： 在TCP/ＩP协议中定义的用正整数表示的端口号用于在传输中提取以区分目标主机的不同应用，用于OSI传输层的传输选择（TSEL）就是端口。 传输地址： 网络地址和端口的组合识别一个传输层终端端口，例如一个IP地址和TCP端口，数据包从一个源传输层地址传送到目标段的传输层地址。 消息流： 一个通信的逻辑通道，允许消息流通。 消息流ID： 每一个消息拥有一个分配的ID识别跟随的消息流。 消息块： 消息的片段，消息被分成小的部分，在他们在网络中发送之前交叉存储。消息块确保定制时间戳的端到端全消息传送，穿过多层流。 消息块流： 一个通信的逻辑通道，允许消息块在一个特定的方向上流通，消息块流可以从客户端传送到服务器，也可以相反。 消息块流ID： 每一个消息块有一个分配的ID用于识别更随的消息块流。 复合技术： 把分开的音视频数据组合成一条音视频流的过程，使同时传送许多音视频数据成为可能。 逆复合技术： 复合的反向过程，交叉存取组装的音频视频数据，使他们成为最初的音视频数据 3．字节顺序，列队和时间格式 所有的整数字段有被网络字节负载着，字节0是第一个显示出来的，也是一段文字和字段中最重要的。 这种字节顺序一般被认为“大字节“，数字常量在这种文档里是用十进制表示。 所有RTMP消息块流是以用字节列队，例如：一个16字节的字段也许会在字数字节的偏移段。那里要填充被标示，填充字节应该有0值（似乎看不懂）. 在RTMP消息块流中的时间戳用整数表示，单位为毫秒。每一个消息块流以时间戳0开始，但是这不是必须的，只要两个终端在时间点上达成一致，注意那就意味着任何穿过多消息块流异步传输（特

rtp协议,端口

竭诚为您提供优质文档/双击可除 rtp协议,端口 篇一：实时传输协议Rtp 实时传输协议Rtp 1.Rtp协议： Rtp（Real-timetransportprotocol）协议最初是在70 年代为了尝试传输声音文件，把包分成几部分用来传输语音，时间标志和队列号。经过一系列发展，Rtp第一版本在1991年8月由美国的一个实验室发布了。到本世纪1996年形成 了标准的的版本。很多著名的公司如netscape,就宣称“netscapelivemedia”是基于Rtp协议的。microsoft也宣称他们的“netmeeting”也是支持Rtp协议. Rtp被定义为传输音频、视频、模拟数据等实时数据的 传输协议。最初设计是为了数据传输的多播，但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。Rtp与辅 助控制协议Rtcp一起得到数据传输的一些相关的控制信息。 2．Rtp协议的工作原理：

如上所说明的，影响多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。Rtp协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。 在流的概念中‘时间标签’是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始 的适时的数据。不同的媒体格式调时属性是不一样的。但是Rtp本身并不负责同步，Rtp只是传输层协议，为了简化了 运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。Rtp报文甚至不包括长度和报文边界的描述。同时Rtp协议 的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。 Rtp协议和udp二者共同完成运输层协议功能。udp协 议只是传输数据包，是不管数据包传输的时间顺序。Rtp的 协议数据单元是用udp分组来承载的。在承载Rtp数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而udp的多路复用让Rtp 协议利用支持显式的多点投递，可以满足多媒体会话的需求。

RTMP协议详解

Real Time Messaging Protocol（实时消息传送协议协议)是Adobe Systems 公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。 具体使用RTMP的AS代码大概如下： 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"); Adobe也在官方网站已经提供了RTMP协议的官方文档说明，为什么要写这个系列文章最大的原因只是对前一段工作的一个总结和回顾，最近两个月，实现了一个RTMP Server的c++版本，把公司的流媒体服务和flash无缝对接起来。希望我的文字能给后来研究这个协议的同学有一定的帮助。 RTMP协议是一个基于TCP的高层协议族，当然这个玩意据说还有UDP协议版本的，不过现在还没有出来，好像Adobe下一版本的FMS会提供支持。下文将要描述的是TCP协议版本的协议。 RTMP协议的概要理解： RTMP协议是为了和flash之间交换信令以及媒体数据。为了提高使用效率信令和媒体数据都是使用相同的机制。因为是相同的机制Adobe就整出来了一些比较搞人的概念，当然每个协议第一次接触都是比较难理解的。 在RTMP协议中信令和媒体数据都称之为Message，在网络中传输这些Message，为了区分它们肯定是要加一个Message head的，所以RTMP协议也有一个Message head，还有一个问题因为RTMP协议是基于TCP的，由于TCP的包长度是有限制的（一般来说不超过1500个字节），而RTMP的Message长度是有可能很大的，像一个视频帧的包可能会有几十甚至几千K，这个问题就必然有一

RTMP协议简介

专题报告：RTMP 协议

目录 专题报告：RTMP协议 (1) 一：什么是rtmp (3) 二：RTMP消息格式 (5) 三：RTMP握手过程 (10) 三．协议控制消息 (21) 四：消息交换的例子 (25)

写在前面红色字体是重点必读，蓝色字体是分点便于区分，绿色字体是次分点便于区分一：什么是rtmp

RTMP协议 Real Time Messaging Protocol（实时消息传送协议协议)实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。它有三种变种： 1)工作在TCP之上的明文协议，使用端口1935； 2)RTMPT封装在HTTP请求之中，可穿越防火墙； 3)RTMPS类似RTMPT，但使用的是HTTPS连接； 介绍: RTMP协议是被Flash用于对象,视频,音频的传输.该协议建立在TCP协议或者轮询HTTP协议之上. RTMP协议就像一个用来装数据包的容器,这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据. 一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的. RTMP中定义了两种通信单元：消息（message）和消息块（chunk）.RTMP消息是协议中实现各种流媒体控制和应用的基本逻辑信息单元，消息从种类上可以分为协议控制消息、用于发送音频数据的音频消息、用于发送视频数据的视频消息、发送用户数据的数据消息、共享对象消息以及命令消息，属于相同逻辑通道的消息组成一个消息流，这个逻辑通道通过消息格式中的“消息流ID”字段来标识。 作为应用层协议，RTMP协议架构在TCP层之上，但RTMP消息并不是直接封装在TCP中，而是通过一个被称为消息块的封装单元进行传输。消息在网络上发送之前往往要分割成多个较少的部分，这些较小的部分就是消息块，属于不同消息流的消息块可以在网络上交叉发送。这样做可以保证各个消息流中的高优先级消息块能够严格按照时间顺序达到通信的对端。比如某个较长消息的实时性要求比较低，如果不进行消息块处理，等长消息都发送完毕后再发送实时性要求高的短消息，则会对流媒体的播放质量造成影响。