linuxrtmp服务器搭建

❶ Mac搭建Nginx流媒体服务器，进行推流，拉流

Nginx 是非常优秀的开源服务器，用它来做hls或者rtmp流媒体服务器是非常不错的选择

下面介绍如何在Mac上搭建流媒体服务器，以便后续的自己研究的项目或者demo向服务器上进行推流

首先需要安装brew，brew是一款管理软件的第三方平台，安装的方式也很简单，请自行查阅安装方式

执行下面2句命令，即可安装rtmp推流的nginx服务器

执行完后，可以查看ngix安装在哪里

可以看到M1 是安装在这个目录下/usr/local/etc/nginx

打开这个目录，可以看到有个nginx.conf文件，这里就是服务器的一个配置文件，如果支持rtmp，则里面的内容会有一个rtmp的json

这个json说明：

1.你本地的nginx服务器会监听1935端口号，

2.服务器会创建一个mytv的程序

后续你可以向这个地址进行推流，并且进行拉流播放

后面我们会使用ffmpeg向这个地址推流
rtmp://localhost:1935/mytv/room

并且用vlc拉取这个地址的流进行播放

执行命令，即可启动nginx服务器

验证是否启动成功，只需要在浏览器中访问下以下链接

在浏览器地址栏输入： http://localhost:8080

出现Welcome to nginx ,代表nginx安装成功了。

打开配置文件 /usr/local/etc/nginx/nginx.conf

这里推的是flv流，可以正常推，这里需要注意的是服务器地址一定要写正确，我的nginx.conf里application配置的是mytv,所以路径就是mytv,room则是随便写都行，代表向程序mytv下的room文件推流

然后电脑上打开vlc这个播放器软件 点击File---->Open Network 在弹出来的框中选择Network然后输入URL:

验证时，推流的文件最好搞大点，不然一下推完了，你才去拉取播放，则播放不了，因为这是实时的

vlc使用如下

3.点击播放即可

可以看到左边是画面，右边是ffmpeg在推流

参考： https://www.jianshu.com/p/cf74a34af15d

❷ 如何在linux操作系统下搭建配置流媒体服务器系统

在Linux操作系统下搭建配置流媒体服务器系统方法详见：https://jingyan..com/article/0eb457e5c8f69303f1a905b3.html

❸ 如果要搭建一个直播平台，直播开发平台中都会用到哪些接口

先，服务器，是最基本的，也是最重要的，系统只有搭建在服务器上才能运作。前期基本的服务器建议阿里云或者腾讯云或者其他支持rtmp协议的服务器，推荐4核8G2M带宽，系统linux cent os7.x（一般为最新的7.6）可支持前期基本运营，后期可根据在线人数升级服务器。

域名：域名一般建议使用运营者自己实名备案的，如果是购买的别人的，在运营中可能会掉，域名掉了，APP也就访问不了了。只有把域名解析到服务器上，网络才能找到你的。也是必需的

短信验证码：登录验证，市场上很多的验证码提供商，价格也是很便宜。

其他登录方式，如微信快捷登录，QQ登录等，需要开通QQ互联及微信开放平台的授权。

充值支付：最为常见的就是微信支付和支付宝支付，这两种方式都需要用到公司资质也就是营业执照，微信支付，需要在微信开放平台申请微信支付的商户号，（微信公众号不可）审核费用，每年300元。账期需要看自己的APP种类，一般分为T+1和T+7等，具体的可以咨询微信官方。支付宝支付是免费的，需要获取开发者能力，配置相关的参数，回调等。其他的三方支付，需要提供三方支付的接口，及文档等信息。不过一般不建议三方支付，有丢单的情况。

腾讯云账号：腾讯云在社交方面还是很强大，现在大部分的社交APP还是集成了腾讯的SDK。腾讯的产品首次使用会有一段时间的免费试用，试用过后就需要付费了。

美颜：市面上也是有很多的美颜商家，提供专业 美颜服务，具体的可以和APP开发商商议。

任何一款直播平台开发都会用到很多的技术，开发商也是一样，会在一套APP内集成多个三方的SDK。在各个领域都有专业的服务商，如果全套的服务都是自己开发，受众面稳定及兼容性也是非常难以做到最完美的，全部自研的成本将会无限提高。

做直播平台，关键是看个人怎么运营，怎么能增加用户的粘性，让用户能够可以持续给平台提供资金流，优质的主播是必不可少的，但是平台的运营策略和推广力度也会起到至关重要的作用。

❹ 我有一台win2012的服务器，想自己搭建一个rtmp的直播服务器，请问需要什么软件

这两天我就在试玩Adobe Media Server 5 extend，流媒体服务所用的环境就是一台win7 64位旗舰版的i5 2.4GHz、4G内存Dell笔记本，3个独立IP的测试发布终端（Wirecast、Adobe live media encoder、Matrox MonarchHD）都以RTMP协议往服务器中发布直播流，除了MonarchHD因为只具有有线接入外，全部设备包括AMS所在的笔记本都用无线AP接入一个局域小网。其中MonarchHD publish给笔记本中安装的AMS推送一个2M码流的1920x1080 i50 H.264直播流，用各种接收终端接收流都很清晰流畅

