FLV视频发布的两种方式(HTTP协议和RTMP协议)

　　配好了FMS/Red5，用flvplayerBack测试RTMP 协议通过。想进一步用NetStream做开发的时候，却发现NetStream.play只支持Http和File两种协议(参考Flash帮助)。
　　上网检查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的保密性好，其缺点就是消耗服务器资源，连接始终是实时的。
一句话，一个是本地播放，一个是服务器实时播放，因需而定。

　　HTTP现在应用的比较多，因为这个完全不需要RED5或者FMS的服务器端的支持，普通的WEB服务器都可以实现（虚拟主机）后面一个就必须有服务器了，不过保密性会强一些。

　　只所以大多数站点都用HTTP模式，一个是因为对服务器来说压力小一些，另外一种对FLASH来讲，播放器的参数更容易设置一些，因为只要修改xxx.swf?file=xxx就可以了.

　　flv视频目前国内用的最多的是互联网视频点播。
　　flv的播放分两种形式： 下播 和 流 2种。
　　下播简单说就是，视频必须缓冲到本地才能播放，如果视频没有缓冲完，则不能向后拖拽进度。
　　流（streaming）的形式就比较类型原来wmv的流的形式，可以从任意时间点开始播没有缓冲的内容。
　　下播是比较常用的，因为实现简单，flv文件像图片一样被存取，不需要特殊的流媒体服务。而streaming的形式需要fms来支持。
　　flv文件本身就比较适合网络视频，缓冲时间短，互动效果好，用户体验好。其中又以on2的编码在同等画质情况下能把视频压的很小从而节省带宽。flash9.0.54（要不就是9.0.115）以后就可以支持h.264编码的高清格式。
　　格式转换主要需要根据不同的视频格式进行解码，再用flv的编码器进行编码。flv常用的编码器有sinero??park??（具体拼写忘了）和 on2vp6 2种，前者是开源的但画质一般，但转码速度快，后者是收费的转码时间很长，但效果非常好。最新的还有H.264的编码（H.264的编码的文件后缀就不是 flv了）。
　　flv的播放器自己写应该不难，有开源的好像叫“若吃”？最简单的用flash的object直接读flv就可以实现视频播放，也可以自己用as编写实现丰富的互动功能。

　　服务器端如果不用fms的服务，采用下播的方式，基本没有什么特别的。页面之间读去flv文件就好了。如果需要防盗链什么的另说。
　　建议把flv文件单独放在一台服务器上，给予足够的带宽。
如果视频量大建议用CDN进行视频分发。