FLV视频发布的两种方式
FLV视频发布的两种方式(HTTP or RTMP)
上网检查youtube，6rooms和56，发现他们用的播放协议也都是Http。按说FMS/Red5作为流媒体服务器，是专门做过优化的。但为何这些网站都没采用RTMP的协议呢。
RTMP协议和Http比有哪些优势呢，或者说：我们为什么要使用FMS/Red5呢？
两种协议HTTP和RTMP，有点点不同，
用HTTP方式： 先通过IIS 将FLV下载到本地缓存，然后再通过NetConnection的本地连接来播放这个FLV，这种方法是播放本地的视频，并不是播放服务器的视频。因此在本地缓存里可以找到这个FLV。其优点就是服务器下载完这个FLV，服务器就没有消耗了，节省服务器消耗。其缺点就是FLV会缓存在客户端，对FLV的保密性不好。
用RTMP方式： 通过NetConnection连接到FMS/Red5服务器，并实时播放服务器的FLV文件，这种方式可以任意选择视频播放点（SEEK()），并不象HTTP方式需要缓存完整个FLV文件到本地才可以任意选择播放点，其优点就是在本地缓存里是找不到这个FLV文件的。其优点就是FLV不会缓存在客户端，FLV的保密性好，其缺点就是消耗服务器资源，连接始终是实时的。
一句话，一个是本地播放，一个是服务器实时播放，因需而定。
RTMP协议概述
介绍:
RTMP协议是被Flash用于对象,视频,音频的传输.该协议建立在TCP协议或者轮询HTTP协议之上.
RTMP协议就像一个用来装数据包的容器,这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据.
一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的.
网络连接(Connection)
一个Actionscript连接并播放一个流的简单代码:
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 |
流
关于流的操作我们需要进一步研究,在论坛中的http://www.openred5.com/bbs/viewthread.php?tid=175&extra=page%3D1这篇文章研究的还是不错的,大家可以参考.不过下面可以列一个关于客户端向服务器端发送流的流程:
Client→Server :发送一个创建流的请求.
Server→Client :返回一个表示流的索引号.
Client→Server :开始发送.
Client→Server :发送视音频数据包(这些包在同一个频道(channel)并用流的索引号来唯一标识).