我的服务器用的是小鸟云的，很稳定，流畅。

❺ linux怎么启动 ams服务

时间:2016-03-23来源:linux网站 作者:meteorite91

最近需要使用rtmp服务器，在red5和AMS之间选择了AMS来搭建，说先说明一下AMS全称是adobe media server，在5.0版本之前名称是FMS（flash media server）。

搭建的环境：64位的centos6.5,PS:AMS只支持64位的系统，不管是windows还是Linux都只有64位，安装之前要安装好64位的Linux环境。

在http://www.adobe.com/support/flashmediaserver/downloads_updaters.html下载5.0.3版本的源码包，在centos切换root权限，解压，进入AMS_5.0.3_r3029目录，运行./installAMS，后面根据提示按enter等键即可，需要注意的是在提示输入IP的时候最好使用自己想用的IP而不是自动检测，默认的端口是1935和1111，其他都可以默认执行。

❻ linux apache 怎么安装rtmp

一，目标: 利用开源或者免费工具实现一个直播系统；同时支持在浏览器、播放器和嵌入到 PC 应 用或者移动 APP 中观看直播。 二，技术选型: 视音频源端:： Adobe Flash Media Live Encoder 3.2，可以在 windows 和 mac 安装； 如果你已有一些支持 RTMP 的采集设备，那是最好了； 或许你想在自己的应用中实现，这样你就必须自己开发处理采集，编码和协议传输了(以后 再表)； RTMP Server： FMS -- Adobe 公司出品的服务器，价格昂贵，当然是最正宗的，因为 RTMP 就是 Adobe 公 司的私有协议； Wowza -- 同样需要授权费， 大概是$55 per month/instance，效率和稳定性都还不错； Red5 -- 一个开源实现， 效率和稳定性都稍微差些，由于它是 java 实现的，所以天生支持 跨平台运行； Nignx-rtmp-mole - -nginx 的一个第三方模块，如果你熟悉 nginx 那是不错的选择，当然它 也是免费的，不过功能就没有其他几个丰富了； 这里我选择 nginx+nginx-rtmp-mole 作为服务器，这是我认为最容易上手的一种方式了(如 果 你 把 windows 作 为 服务 器 那 可 能 麻烦 些 ， 官 方 提供 的 windows 二 进 制版 本 是 没 有 nignx-rtmp-mole 的

❼ 直播系统源码是如何实现视频直播以及直播系统搭建的

一、手机直播系统源码开发实现视频直播主要有以下四步：
1）前端采集编码设备：提供直播信号源的采集和编码压缩功能，并将信号推送到直播流媒体服务器上。
2）直播流媒体服务器：负责直播流的发布和转播分发功能。
3）WEB服务器：实现直播节目在终端上的展现。
4）终端设备：包括PC和移动终端。编码和协议 是实现直播的重要环节：1）网络协议：主要有3种 a. RTSP（Real Time Streaming Protocol）是用来控制声音或影像的多媒体串流协议, 由Real Networks和Netscape共同提出的；b. RTMP(Real Time Messaging Protocol):实时消息传送协议是Adobe公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议；c. HLS(HTTP Live Streaming):是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议； 2）视频编码: Mpeg4, H264等 3）音频编码: Mp3, AAC等4）视频分辨率: 标清通常指的是640×480（或768×480）；高清指的是1280×720；全高清指的是1920×1080；超高清3840×2160。
二、直播系统源码搭建服务器部署重点
直播系统源码有哪几块组成，视频直播的过程一般可以分为采集、前处理、编码、传输、解码、渲染这几个环节，经过这几个环节之后，我们就可以通过PC端或者移动端进行视频直播的观看。直播系统在搭建时会用到多个业务服务器，共同完成直播系统的业务逻辑流程。通常在服务器部署时会采用动静分离分布式部署方式，保障了直播平台的稳定运行。主要用到以下的业务服务器。
1）消息服务器：主要用于消息推送，给用户推送房间聊天消息、私信消息。
2）业务服务器：手机直播的业务部分、好友关系、直播管理、货币系统、礼物系统等。
3）视频服务器：视频直播、点播、转码、存储和点播等。
4）IM即时聊天：使用Node.js服务自主搭建部署聊天服务器。
5）视频流（流媒体服务器）：建议采用第三方CDN，开通账号即可使用。关于CDN方面的内容，我们会在以后的内容中做重点介绍。
6）业务服务器：网站逻辑基于php-tlinkphp、thinkcmf、mysql、redis。MYSQL 服务提供静态数据的存储，REDIS 服务提供数据的缓存、存储动态数据。
以上便是对直播系统源码如何实现视频直播以及搭建服务器的简单介绍。搭建直播开发平台之前就是找到一款优质的直播系统源码，直播系统源码开发原理比其他软件更加复杂，而且相对于技术以及其他方面都会有一定的要求。直播系统源码的稳定性和安全性决定了后期搭建出的直播平台的流畅度、高并发承载及用户的产品体验，所以选择直播源码的时候一定不要为了贪图价格便宜，而选择安全性低，系统功能不会正常更新，bug一堆的源码。直播系统源码的开发需要经过推流端(采集、前处理)、服务端处理(编码、转码、录制、截图、鉴黄)、播放器(拉流、解码、渲染和互动系统)。望采纳，谢谢

❽ nginx-rtmp模块简介

1:  Mole Configuration Struct(s)模块配置结构

这个结构的命名规则为ngx_http_[mole-name]_[main|srv|loc]_conf_t。

main,srv,loc表示这个模块的作用范围是配置文件中的main/server/location三种范围（这个需要记住，后面会经常用到）

2: Mole Directives模块命令结构

static ngx_command_t ngx_http_echo_commands[] = {

{

ngx_string("echo"), //命令名字

NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1, //代表是local配置，带一个参数

ngx_http_echo, //组装模块配置结构

NGX_HTTP_LOC_CONF_OFFSET, //上面的组装模块配置获取完参数后存放到 哪里？使用这个和下面的offset参数来进行定位

offsetof(ngx_http_echo_loc_conf_t, ed), //同上 

},

ngx_null_command //必须使用ngx_null_command作为commands的结束标记

};

3: The Mole Context模块内容

static ngx_http_mole_t   ngx_http_circle_gif_mod ule_ctx

主要是定义了一些钩子函数, nginx会在不同时期会调用

4: The Mole Definition模块整合

ngx_mole_t ngx_http_<mole name>_mole = {

NGX_MODULE_V1,

&ngx_http__mole_ctx, /* mole context模块内容 */

ngx_http__commands, /* mole directives模块命令*/

NGX_HTTP_MODULE, /* mole type模块类型，HTTP模块，或者HTTPS*/

5: Mole Installation模块安装

1: ngx_rtmp_live_mole

直播模块:推拉流同点, 不涉及回源

2: ngx_rtmp_relay_mole

中继模块:  1:回源pull  2: 转推: push

一:  建立rtmp连接, 需要握手

      1: ngx_rtmp_handshake_recv()开始握手

      2: NGX_RTMP_HANDSHAKE_DONE()握手完成

      3: ngx_rtmp_cycle()重新设置读写handler

二:  建立网络连接

    建立rtmp连接之后, ngx_rtmp_recv函数会利用ngx_event_t结构会获取推送过来的原始数据, 接受到的数据会存放到ngx_rtmp_stream_t的in链表结构中.

1:接受chunk数据

2:分析处理chunk数据, 如果message还没接受完, 继续接受数据

3:将chunk组成一个rtmp message, 然后交给ngx_rtmp_receive_message处理, 这个函数根据消息的类型找对应的handle

三:  建立网络流

        在建立网络连接后,就需要建立网络流了, 网络流代表了发送多媒体数据的通道. 服务器和客户端只能建立一个网络连接, 且多个网络流可以复用这一个网络连接

1: ngx_rtmp_recv接受数据后交给ngx_rtmp_receive_handler, 它会根据类型区别处理, 此时客户端发送ngx_rtmp_msg_chunk_size类型的消息

2:接受message后跳转到处理函数ngx_rtmp_amf_message_handler. 处理客户端发送的amf控制消息. 此时连续接受3个amf数据.

3:调用ngx_rtmp_cmd_create_stream_init初始化网络流. 利用ngx_rtmp_receive_amf获取接受的amf数据.

4:调用ngx_rtmp_cmd_create_stream创建网络流, 利用ngx_rtmp_send_amf向客户端发送amf控制消息

四:  传输媒体数据

在客户端和服务端建立网络流之后,接下来就可以传输媒体数据了, 一般来讲, 媒体数据分为两部分, 一部分为meta元信息, 另一部分是音视频数据, 首先传送的是meta元信息. 然后推送媒体. 服务器处理如下:

1:从客户端接受amf命令信息, 然后服务端会利用ngx_rtmp_cmd_publish_init来初始化发布环境.  函数功能: 会读取刚接受端amf信息

2:利用ngx_rtmp_auto_push_publish, ngx_rtmp_notify_publish, ngx_rtmp_exec_publish建立发布环境,

3:如果conf配置了record命令记录媒体文件, 此时会调用ngx_rtmp_record_publish来初始化记录环境;

4:执行ngx_rtmp_access_publish;

[if !supportLists]l [endif]meta信息:

5:接受客户端amf, 并调用ngx_rtmp_codec_meta_data获取meta元信息;

6:结合服务器的参数, 利用ngx_rtmp_codec_reconstruct_meta接口重构meta元信息, 并调用ngx_rtmp_prepare_message组成消息保存

[if !supportLists]l [endif]媒体数据:

7:接受客户端推送, 根据类型转到ngx_rtmp_codec_av来处理音视频数据; 其中利用函数ngx_rtmp_codec_parse_avc_header来处理头部信息

8:调用record模块记录数据, 接口为ngx_rtmp_codec_av;

9:调用live模块来广播发布数据, 接口为ngx_rtmp_live_av, 广播到所有观察者, 第一次调用接口ngx_rtmp_live_start创建广播, 之后直接调用ngx_rtmp_append_shared-bufs

 

rtmp 的 信令交互图:

1: 播放器端发起play

2: ngx_rtmp_relay_play()

3: ngx_rtmp_relay_pull() --主要建立pull请求, 将远程拉流的上下文和本地上下文放到链表中

    ngx_rtmp_relay_create_local_ctx()创建本地上下文

    ngx_rtmp_relay_create_remote_ctx()创建远端上下文

4: ngx_rtmp_relay_create_remote_ctx详解:  创建远端session, 开始rtmp信令交互

       1: ngx_rtmp_relay_create_connection  

        2: ngx_rtmp_init_session

注意:此时session中的flashver为“ngx-local-relay“

5: rtmp信令交互流程

核心函数: ngx_rtmp_relay_on_result主要用来接收对端服务端发送的amf消息包，而后按正常rtmp协议请求进行下一步交互，这个主要是当前服务端做为客户端发起远程rtmp请求流程

例如:   ngx_rtmp_client_handshake(发起握手)

         握手完成后调用回调函数: ngx_rtmp_relay_handshake_done

       ngx_rtmp_relay_send_connect:发起连接请求, 接着参考rtmp信令交互图

        核心功能:向nginx推送一个直播流，该直播流经 nginx-rtmp 的 ngx_rtmp_live_mole 模块转发给 application live 应用，然后使用vlc连接 live，播放该直播流。本质上就是1对多的广播

参考: http://nginx.org/en/docs/debugging_log.html

1: Nginx-rtmp-mole模块源码学习

https://blog.evanxia.com/2017/02/1264

2: nginx_rtmp_relay_mole模块解读

https://www.shangmayuan.com/a/d74b78669f804fb5b12cae5a.html

3:开发手册中文版:包含指令介绍

https://blog.csdn.net/ai2000ai/article/details/55517992

❾ Android平台FFmpeg实现rtmp推流-C++的实现

视频编码有几种方式：
1.硬编码，使用MediaCodec实现
2.软编码，使用FFmpeg或者libx264库来实现。

本文分享在Android平台视频编码-软编码的实现，也就是用FFmpeg来实现视频的编码，rtmp推流到服务器上，相机采集视频将在下一篇文章分享。

流媒体服务器使用 nginx-rtmp-mole 来进行搭建。

本文所使用FFmpeg的版本是4.1，关于FFmpeg编译成Android平台so库如果有需要，我将在下一篇文章分享说明。

视频编码比较耗cpu，上传视频数据的会耗网络io，所以需要开启新线程去处理，这里我用HandlerThread来处理视频的编码上传。

初始化编码相关操作
这里我们使用的是FFmpeg,所以在编码前我们会先做一些初始化以及参数设置工作。
FFmpeg初始化
av_register_all()
创建输出格式上下文
avformat_alloc_output_context2()
获取编码器
avcodec_find_encoder(AV_CODEC_ID_H264) 获取H264的编码器
设置编码器参数

使用给定的编码器和参数初始化编码上下文
avcodec_open2(pCodecCtx, pCodec, ¶m)
创建视频流
video_st = avformat_new_stream(ofmt_ctx, pCodec)
打开输出上下文
avio_open(&ofmt_ctx->pb, out_path, AVIO_FLAG_READ_WRITE)
写入输出头信息
avformat_write_header(ofmt_ctx, NULL)

像素格式转换
AV_PIX_FMT_YUV420P，它是纯平面存储。总共三个平面，分别存放，Y、U、V数据。
当图像宽是width，高是height时，Y分量的大小就是width×heitht,而U是width×heitht/4,V也是U是width×heitht/4。
H264编码
首先我们需要了解两个数据结构AVFrame、AVPacket
AVFrame存放的是原始数据、AVPacket存放的是编码后的数据。
创建AVPacket
av_new_packet(&enc_pkt, picture_size);
开始编码
ret = avcodec_encode_video2(pCodecCtx, pFrameYUV);
输出一帧编码后的视频数据
ret = av_write_frame(pCodecCtx, &enc_pkt);

释放资源

小伙伴们有疑问的可以在下方评论区评论。

❿ rtmp规范1.0全面指南

RTMP（real time messaging protocol）协议

本文为Adobe rtmp规范1.0的中文介绍，其中内容大部分都是翻译自rtmp官方文档 rtmp_specification_1.0.pdf

Adobe的实时消息传输协议（ RTMP ）通过可靠的流传输（如 TCP [RFC0793] ）提供双向消息多路传输服务，用于在端到端之间传输带有时序信息的视频，音频和数据消息的并行流。 穿过多层流， RTMP 消息块流不提供任何控制的优先级别和相似形式，但是可以用于高层协议提供这样的优先级，例如：一段实时视频服务会选择丢弃给缓慢的客户的视频信息确保音频信息可以及时被接收。 RTMP消息块流 包含它自己的入队协议控制消息，也提供一个高层协议机制用于嵌入用户的控制消息。

有效负载：Payload

包含在包中的数据，就像音频样本或者压缩的视频数据。

包：Packet

一个数据包由固定的包头和有效负载数据组成，一些底层协议或许需要包的封装来被定义。

端口：Port

在 TCP/IP 协议中定义的用正整数表示的端口号用于在传输中提取以区分目标主机的不同应用，用于 OSI 传输层的传输选择（ TSEL ）就是端口。

传输地址：Transport address

网络地址和端口的组合识别一个传输层终端端口，例如一个IP地址和TCP端口，数据包从一个源传输层地址传送到目标段的传输层地址。

消息流：Message stream

一个通信的逻辑通道，允许消息流通。

消息流ID：Message stream ID

每一个消息拥有一个分配的ID识别跟随的消息流。

消息块：Chunk

消息的片段，消息被分成小的部分，在他们在网络中发送之前交叉存储。消息块确保定制时间戳的端到端全消息传送，穿过多层流。

消息块流：Chunk stream

一个通信的逻辑通道，允许消息块在一个特定的方向上流通，消息块流可以从客户端传送到服务器，也可以相反。

消息块流ID：Chunk stream ID

每一个消息块有一个分配的ID用于识别更随的消息块流。

复合技术：Multiplexing

把分开的音视频数据组合成一条音视频流的过程，使同时传送许多音视频数据成为可能。

逆复合技术：DeMultiplexing

复合的反向过程，交叉存取组装的音频视频数据，使他们成为最初的音视频数据

远程过程调用：Remote Procere Call (RPC)

允许客户端或服务器在对等端调用子例程或过程的请求。

Action Message Format (AMF)

一种紧凑的二进制格式，用于序列化 ActionScript object graphs 。 可以透过 AMF overHTTP 的方式将 flash 端资料编码后传回server，server端的 remoting adaptor 接收到资料后则会译码回正确的 native 对象，交给正确的程序处理。

所有的整数字段都被引入到了字节顺序当中，字节0是第一个显示出来的，也是一个词和一个字段中最重要的。这种顺序就是通常所说的“大端”。如果没有特殊说明，在本文档中数字常量都是用十进制表示。

除另有规定外， RTMP 中的所有数据都是字节对齐的。例如，一个16位字段可能处于奇数字节偏移处。 在指定填充的地方，填充字节应该是0。

RTMP 中的时间戳相对于未指定的时期是以整数毫秒为单位给出的。 通常，每个流将以时间戳0开始，但这不是必需的，只要两个终端在时间点上达成一致。 请注意，这意味着跨多个流（尤其是来自不同主机）的任何同步都需要一些 RTMP 外的其他机制。

时间戳必须始终在线性的增加，允许应用程序处理异步传输，带宽度量，检测，和流控制。

由于时间戳长度为32位，因此它们每隔49天，17小时，2分钟，47.296秒滚动一次。 由于流可以连续运行，可能持续数年， RTMP 应用程序应该在处理时间戳时使用序列号算法 [RFC1982] ，并且应该能够处理回绕。 例如，假定所有相邻的时间戳都在 2^31 - 1 毫秒之间，所以10000会在4000000000之后，而3000000000会在4000000000之前。

时间戳增量delta也被指定为相对于先前时间戳的无符号整数毫秒数。 时间戳增量delta可以是24位或32位。

本节介绍实时消息传送协议块流（ RTMP块流 ）。 它为更高级别的多媒体流协议提供复用和打包服务。 虽然 RTMP Chunk Stream 旨在与实时消息传送协议配合使用，但它可以处理发送消息流的任何协议。 每条消息都包含时间戳和有效负载类型标识。 RTMP Chunk Stream 和 RTMP 一起适用于各种音频 - 视频应用，从一对一和一对多实时广播到视频点播服务，再到交互式会议应用。

当与可靠的传输协议（如 TCP [RFC0793] ）一起使用时， RTMP块流 提供了保证所有消息在多个流中按时间排序的端到端传送。 RTMP块流 不提供任何优先级或类似的控制形式，但可以由更高级别的协议提供这种优先级。

可以拆分成块以支持复用的消息格式取决于更高级别的协议。 但是，消息格式应该包含下列创建块所必需的字段。

时间戳：

消息的时间戳，这个字段可以传输4个字节。

长度：

消息的有效负载的长度，如果消息头不能被省略，它应该包含在长度中，这个字段在消息块包头中占有3个字节。

类型ID：

协议控制消息的类型字段的范围是被保留的，这些传播信息的消息由 RTMP消息块 和高层协议处理，所有其他的类型ID可被高层协议使用，对 RTMP消息块 来说当做不透明的值，实际上， RTMP Chunk Stream 中的任何内容都不需要将这些值用作类型; 所有（非协议）消息可以是相同类型的，或者应用程序可以使用类型id来区分同步踪迹而不是类型。 该字段占用块头中的1个字节。

消息流ID:

消息流ID可以是任意的值。 复合到相同块流上的不同消息流可以基于它们的消息流ID进行逆复合操作。 除此之外，就 RTMP 块流而言，这是一个不透明的值。 该字段以小尾数格式占用块头中的4个字节。

RTMP 连接始于握手。 rtmp 握手与其他协议的握手不同; 它由三个相同大小的块组成，而不是由可变大小的块组成。

客户端（连接已初始化的终端）和服务器都发送相同的三个块。 为了说明，由客户端发送的3个块分别为 C0 , C1 , C2 ，由服务端发送的3个块分别为 S0 , S1 , S2 。

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

C0 和 S0 都是单个8位字节，可以看成一个8位整形字段。

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

C1 和 S1 包长度为1536个8位字节，包含以下字段：

time（4个字节） ：这个字段包含时间戳，被当做后续消息块从终端发送的时间点，也许是0，或者一些任意的值。为了同步多路消息块流，终端或许希望发送其他消息块流的时间戳的当前值。

zero（4各个字节） ：这个字段必须全0。

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

C2 和 S2 包长度为1536个8位字节，分别类似于 S1 和 C1 的原样返回，由一下几个字段组成：

time（4个字节） ：

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

time2（4个字节） ：

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

random echo（1528个字节） ：

这个字段必须包含在对端发送的 S1 （对应 C2 ）或 S2 （对应 C1 ）数据包中的随机数据字段。 任何一方都可以使用 time 和 time2 字段与当前时间戳一起快速估算连接的带宽和/或延迟，但这不太可能有用。

下面的表格描述了握手过程的几个阶段

握手后，连接复用一个或多个消息块流。每个块流从一个消息流携带一种类型的消息。每个创建的块都有一个与其关联的唯一ID，称为块流ID。这些块通过网络传输。发送时，每个块必须在下一个块之前全部发送。在接收端，根据块流ID将块组合成消息。

分块允许将较高级别协议中的大的型消息分解为较小的消息，例如防止较大的低优先级消息（例如视频）阻塞较小的高优先级消息（如音频或控制）。

分块还允许以较少的开销发送小消息，因为分块头包含信息的压缩表示信息，这些压缩消息本来应该包含在消息本身的。

块大小是可配置的。它可以使用 Set Chunk Size 控制消息进行设置。

每一个消息块有头部和数据组成，头部自身可以被分割成三个部分：

消息块基本头（1到3个字节） ：这个字段编码了消息块流的ID和消息块的类型，消息块类型决定了消息包头的编码格式，长度完全取决于可变长的消息块流ID。

消息块消息头（0,3,7或11字节） ：这个字段编码正在传送的消息的信息，长度可以利用在消息块头中详细的消息块类型来决定。

扩展时间戳（0或4字节） ：此字段在某些情况下是存在的，取决于消息块消息头中的编码时间戳或时间戳增量字段。

消息块块数据（可变大小） ：该块的有效负载，直至配置的最大块大小。

消息块基本头对消息块流的ID和消息块的类型进行编码（在下面的图表中用 fmt 表示），消息块类型决定了编码的消息头的格式，消息块基本头字段可以是1,2或者3个字节长，取决于消息块流ID。

该协议支持多达65597个ID为3-65599的流。 ID0,1和2被保留。 值0指示2字节形式和64-319范围内的ID（ the second byte + 64 ）。 值1表示3字节形式，ID在64-65599（ (the third byte) * 256 + the second byte + 64 ）范围内。 在3-63范围内的值表示完整的流ID。 块ID为2的流ID保留，用于低级别的协议控制消息和命令。

在消息块基本头中0-5比特(最不重要的)代表了消息块流ID。

消息块流ID 2-63 可以被编码成这个字段的单字节的版本号。

块流ID 64-319可以以2字节的形式被编码。 ID计算为（第二个字节+ 64）。

可以在此字段的3字节版本中对块流ID 64-65599进行编码。 ID计算为（（第三字节）* 256 +（第二字节）+64）。

cs id（6比特） ：这个字段包含了消息块流ID，值从2到63，值0和1用于代表这个字段的2个或者3个字节的版本号。

fmt（2比特） ：这个字段标识消息块消息头使用的四种格式之一。见下一小节

cs id -64（8或者16个比特） ：

这个字段包含了消息块流ID减64，例如ID 365在 cs id 段用1表示，在16比特的 cs id -64 段用301表示。

值为64到319的消息块流ID可以被2字节或者3字节的版本号来表示。

在消息块消息头中有四种不同的格式，由消息块基本头的 fmt 字段选择。应该使用最简洁的表达方式表示每一个消息块消息头。

类型0的消息块有11个字节长，这个类型必须在消息块流开始时和消息流的时间戳回溯时使用

时间戳（3个字节） ：对于类型0的块，消息的绝对时间戳发送到此处。 如果时间戳大于或等于16777215（十六进制 0xFFFFFF ），则该字段必须是16777215，表示存在扩展时间戳字段以编码完整的32位时间戳。 否则，这个字段应该是整个时间戳。

类型1的消息块有7个字节长，消息流ID没有被包含，这个消息块得到和先前消息块同样的流ID，带有可变长的消息的流（例如许多视频格式）在类型0消息块后应该使用这种格式作为每一个消息的第一个消息块。

类型2块头长度为3个字节。 流ID和消息长度都不包含在内; 该块与前面的块具有相同的流ID和消息长度。 具有固定大小消息的流（例如，某些音频和数据格式）应该在第一个消息之后使用这种格式作为每个消息的第一个块。

类型3 的消息块没有头，流ID，消息长度和时间戳delta，这个类型的消息块在之前的消息块中取值，当单一的消息被分裂成消息块，所有的消息块除了第一个，其余都应该使用这种类型，流由同样大小的消息组成。

块消息头中每个字段的描述：

Extended Timestamp 字段用于编码大于16777215（ 0xFFFFFF ）的时间戳或时间戳增量; 也就是说，对于时间戳或时间戳增量，它们不适合类型0,1或2块的24位字段。 该字段对完整的32位时间戳或时间戳增量进行编码。 这个字段用于表示将类型0块的时间戳字段或类型1或2块的时间戳增量字段设置为16777215（ 0xFFFFFF ）。 当相同块流ID的最新类型0,1或2的块指示存在扩展时间戳字段时，该字段出现在类型3的块中。

共有2个示例

本例给出了一个简单的音频消息流，这个例子示范了信息的冗余。

下表显示了在此流中生成的块。 从消息3开始，数据传输得到优化。 除此之外，每消息只有1字节的开销。

本例说明一个很长的消息被分割成很多消息块。

这里是分割出来的消息块

消息块1的包头数据详细介绍了307个字节的消息的全部。

注意这两个例子，类型3消息块可以用作两种不同的方式，第一种是表示一条消息的延续，第二种是表示一条新消息的开始，这个新消息可以从已经存在的数据中衍生出来。

RTMP 块流使用消息类型ID 1,2,3,5和6作为协议控制消息。 这些消息包含 RTMP Chunk Stream 协议所需的信息。

这些协议控制消息务必具有消息流ID 0 （称为控制流）并且以块流ID 2 发送。协议控制消息一旦被接收就会立即生效，同时时间戳被忽略。

协议控制消息1：设置消息块大小。用来通知对方新的最大的消息块大小。

消息块的大小可以被设置成一个默认的值，128字节，但是客户端或者服务端可以改变这个值，并且发送消息通知对方更新。例如：假设一个客户端想要发送131字节的音频数据，消息块的大小为128字节，在这种情况下，客户端可以发送这个协议控制消息给服务端以通知消息块的大小被设置成了131字节，那么客户端就可以用一个消息块发送音频数据。

最大块大小应该不能小于128个字节，并且必须不能小于1个字节。 每个方向的最大块大小都是独立维护的。

0 ： 这一位必须为0。

chunk size 块大小（31位） ：该字段保存新的最大块大小（以字节为单位），这将用于发件人的所有后续块，直至另行通知。 有效大小为1到2147483647（ 0x7FFFFFFF ）（含）; 但是，大于16777215（ 0xFFFFFF ）的所有大小都是等效的，因为没有块大于一条消息，并且没有消息大于16777215字节。

协议控制消息2：中止消息。用于通知对方是否正在等待块完成消息，然后丢弃部分接收到的消息。 对方接收块流ID作为该协议消息的有效载荷。 应用程序可能会在关闭时发送此消息，以指示不需要进一步处理消息。

chunk stream ID 块流ID （32 位） ： 该字段保存块流ID，对应的当前消息将被丢弃。

客户端或服务器在收到等于窗口大小的字节后，必须向对端发送 Acknowledgement 确认。 窗口大小是发送方未收到接收方确认而发送的最大字节数。 该消息指定了序列号，它是到当前为止收到的字节数。

sequence number 序列号（32 位） ：字段表示到当前为止收到的字节数。

客户端或服务器发送此消息以通知对方在发送 Acknowledgement 确认之间使用的窗口大小。 发送人希望在发送窗口大小字节后得到对方的确认。

客户端或服务器发送此消息来限制另一方的输出带宽。 收到此消息的另一方通过将已发送但未确认的数据量限制为此消息中指示的窗口大小这种方式用来限制其输出带宽。如果窗口大小与发送给此消息发送者的最后一个窗口大小不同，那么接收此消息的另一方应该使用 "Window Acknowledgement Size" 消息进行响应。

限制类型 Limit Type 是以下值之一：

本部分主要介绍 RTMP 消息的格式，在网络实体之间使用较低级传输层（如 RTMP块流 ）传输这些消息。

虽然 RTMP 旨在与 RTMP块流 一起使用，但它可以使用任何其他传输协议发送消息。 RTMP Chunk Stream 和 RTMP 一起适用于各种音视频应用，从一对一和一对多实时广播到视频点播服务，再到交互式会议应用。

服务器和客户端通过网络发送 RTMP 消息以相互通信。 消息可能包括音频，视频，数据或任何其他消息。

RTMP 消息有两部分，头部和有效负载。

消息头包含以下字段：

消息的另一部分是有效负载，它是消息中包含的实际数据。 例如，它可能是一些音频样本或压缩的视频数据。

RTMP使用消息类型ID 4 作为用户控制消息。 这些消息包含RTMP流层使用的信息。 带有ID 1,2,3,5和6的协议消息由RTMP块流协议使用。

用户控制消息应该使用消息流ID 0（称为控制流），并且当通过RTMP块流发送时，在消息流ID 2上发送。用户控制消息在流中被接收时生效， 他们的时间戳被忽略。

客户端或服务器发送此消息以通知对端用户控制事件。 该消息携带事件类型和事件数据。

消息数据 Event Data 的前2个字节用于标识事件类型 Event Type 。 事件类型后面跟着事件数据。 事件数据字段的大小是可变的。 但是，在消息必须通过RTMP块流层的情况下，最大块的大小应该足够大，以允许这些消息适合单个块。

本节介绍在服务器和客户端之间用于相互通信的不同类型的消息和命令。

在服务器和客户端之间交换的不同类型的消息包括用于发送音频数据的音频消息，用于发送视频数据的视频消息，用于发送任何用户数据的数据消息，共享对象消息和命令消息。 共享对象消息提供了一种通用的方式来管理多个客户端和服务器之间的分布式数据。 命令消息在客户端和服务器之间传送 AMF 编码的命令。 客户端或服务器可以通过流使用命令消息请求对方的远程过程调用（ RPC ）。

服务器和客户端通过网络发送消息以相互通信。 消息可以是任何类型，包括音频消息，视频消息，命令消息，共享对象消息，数据消息和用户控制消息。

命令消息在客户端和服务器之间传送 AMF 编码命令。 这些消息的 AMF0 编码的消息类型值为20， AMF3 编码的消息类型值为17。 这些消息被发送来执行一些操作，例如 connect ， createStream ， publish ， play ， pause 等。 诸如 onstatus ， result 等命令消息用于通知发送者有关请求的命令的状态。 命令消息由命令名称，事务ID和包含相关参数的命令对象组成。 客户端或服务器可以通过流使用命令消息请求对方的远程过程调用（ RPC ）。

客户端或服务器发送此消息用于向对方发送元数据或任何用户数据。 元数据包括有关数据（音频，视频等）的详细信息，如创建时间，持续时间，主题等。 AMF0 的消息类型值为18， AMF3 的消息类型值为15。

共享对象是一个Flash对象（name-value对的集合），在多个客户端，实例等之间同步的。 AMF0 的消息类型19和 AMF3 的消息类型16保留用于共享对象事件。 每条消息可以包含多个事件。

支持以下事件类型：

客户端或服务器发送此消息来向对等方发送音频数据。 消息类型值8保留给音频消息。

客户端或服务器发送此消息以向对等方发送视频数据。 消息类型值9保留给视频消息。

聚合消息是单个消息。消息类型22用于聚合消息。

聚合消息的消息流ID会覆盖聚合内的子消息的消息流ID。

聚合消息的时间戳与第一个子消息之间的差异是用于将子消息的时间戳重新归一化为流时间尺度的偏移量。 将偏移量添加到每个子消息的时间戳以达到标准化的流时间。 第一个子消息的时间戳应该与聚合消息的时间戳相同，所以偏移量应该为零。

后向指针包含前一个消息的大小，包括其头部。 它被包含来匹配 FLV 文件的格式并用于向后搜索。

使用聚合消息有几个性能优势：

客户端或服务器发送此消息以通知对端关于用户控制事件。

支持以下用户控制事件类型：

客户端和服务器交换 AMF 编码的命令。发送方发送一条命令消息，其中包含命令名称，事务ID和包含相关参数的命令对象。例如， connect 命令包含 'app' 参数，它告诉客户端连接到的服务器应用程序名称。接收方处理该命令并以相同的事务ID发送响应。响应字符串可以是 _result ， _error 或方法名称，例如 verifyClient 或 contactExternalServer 。

_result 或 _error 命令字符串表示响应。事务ID指示响应引用的未完成的命令。它与 IMAP 和许多其他协议中的标签相同。命令字符串中的方法名称指示发送方正试图在接收方端运行方法。

以下类对象用于发送各种命令：

NetConnection 管理客户端应用程序和服务器之间的双向连接。 另外，它为异步远程方法调用提供支持。

以下命令可以在 NetConnection 上发送：

客户端向服务端发送连接（ connect ）命令请求连接一个服务器应用实例。以下为命令的结构：

以下是连接命令的命令对象中使用的 name-value 对的描述：

audioCodecs 属性的标志值：

videoCodecs 属性的标志值：

videoFunction 属性的标志值：

对象编码( object Encoding )属性的值：

以下是服务端到客户端命令的结构：

以下是连接命令中的消息流：

命令执行期间的消息流是：

NetConnection 对象的调用方法在接收端运行远程过程调用（ RPC ）。 被调用的 RPC 名称作为参数传递给 call 命令。

从发送方到接收方的命令结构如下：

响应的命令结构如下：

客户端将此命令发送到服务器以创建用于消息通信的逻辑通道。音频，视频和元数据的发布是通过使用 createStream 命令创建的流通道执行的。

NetConnection 是默认通信通道，其流ID为0。协议和一些命令消息（包括 createStream ）使用默认通信通道。

从客户端到服务器的命令结构如下所示：

从服务器到客户端的命令结构如下：

NetStream 定义了流式音频，视频和数据消息可以通过将客户端连接到服务器的 NetConnection 流动的通道。 一个 NetConnection 对象可以为多个数据流支持多个 NetStream 。

以下命令可以由客户端在 NetStream 上发送到服务器：

服务器使用 'onStatus' 命令将 NetStream 状态更新发送到客户端：

客户端将此命令发送到服务器以播放流。 播放列表也可以使用此命令多次创建。

如果您想要创建一个可在不同直播流或录像流之间切换的动态播放列表，请多次调用 play ，每次给 reset 传递 false 。相反，如果要立即播放指定的数据流，请清空播放队列中的其他流，给 reset 传递 true 。

从客户端到服务器的命令结构如下所示：

Play 命令中的消息流：