RTMP头RTMP协议封包 参考Red5
RTMP头RTMP协议封包参考Red5RTMP协议封包由一个包头和一个包体组成,包头可以是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 Length0012 bytes018 bytes10 4 bytes11 1 byteHead_Type的后面6个Bit和StreamID决定了ChannelID。
StreamID和ChannelID对应关系：StreamID=(ChannelID-4)/5+1 参考red5ChannelID Use02Ping 和ByteRead通道03Invoke通道我们的connect() publish()和自字写的NetConnection.Call() 数据都是在这个通道的04Audio和Vidio通道05 06 07服务器保留,经观察FMS2用这些Channel也用来发送音频或视频数据二、TiMMERTiMMER占3个字节纪录的是时间戳,音视频流的时间戳是统一排的。
可分为绝对时间戳和相对时间戳。
fms对于同一个流，发布的时间戳接受的时间戳是有区别的publish时间戳,采用相对时间戳，时间戳值等于当前媒体包的绝对时间戳与上个媒体包（不区分音视频）的绝对时间戳之间的差距，单位毫秒。
play时间戳，相对时间戳，时间戳值等于当前媒体包的绝对时间戳与上个同类型媒体包（视频对应视频，音频对应音频）的绝对时间戳之间的差距，单位毫秒。
flv格式文件时间戳，绝对时间戳，时间戳长度3个字节。
超过0xFFFFFF后时间戳值等于TimeStamp & 0xFFFFFF。
flv格式文件影片总时间长度保存在onMetaData的duration属性里面，长度为8个字节，是一个翻转的double类型。
三、AMFSizeAMFSize占三个字节，这个长度是AMF长度，可超过RTMP包的最大长度128字节。
如果超过了128字节，那么由多个后续RTMP封包组合，每个后续RTMP封包的头只占一个字节。
一般就是以0xC？开头。
四、AMFTypeAMFSize占三个字节，这个长度是AMF长度，可超过RTMP包的最大长度128字节。
AMFType是包的类型0×01Chunk Size changes the chunk size for packets0×02Unknown0×03Bytes Read send every x bytes read by both sides0×04Ping ping is a stream control message, has subtypes0×05Server BW the servers downstream bw0×06Client BW the clients upstream bw0×07Unknown0×08Audio Data packet containing audio0×09Video Data packet containing video data0x0A-0x0E Unknown0x0F FLEX_STREAM_SEND TYPE_FLEX_STREAM_SEND0x10FLEX_SHARED_OBJECT TYPE_FLEX_SHARED_OBJECT0x11FLEX_MESSAGE TYPE_FLEX_MESSAGE0×12Notify an invoke which does not expect a reply0×13Shared Object has subtypes0×14Invoke like remoting call, used for stream actions too.0×16StreamData 这是FMS3出来后新增的数据类型,这种类型数据中包含AudioData和VideoData五、StreamIDStreamID是音视频流的ID,如果AMFType!=0x08 或!=0x09那么 StreamID为0。
ChannelID 和StreamID之间的计算公式：StreamID=(ChannelID-4)/5+1 参考red5例如当ChannelID为2、3、4时StreamID都为1 当ChannelID为9的时候StreamID 为2六、封包分析例如有一个RTMP封包的数据0300 00 00 00 01 02 1400 00 00 00 0200 07 63 6F 6E 6E 65 63 74 003F F0 00 00 00 00 00 00 08 ，，，数据依次解析的含义03表示12字节头，channelid=3000000表示Timmer=0000102表示AMFSize=1814表示AMFType=Invoke 方法调用00 00 00 00 表示StreamID = 0//到此,12字节RTMP头结束下面的是AMF数据分析,具体的AMF0数据格式请参考 /fly2700/archive/2008/04/09/281432.html02表示String0007表示String长度763 6F 6E 6E 65 63 74 是String的Ascall值"connect"00表示Double3F F0 00 00 00 00 00 00 表示double的0.008表示Map数据开始red5代码分析如下:Head_Type我看到代码red5与以上分析有些出入.“Head_Type的前两个Bit和长度对应关系”分析没有错.而red5代码中计算头字节公式如下(头字节不一定是一个字节，有可能是两个字节或三个字节，需要说明的头字节计算结果最终会影响ChannelId)：1.当Head_Byte & 0x3F=0时,headerValue=((int) headerByte & 0xff) << 8 | ((int) in.get() & 0xff)此时读出字节头为两个字节2.当Head_Byte & 0x3F=1时，headerValue = ((int) headerByte & 0xff) << 16 | ((int) in.get() & 0xff) << 8 | ((int) in.get() & 0xff)此时读出字节头为三个字节3.如果以上两个条件都不满足，则headerValue = (int) headerByte & 0xff; channelId计算公式为:1.如果头为一个字节，则channelId = (headerValue & 0x3f)2.如果头为两个字节,则channelId = 64 + (headerValue & 0xff)3.如果头为三个字节，则channelId = 64 + ((headerValue >> 8) & 0xff) +((headerValue & 0xff) << 8)Head_Type的后面6个Bit和StreamID决定了ChannelID。
StreamID和ChannelID对应关系：StreamID=(ChannelID-4)/5+1 参考red5ChannelID Use02 Ping 和ByteRead通道03 Invoke通道我们的connect() publish()和自字写的NetConnection.Call() 数据都是在这个通道的04 Audio和Vidio通道05 06 07 服务器保留,经观察FMS2用这些Channel也用来发送音频或视频数据以下是用一个截包工具获取原始二进制数据。
03 00 00 00 00 01 30 14 00 00 00 00 02 00 07 63 6F 6E 6E 65 63 74 00 3F F0 00 00 00 00 00 00 03 00 03 61 70 70 02 00 08 72 6F 6F 6D 2F 30 30 31 00 08 66 6C 61 73 68 56 65 72 02 00 0E 57 49 4E 20 31 30 2C 30 2C 31 32 2C 33 36 00 06 73 77 66 55 72 6C 06 00 05 74 63 55 72 6C 02 00 1C 72 74 6D 70 3A 2F 2F 31 39 32 2E 31 36 38 2E 31 2E 31 38 2F 72 6F 6F 6D 2F 30 30 31 00 04 66 70 61 64 01 00 00 0C 63 61 70 61 62 69 6C 69 C3 74 69 65 73 00 40 2E 00 00 00 00 00 00 00 0B 61 75 64 69 6F 43 6F 64 65 63 73 00 40 A8 EE 00 00 00 00 00 00 0B 76 69 64 65 6F 43 6F 64 65 63 73 00 40 6F 80 00 00 00 00 00 00 0D 76 69 64 65 6F 46 75 6E 63 74 69 6F 6E 00 3F F0 00 00 00 00 00 00 00 07 70 61 67 65 55 72 6C 06 00 0E 6F 62 6A 65 63 74 45 6E 63 6F 64 69 6E 67 00 40 08 00 00 00 00 00 00 00 00 09 02 00 0F 30 38 31 32 31 31 C3 30 39 32 30 32 32 32 32 32 0200 02 33 34 02 00 0D 31 39 35 2E 31 36 38 2E 31 34 2E 32 32 02 00 03 30 30 31 02 0001 30 02 00 01 38 02 00 01 301.下面我们来对鲜绿色背景头数据进行分析从上面剖析包头说明判断可以第一个字节0x03，此包头有12个字节.Head_Type=03TiMMER=00 00 00AMFSize=00 01 30 表示经过组合之后AMF的总字节长度(默认情况下每个RTMP包为128字节，由C3字节得知，以上包有3个rtmp封包)AMFType=14 表示接下来第一个字符串为远程调用方法名称02 00 07 63 6F 6E 6E 65 63 74 02字节表示字符串类型00 07表示该字符串长度为7个字节63 6F 6E 6E 65 63 74 为connect远程方法StreamID=00 00 00。
RTMP协议
RTMP协议协议名称：RTMP协议一、引言RTMP（Real-Time Messaging Protocol）是一种用于实时数据传输的协议，最初由Adobe公司开发，用于在Flash平台上实现音视频流的传输。
RTMP协议可以通过传输控制协议（TCP）在客户端和服务器之间进行数据传输，支持实时音视频流的传输和即时通讯功能。
二、协议目的RTMP协议的目的是确保高效、稳定、实时的音视频传输和即时通讯功能。
通过该协议，用户可以在客户端和服务器之间传输实时音视频流，并实现实时的双向通讯。
三、协议范围本协议适用于所有使用RTMP协议进行实时音视频传输和即时通讯的应用场景，包括但不限于在线直播、视频会议、游戏实时通讯等。
四、术语定义1. RTMP：Real-Time Messaging Protocol的缩写，即实时消息传输协议。
2. 客户端：指使用RTMP协议进行数据传输的终端用户设备。
3. 服务器：指提供RTMP服务的服务器端设备。
五、协议内容1. 连接建立1.1 客户端通过TCP连接与服务器建立连接。
1.2 客户端发送连接请求到服务器，请求中包含握手信息。
1.3 服务器收到连接请求后，验证握手信息的合法性。
1.4 服务器发送握手响应到客户端，确认连接建立成功。
2. 数据传输2.1 客户端发送音视频流数据到服务器，数据格式为FLV（Flash Video）。
2.2 服务器接收音视频流数据，并进行解码处理。
2.3 服务器将解码后的音视频流数据发送给客户端。
2.4 客户端接收音视频流数据，并进行播放或显示。
3. 控制消息3.1 客户端和服务器之间通过控制消息进行交互。
3.2 控制消息包括连接控制、流控制、用户控制等。
3.3 连接控制消息用于管理连接的建立、断开和状态维护。
3.4 流控制消息用于管理音视频流的传输和控制。
3.5 用户控制消息用于控制音视频流的播放、暂停、停止等操作。
4. 安全性4.1 RTMP协议支持加密传输，可使用SSL/TLS协议进行数据加密。
RTMP协议
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)一个Actionscript连接并播放一个流的简单代码: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 packets0×02 Unknown anyone k now this one?0×03 Bytes Read send every x bytes read by both sides0×04 Ping ping is a stream control message, has subtypes 0×05 Server BW the servers downstream bw0×06 Client BW the clients upstream bw0×07 Unknown anyone know this one?0×08 Audio Data packet containing audio0×09 Video Data packet containing video data0x0A - 0×11 Unknown anyone know?0×12 Notify an invoke which does not expect a reply0×13 Shared Object has subtypes0×14 Invoke like remoting call, used for stream actions too.Shared Object 数据类型0×01 Connect0×02 Disconnect0×03 Set Attribute0×04 Update Data0×05 Update Attribute0×06 Send Message0×07 Status0×08 Clear Data0×09 Delete Data0x0A Delete Attribute0x0BInitial DataRTMP包结构RTMP包包含一个固定长度的包头和一个最长为128字节的包体.包头可以是下面4种长度的任意一种:12, 8, 4, or 1 byte(s).第一个字节的前两个Bit很重要,它决定了包头的长度.它可以用掩码0xC0进行"与"计算.下面的表格罗列了可能的包头长度:Bits Header Length00 12 bytes01 8 bytes10 4 bytes11 1 byte其实RTMP包结构就是使用了AMF格式.下面是一个关于客户端向服务器端发送流的流程:Client→Server :发送一个创建流的请求.Server→Client :返回一个表示流的索引号.C lient→Server :开始发送.Client→Server :发送视音频数据包(这些包在同一个频道(channel)并用流的索引号来唯一标识).四．RTMP协议封包RTMP协议封包由一个包头和一个包体组成,包头可以是4种长度的任意一种:12, 8, 4, 1 byte(s).完整的RTMP包头应该是12bytes,包含了时间戳,AMFSize,AMFType,StreamID信息, 8字节的包头只纪录了时间戳,AMFSize,AMFType,其他字节的包头纪录信息依次类推。
RTMP协议
RTMP协议协议名称：Real-Time Messaging Protocol (RTMP) 协议1. 引言本协议描述了 Real-Time Messaging Protocol (RTMP) 的标准格式。
RTMP 是一种用于实时数据传输的协议，最初由 Adobe Systems 开发，用于在 Adobe Flash 平台上传输音频、视频和数据流。
随着时间的推移，RTMP 也被应用于其他实时流媒体应用程序。
2. 目的本协议的目的是规范 RTMP 的通信过程和数据格式，以确保在不同平台和设备之间的兼容性和互操作性。
3. 协议规范3.1 连接建立- 客户端通过 TCP/IP 连接到 RTMP 服务器的默认端口 1935。
- 客户端发送 C0 和 C1 数据包，其中 C0 是一个字节，表示 RTMP 版本号，C1 是一个 1536 字节的随机数据块。
- 服务器接收到 C0 和 C1 数据包后，发送 S0 和 S1 数据包作为响应，其中 S0 是一个字节，表示 RTMP 版本号，S1 是一个 1536 字节的随机数据块。
- 客户端接收到 S0 和 S1 数据包后，发送 C2 数据包，其中包含 S1 数据块的哈希值。
- 服务器验证 C2 数据包，如果匹配成功，连接建立成功。
3.2 握手过程- 客户端发送 C0 和 C1 数据包后，等待服务器响应。
- 服务器接收到 C0 和 C1 数据包后，发送 S0 和 S1 数据包作为响应，等待客户端发送 C2 数据包。
- 客户端接收到 S0 和 S1 数据包后，发送 C2 数据包，等待服务器验证。
- 服务器验证 C2 数据包，如果匹配成功，握手成功。
3.3 数据传输- RTMP 使用消息进行数据传输，每个消息由一个消息头和一个消息体组成。
- 消息头包含了消息的类型、长度、时间戳和流 ID 等信息。
- 消息体包含了实际的数据，可以是音频、视频或其他自定义数据。
- RTMP 支持多种消息类型，如音频消息、视频消息、命令消息等。
基于Red5的网络视频系统的设计与实现
趋势下 ，对ＦａｈＳｒｅ的研究变得颇为重要 。Ｒ ｄ 的主 ｌｓ ｅｖｒ ｅ５
Ｐｏ ｃ１ ｒｔ ｏ） ｏ 是互联 网上应用最为广泛 的一种 网络协议 。所 有的ｗｗｗ文件都必须遵守这个标准。
视频可分为网络直播视频和网络录制视频 。网络视频具 有交互性 、实时 ｌ 生、集成性、码率可变、突发性强等特
点。
ＨＴ Ｐ Ｔ 协议基 于Ｔ Ｐ Ｃ 构建 ，其 中的主要 参与者是客 户端 和服务器 ，客户端一 般为浏 览器 ，也 可 以是其它
一
包都是按 照固定大小 的包传输 的【 。
Ｒ ＭＰ Ｔ 协议是为了和ｆ ｓ之间交换 信令 以及媒体 数 ｌｈ ａ
据 。为了提高使用效率信令 和媒体数据都是使用相 同的
机制 。
、
网络视 频简 介
在 ＲＴＭ 议 中 信 令 和 媒 体 数 据 都 称 之 为 Ｐ协
Ｍｅｓｇ ，在网络 中传输这些Ｍｅｓｇ ，为了区分它们肯 ｓ ｅ ａ ｓ ｅ ａ
主要方法有Ｇ ｔ ｏｔ ｅｄ ，常用 的Ｇ ｔ ｅ、Ｐ ｓ 、Ｈ ａ等 ｅ 方法用来从 服务器上获取数据Ｐ ｓ ｏｔ 方法用来将 客户端数据提交到服
务器 。
节目 源
Ｒｅ ｔ ｘ ５
流 媒
服
ｎｔ ｔ ｐ
Ｉ Ｐ 客
夕
Ｐ 流媒体编码器 ８
体
Ｒｍ ｔｐ
络 ］ 端几 千Ｋ，这 个 问题就必然有一个分片 的问题 ，在Ｒ ＭＰ Ｔ 协议 中对应
Red5服务器搭建
Red5服务器搭建Red5服务器架构模型：直播工作模型：·Client：向Server（业务逻辑服务器）请求推流授权·Server发布带授权信息的Stream给Client·Client通过RTMP推流给Pili Stream Cloud·Client向Server请求播放授权·Server向Client发布播放地址·Client调用播放器SDK打开播放地址进行播放基于七牛云直播服务的业务架构，我们可以大致了解直播云服务的一些流程现在可以动手自己搭建一个基于Red5-Flash的流媒体服务器1.Red5服务器简要介绍：流媒体服务器是通过建立发布点来发布流媒体内容和管理用户连接的。
流媒体服务器能够发布从视频采集卡或摄像机等设备中传来的实况流，也可以发布事先存储的流媒体文件，并且发布实况流和流媒体文件的结合体。
一个媒体流可以由一个媒体文件构成，也可以由多个媒体文件组合而成，还可以由一个媒体文件目录组成。
Flash Media Server，简称 FMS，是 Flash 大家庭里的一员，被称为是目前开发Web 音视频应用程序（比如，视频聊天室、视频会议系统、播客系统、音视频留言等等）的最方便最快捷的解决方案。
也在 web 应用程序开发上有着越来越广泛的应用。
当然 FMS 这种优良功能并不是免费提供给广大用户的，几千美金每个点的价格让很多开发人员望而却步。
于是，大家开始尝试寻找一种更合适的解决方案，开源的 Red5 便成为了人们的新宠。
Red5 是一个采用 Java 开发的开源的 Flash 流媒体服务器，功能上与 FMS 类似。
它支持：把音频（MP3）和视频（FLV）转换成播放流；录制客户端播放流（只支持FLV）；共享对象；现场直播流发布；远程调用。
Red5 使用 RSTP 作为流媒体传输协议，包括在线录制，Flash 流媒体播放，在线聊天，视频会议等一些基本功能。
RTMP协议
RTMP协议协议名称: RTMP协议1. 引言RTMP（Real-Time Messaging Protocol）是一种用于实时数据传输的协议，最初由Adobe Systems开发。
它被广泛应用于流媒体传输、互动直播和实时通信等领域。
本协议旨在详细描述RTMP协议的标准格式，以便确保各方能够准确理解和实施该协议。
2. 协议概述RTMP协议是一种基于TCP的协议，用于在客户端和服务器之间传输音频、视频和其他实时数据。
它支持多种传输模式，包括实时数据传输、点播和直播等。
3. 协议结构RTMP协议由多个消息组成，每个消息都有一个消息头和一个消息体。
消息头包含了消息的类型、长度和时间戳等信息，而消息体则包含了实际的数据。
3.1 消息头消息头由三个部分组成：基本头、消息类型ID和消息长度。
- 基本头：用于指示消息头的长度。
它的长度可以是1、2或3个字节。
- 消息类型ID：用于指示消息的类型，包括音频、视频、命令和数据等。
- 消息长度：用于指示消息体的长度。
3.2 消息体消息体是RTMP协议中实际的数据部分。
它可以是音频、视频、命令或数据等。
4. 协议交互RTMP协议的交互过程包括握手、连接、传输和关闭等步骤。
4.1 握手握手过程用于建立客户端和服务器之间的连接。
它包括两个阶段：握手请求和握手响应。
- 握手请求：客户端向服务器发送一个握手请求消息，包含了一些握手参数。
- 握手响应：服务器接收到握手请求后，生成一个握手响应消息，并将其发送给客户端。
4.2 连接连接过程用于在客户端和服务器之间建立一个稳定的连接。
它包括两个阶段：连接请求和连接响应。
- 连接请求：客户端向服务器发送一个连接请求消息，包含了一些连接参数。
- 连接响应：服务器接收到连接请求后，生成一个连接响应消息，并将其发送给客户端。
4.3 传输传输过程用于在客户端和服务器之间传输实时数据。
它包括音频、视频和其他实时数据的传输。
- 音频传输：客户端和服务器之间传输音频数据的过程。
使用Red5
使用Red5和FFMpeg搭建在线Flash流媒体分享平台最近视频的东西比较火，前些天我也稍微了解了一下使用开源软件建在线Flash 流媒体播放平台的解决方案，还是有一些收获。
Red5是一款基于java的开源的Flash流媒体Server 软件，可以作为取代Macromedia提供的商业版本FMS。
Red5使用RSTP作为流媒体传输协议，内置了一些示例，这些示例实现了在线录制， flash流媒体播放，在线聊天，视频会议等一些基本的功能。
由于系统本身是开源的，在碰到问题的时候也比较容易解决，大不了直接改代码，在成本方面也可以省下一笔不小的开销，为未来的功能扩展也提供了充分的空间。
如果仅仅是实现在线录制，在线播放，那么Red5也就差不多够了，但可能我们有时候还需要用户上传自己拍摄的视频文件，而要把这些视频文件转成可播放的flv文件就需要视频编码软件了。
FFMpeg提供了录制，播放，视频流处理的完整解决方案。
它自身也带了一个基于HTTP的流媒体广播程序以及其它几个实用的程序，但我们的重点还是它的视频转换程序，似乎Google Video也是用的它的程序作为视频转换工具。
我用FFMpeg转了几个视频，效果还可以，在声音上碰到了一些问题，在不添加参数的情况下，有一部分视频的声音会有问题，有的视频无论怎么添加参数，都出不来声音，报错提示的是不支持所带的声音采样格式，只支持几种固定的格式，我看了一下代码，确实是这样子，但理论上应该是能够解决的。
FFMpeg自带的libavcodec是一套很牛的编码库，为了保证质量和性能，里面的很多codec 都是从头开发的。
这两个加起来，实现一些简单的在线视频功能就差不多了。
RED5—从下载到HELLO WORLD！D5Power Studio原创，转载请注明出处~谢谢！RED5的中文资料象牛毛一样稀少。
从下载到完全调试成功，大概花费了1天多的时间。
在这个把中间出现的问题罗列出来，希望给想研究RED5的朋友一点帮助。
Windows下Red5安装与配置文档
Windows下Red5安装与配置RED5简介Red5是一个采用Java开发开源的Flash流媒体服务器。
它支持：把音频（MP3）和视频（FLV）转换成播放流；录制客户端播放流（只支持FLV）；共享对象；现场直播流发布；远程调用。
Red5使用RSTP作为流媒体传输协议，在其自带的一些示例中演示了在线录制，flash流媒体播放，在线聊天，视频会议等一些基本功能。
软件环境既然是Java开发的，自然少不了要安装JDK，这里使用的是JDK1.6版本，Red5用的是1.0.1版本，Red5内嵌了Tomcat6.x服务器。
以下是Red5和Flowplayer3.2.x下载地址。
Red5：/downloads/Flowplayer：/download/软件安装与环境配置1.安装JDKJDK这里使用的是1.6版本，最常用，与Red5搭配更好。
可以自行修改安装路径，这里默认。
安装完毕后设置环境变量：JAVA_HOME，PATH和CLASSPATH。
1，新建变量名：JAVA_HOME，变量值：C:\Program Files\Java\jdk1.6.0_21 2，打开PATH，添加变量值：%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin 3，新建变量名：CLASSPATH，变量值：（注意此处以.;开始，英文状态）.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar备注：1，.表示当前路径，%JAVA_HOME%就是引用前面指定的JAVA_HOME；2，JAVA_HOME指明JDK安装路径，此路径下包括lib，bin，jre等文件夹，tomcat，eclipse等的运行都需要依靠此变量。
3，PATH使得系统可以在任何路径下识别java命令。
4，CLASSPATH为java加载类(class or lib)路径，只有类在classpath中，java 命令才能识别。
android视频开发之一android如何使用juv-rtmp-client.jar向red5服务器发布实时视频数据
android视频开发之一Android 如何使用juv-rtmp-client.jar 向Red5服务器发布实时视频数据使用juv-client-client.jar主要是尽快地完成毕业设计里面手机端向网页端发送实时视频的功能，由于实习和做毕业设计的时间冲突，因此完成毕业设计只花了1个多月时间。
（万恶的形式主义，论文格式改了我老久老久）因此代码上面会存在一些问题，并且也是单纯的实现了摄像头视频的实时传输，麦克风的实时语音没有实现。
自我感觉这个毕业设计没有多大价值，但是有参考意义，特把实现记录一下，用作纪念！原理：juv-client-client.jar提供了很多与Red5的交互操作，比如连接，流数据发布，方法互相调用等等。
在发布实时视频数据的之前，我们需要建立手机端和服务器端的RTMP连接。
使用类库里的NetConnection类：关键代码如下：private void connectRed5() { //key的值官方网站上可以申请到免费试用版本：/order.jsf#request_evaluation_key License.setKey("63140-D023C-D7420-00B15-91FC7"); connection = new NetConnection();//对连接进行配置connection.configuration().put(NetConnection.Configuration.INACTIVITY_TIMEOUT, -1);connection.configuration().put(NetConnection.Configuratio n.RECEIVE_BUFFER_SIZE, 256 * 1024);connection.configuration().put(NetConnection.Configuratio n.SEND_BUFFER_SIZE, 256 * 1024);connection.client(new ClientHandler());connection.addEventListener(new NetConnectionListener());connection.connect(red5_url); }其中new ClientHandler类是继承Object，里面写的方法可以被服务器调用。
red5 rtmp协议参数
red5 rtmp协议参数
RTMP（Real-Time Messaging Protocol）是一种用于在互联网上传输音频、视频和数据的协议。
而Red5是一个基于Java的开源流媒体服务器，支持RTMP协议。
在使用Red5服务器时，可以通过一些参数来配置和控制RTMP协议的行为。
一些常见的RTMP协议参数包括：
1. host，指定RTMP服务器的主机名或IP地址。
2. port，指定RTMP服务器的端口号。
3. app，指定连接的应用程序名称，对于Red5服务器，默认的应用程序名称是"live"。
4. stream，指定流的名称，用于唯一标识一个流。
5. tcUrl，指定连接的URL，包括主机名、端口和应用程序名称。
6. pageUrl，指定用于SWF文件的URL，用于验证连接来源。
7. swfUrl，指定SWF文件的URL，用于验证连接来源。
除了上述参数外，还有一些高级的参数可以用于配置RTMP连接的各种属性，比如连接超时时间、缓冲区大小、连接重试次数等。
这些参数可以根据具体的需求进行配置，以实现更灵活和定制化的RTMP连接行为。
总的来说，通过合理配置RTMP协议参数，可以实现对RTMP连接的控制和管理，以满足不同的业务需求和性能要求。
在使用Red5服务器时，了解和合理配置这些参数可以帮助用户更好地利用RTMP 协议进行流媒体传输。