流媒体指的是在网络中使用流技术传输的连续时基媒体，其特点是在播放前不需要下载整个文件，而是采用边下载边播放的方式，它是视频会议、IP电话等应用场合的技术基础。
一、流媒体简介
随着Internet的日益普及，在网络上传输的数据已经不再局限于文字和图形，而是逐渐向声音和视频等多媒体格式过渡。目前在网络上传输音频/视频（Audio/Video，简称A/V）等多媒体文件时，基本上只有下载和流式传输两种选择。通常说来，A/V文件占据的存储空间都比较大，在带宽受限的网络环境中下载可能要耗费数分钟甚至数小时，所以这种处理方法的延迟很大。如果换用流式传输的话，声音、影像、动画等多媒体文件将由专门的流媒体服务器负责向用户连续、实时地发送，这样用户可以不必等到整个文件全部下载完毕，而只需要经过几秒钟的启动延时就可以了，当这些多媒体数据在客户机上播放时，文件的剩余部分将继续从流媒体服务器下载。
流（Streaming）是近年在Internet上出现的新概念，其定义非常广泛，主要是指通过网络传输多媒体数据的技术总称。流媒体包含广义和狭义两种内涵：广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称，即流媒体技术；狭义上的流媒体是相对于传统的下载-回放方式而言的，指的是一种从Internet上获取音频和视频等多媒体数据的新方法，它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术，服务器能够向客户机发送稳定和连续的多媒体数据流，客户机在接收数据的同时以一个稳定的速率回放，而不用等数据全部下载完之后再进行回放。
由于受网络带宽、计算机处理能力和协议规范等方面的限制，要想从Internet上下载大量的音频和视频数据，无论从下载时间和存储空间上来讲都是不太现实的，而流媒体技术的出现则很好地解决了这一难题。目前实现流媒体传输主要有两种方法：顺序流（progressive streaming）传输和实时流（realtime streaming）传输，它们分别适合于不同的应用场合。
顺序流传输
顺序流传输采用顺序下载的方式进行传输，在下载的同时用户可以在线回放多媒体数据，但给定时刻只能观看已经下载的部分，不能跳到尚未下载的部分，也不能在传输期间根据网络状况对下载速度进行调整。由于标准的HTTP服务器就可以发送这种形式的流媒体，而不需要其他特殊协议的支持，因此也常常被称作HTTP 流式传输。顺序流式传输比较适合于高质量的多媒体片段，如片头、片尾或者广告等。
实时流传输
实时流式传输保证媒体信号带宽能够与当前网络状况相匹配，从而使得流媒体数据总是被实时地传送，因此特别适合于现场事件。实时流传输支持随机访问，即用户可以通过快进或者后退操作来观看前面或者后面的内容。从理论上讲，实时流媒体一经播放就不会停顿，但事实上仍有可能发生周期性的暂停现象，尤其是在网络状况恶化时更是如此。与顺序流传输不同的是，实时流传输需要用到特定的流媒体服务器，而且还需要特定网络协议的支持。
二、流媒体协议
简单介绍一下流媒体协议，
1.主要流媒体协议一览：
|
名称 |
推出机构 |
传输层协议 |
客户端 |
目前使用领域 |
|
RTSP+RTP |
IETF |
TCP+UDP |
VLC, WMP |
IPTV |
|
RTMP |
Adobe Inc. |
TCP |
Flash |
互联网直播 |
|
RTMFP |
Adobe Inc. |
UDP |
Flash |
互联网直播 |
|
MMS |
Microsoft Inc. |
TCP/UDP |
WMP |
互联网直播+点播 |
|
HTTP |
WWW+IETF |
TCP |
Flash |
互联网点播 |
流媒体协议主要包括:RTP、RTCP、RTSP、SDP、SIP、RTMP、RTMFP、SRTP、SRTCP、MMS，几个协议的区别和概念如下：
RTP: 这个协议是干累活的，音视频数据，都由这个协议承载。rtp实际的包里，还包括些流类型（h264，aac）描述，包序列描述等等。底层数据包都由UDP承载。
RTCP：控制协议，举个例子，音视频数据发出去了，发了多少，收到多少，丢了多少，网络延迟多大，这些QOS（Quality of Service）相关的数据，以及音频同步的信息。谁来提供，没错，就是rtcp。与rtp是兄弟协议，由udp承载数据。
RTSP：类似用户界面操作，和Http比较类似，提供播放，停止，加入等功能。注意，这里rtsp只负责发送操作命令，实际的音视频数据，并不由这个协议承载。
一般采用UDP传输视音频，支持组播，效率较高。但其缺点是网络不好的情况下可能会丢包，影响视频观看质量。tcp不会发生丢包，因而保证了视频的质量，但是传输的效率会相对低一些。
rtsp协议并没有规定底层是由tcp还是udp实现，实际操做中，rtsp有tcp和udp两种实现，。这个也算和http不同的一点，http都是tcp。
RTSP-Over-HTTP：关键（同时也是全部内容）在于：让RTSP报文通过HTTP端口（即80端口）通信。
我们知道RTSP的标准端口是554，但是由于各种不同的防火墙等安全策略配置的原因，客户端在访问554端口时可能存在限制，从而无法正常传输RTSP报文。
但是HTTP端口（80端口）是普遍开放的，于是就有了让RTSP报文通过80端口透传的想法，即RTSP-Over-HTTP。
SDP: 完全是一种会话描述格式（对应的RFC2327,RFC4566),它不属于传输协议,它只使用不同的适当的传输协议，SDP协议是也是基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围。
SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。
SIP: 会话初始协议（Session Initiation Protocol）是一种信令协议，用于初始、管理和终止网络中的语音和视频会话，具体地说就是用来生成、修改和终结一个或多个参与者之间的会话。
SIP是互联网工程任务组（IETF）多媒体数据和控制体系结构的一个组成部分，因此它与IETF的许多其他协议都有联系，例如RTP（实时传输协议）和SDP协议。
SIP与许多其它的协议协同工作，仅仅涉及通信会话的信令部分(control message)。SIP报文内容传送会话描述协议(SDP)，SDP协议描述了会话所使用流媒体细节，
如：使用哪个IP端口，采用哪种编解码器等等。SIP的一个典型用途是：SIP“会话”传输一些简单的经过封包的实时传输协议流。RTP本身才是语音或视频的载体。
----------------------------------------------------------------------------------------------------------------------
以上是比较标准的流媒体协议，
RTMP: 看起来很像ietf的东西，不过是adobe自家的协议，不过后来也开放出来了，基本上可以等同于flash播放的服务器。有开源实现rtmpdump，有兴趣的同学可以自己google一下自己看看。
RTMFP 是一种比较新的流媒体协议，特点是支持P2P。
SRTP: 思科与爱立信扣起手搞得，后来也成了ietf标准，可以理解成加密的rtp，主要用于voip，
SRTCP:同上。这两个协议都是相伴而生的。
MMS:微软自己搞的，类似于rtsp协议，暗下不表。觉得这里很搞笑，不是国际标准，但总还要给他很大的支持
2.比较知名的开源实现，
ortp：linphone项目的子项目，开发语言是c语言，实现了rtp/rtcp协议，没有实现rtsp协议，如果要用，自己google一下，有比较多的开源实现。自己动手也不算复杂。
jrtplib:博客有详细介绍: http://www.cnblogs.com/yuweifeng/p/7550737.html
live555:live555的野心明显不是实现几个协议，人家是要干票大的。他除了实现了rtsp/rtp/rtcp/各种协议之外，还实现了各种流媒体的分包解析。
上面两个还算是单纯的库，live555就是一整套解决方案了，只是顺便实现几个协议，其他：vlc/mpeg4ip/的rtp相关实现都是使用live555
3.QoS
QoS（Qualityof Service）服务质量，是网络的一种安全机制, 是用来解决网络延迟和阻塞等问题的一种技术。在正常情况下，如果网络只用于特定的无时间限制的应用系统，并不需要QoS，比如Web应用，或E-mail设置等。但是对关键应用和多媒体应用就十分必要。当网络过载或拥塞时，QoS 能确保重要业务量不受延迟或丢弃，同时保证网络的高效运行。
ITU将服务质量定义为决定用户对服务的满意程度的一组服务性能指标。从另一角度来说，QoS参数也是流媒体媒体传输的性能指标。主要的QoS参数有如下几项：传输带宽，传输时延和抖动，丢包率。
3.1.传输带宽
传输带宽也指的是数据传输的速率。对于流媒体的播放，影响最大的属性就是传输带宽。如果带宽过低，使得数据传输下载的速度小于视频流播放的数率，那么在视频的播放将会经常出现停顿和缓冲，极大的影响了客户观看的流畅性；而为了保证视频观看的流畅性，在低带宽的条件下，只能选择低品质、低码流的视频进行传输，这样又会影响到客户的光看效果。所以，一个良好的传输带宽环境是客户活动高品质的流媒体体验的重要保证。
3.2.传输时延和抖动
传输时延定义为从服务器端发送数据到接受端接收到该数据之间的时间差，它是用来描述网络时延的一个指标。时延抖动定义为网络传输延时的变化率。流媒体最重要一个特性的就是实时性强，所以流媒体通信需求更难于满足的是对通信系统的传输时延限制。时延限制主要是用在具有实时性要求的交互分布式实时流媒体应用中，如视频会议系统，为防止时延给交互式通信带来不便，建议的最大端到端的总时延不要超过150ms，否则交互双方会感到明显的时延，给双方的信息交流带来不便。端到端的时延可分为以下四个部分：
3.2.1．信息源的媒体采样、压缩编码和打包的时延；
3.2.2．传输时延；
3.2.3．接收端的排队和播放缓冲时延；
3.2.4．接收端的拆包、解码和输出时延。
抖动定义为网络传输延时的变化率。时延抖动对流媒体播放质量的影响非常大，一般会采用缓存排队的办法平滑数据报的抖动。但如果数据传输的抖动较大，则必须采用大的缓存，这将直接造成更大的时延，直接影响流媒体的体验效果。
3.3.丢包率
流媒体数据传输中的时延和抖动是可以通过缓存的办法减少影响，所以流媒体业务可以允许在一定范围内的时延和抖动。但丢包会对流媒体数，据播放质量造成极其重大的影响。丢包率会造成视频和音频质量严重恶化，小的丢包率会造成图像的失真和语音的间歇中断，过高的丢包率甚至可以导致业务的中断。网络设计的目标是丢包率为零，但显然不存在这样的理想网络。所以丢包的大小将直接决定流媒体业务质量的好坏。
4.参考的原文：
http://www.cnblogs.com/mr-nop/archive/2013/08/28/3287402.html
http://blog.csdn.net/leixiaohua1020/article/details/18893769
http://www.cnblogs.com/gnuhpc/archive/2012/12/10/2812095.html
http://blog.csdn.net/demon_evil/article/details/2097156
http://www.cnblogs.com/ansersion/p/7514035.html
http://www.cnblogs.com/gnuhpc/archive/2012/12/10/2812095.html
http://blog.csdn.net/leixiaohua1020/article/details/18893769
https://github.com/EasyDarwin/Course