所谓流媒体按照字面意思理解就是像流一样的媒体，看起来像是废话。流媒体现在司空见惯，所以一般人大概不会有疑问。事实上在流媒体还没有出现的时候，基本上通过网络播放电影就不太现实。通过网络播放电影的时候必须先将整个文件下载到电脑上然后才能播放，所以一般都要缓冲很久，这也是为什么最开始迅雷等下载工具流行的原因，其实大多数都是用来下电影了。
流媒体最大的特点即是能够做到边下载边播放，而不需要预先将整个文件全部下载完成之后才能播放，这样极大的改善了用户体验，也提高了实时性，使得网络直播成为可能。
那么流媒体是如何做到边下载边播放的呢，我们要了解流媒体系统的组成。
一个完整的流媒体系统由这些部分组成，信号采集，编码，传输，解码，输出。
信号采集：我们所说的流媒体系统都是要在计算机系统上面进行处理的，而系统中最主要的元素是音频和视频，从物理上面来说音频实际上是一种通过物理震动形成的机械波，音频采集即是将这种物理波转换为电信号进而转换成二进制的音频数据，一般采集得到的原始音频数据是PCM数据。视频是什么，视频实际上是顺序呈现出来的一幅幅连续的静止图像，所以视频实际上是由一幅幅静止的图像组成，视频的采集就是连续不断的采集这些静止的图像的过程，这些一幅幅的图像一般被称为帧。那么这些被称为帧的静止图像又是怎么被采集的呢，实际上图像的表现形式并不是像声音一样的波，初中的物理我们就学过成像，我们之所以能够看到图像，是因为照射在物体上的光反射到我们的眼睛进入视网膜，传导到视神经最后被我们大脑感知。所以图像的采集是对光信号的采集与转换，将光信号转换为二进制的图像帧的过程，一般我们得到的原始图像数据格式是YUV格式。
编码：什么是编码，为什么要编码。假设我们的网络容量是无限的，传输速度也是无限大的，这当然是不需要编码的。而实际上并不是，我们采集到的原始音视频数据量是很大的，所以我们需要想办法，将采集到的原始的音视频二进制数据量尽量变小，方便在网络上进行传输，同时又需要在还原(解码)的时候尽量接近原始音视频(损失，编码也有分为有损和无损)。我们有时候称编码也叫压缩编码，其实压缩这个概念类似我们平时的压缩文件的原理一样，举个简单的例子，例如有一个文本文件其内容是00000000000000000000000000000000000000000000000000 这么一串字符串，实际就是50个0字符，我们完全可以用最简单的描述来压缩，例如我们压缩之后文件内容变成50’0’表示这里有50个0字符。在还原的时候这里直接用50个0字符填充即可，这样是不是会节约大量的空间呢，如果不是50个0而是一万个0字符呢，这样经过压缩之后的压缩比会更大，也就是说重复的冗余数据越多，压缩效率越高。当然实际的压缩算法肯定没这么简单，说这么个简单的例子只是为了说明原理而已。视频的编码算法有很多种，而且要复杂很多，每一种算法的运行效率，压缩比，损失率都不一样。而原理都是一样的，在最常见的概念中，有帧内压缩和帧间压缩。
什么是帧内压缩呢，假设一副图像的背景是纯红色，前面站个人(拍证件照的场景)。在编码的时候一副图像被分成很多小块(宏块)，这样由于背景中会有很多相邻的小块都是纯红色，很多纯红色的小块都可以根据其周围的小块推断出来，而不需要单独编码，这就是帧内压缩，这种压缩是在一个帧内部进行的，跟其前后的图像没有关系。
那么帧间压缩又是什么，如果一个视频中相邻的2副图像，背景都是纯红色，背景中有一个球在图像1中的位置是A点。在图像2中的位置是B点。实际上如果把图像1和图像2叠在一起会发现他们除了球的位置不一样之外，其他的部分是一样的，也就是说这两幅相邻的图像有很大一部分是相同的。在编码第2副图像的时候完全可以只编码其与上一副图像的不同部分。如果图像1我们需要完全编码，图像1被称为关键帧(一般称为I帧)，而图像2在还原的时候需要参考图像1，所以称为参考帧(一般称为P帧)。如果没有关键帧，那么参考帧是无法还原的。当然在编码的时候，一帧不仅可以参考其上一帧，还可以参考其下一帧(双向预测的帧间压缩)，例如一个球从左滚到右，这种运动是可以做预测的。这种当前帧的编码参考其相邻图像的算法就是帧间压缩算法。
传输：经过采集，编码我们现在已经获得了音视频数据帧，但是一般观看视频的一定不是在采集编码的现场，否则就不需要传输了，传输的过程就是将编码后的音视频数据通过网络(互联网，或者有线电视网等，我们只讨论互联网)传输到希望观看的观众那里。数据从一个地方传递到另一个地方这个过程就是传输。传输过程中最重要的当然是流媒体协议了，为什么还需要流媒体协议？在流媒体播放的时候会有一些播放逻辑，例如，播放，暂停，跳转，停止，快进，快退。另外在编码之后的数据从一端传递到另一端，另一端需要将编码之后的数据还原成编码之前的原始数据才能播放。如何还原？必须得知道之前编码是使用什么算法编码的，在还原的时候才能采用相应的解码算法进行还原。那么编码的时候使用的是什么算法，这个也需要从一端通知到另一端，这个信息也是在流媒体传输协议中会有的。除此之外还会有其他的一些逻辑信息，例如视频的帧率，关键帧的间隔(GOP Size)等。总结为一句话，编码过后的音视频数据通过网络从一端传递到另一端，在另一端对数据还原的时候需要一些信息，并且需要支持一些播放场景的逻辑，这些都需要在流媒体协议中进行描述。目前最流行的流媒体协议，Adobe公司的RTMP，RTSP，微软的MMS等。
解码：经过编码压缩的数据必须还原成编码之前的原始数据才能播放显示，这个还原过程就是解码的过程。
输出：输出的过程就是播放出来的过程，与采集的时候一样，实际上这是将采集的原始音视频数据经过模数转换转换成物理信号，视频信号通过显示器显示出来，音频信号通过音箱放出来。
我们之前讨论的是媒体的流式播放，其实这个流式主要是指传输是流动的，而且视频帧可以边传输，边解码播放。如果我们希望将播放的内容保存到磁盘上，就必须要有一种文件格式来组织这些数据，以一定的结构来保存这些音视频数据。为什么不直接将网络传输过来的内容直接写到一个文件中保存呢，如果直接将所有传输过来的数据不加任何结构组织直接保存的话，那么在播放的时候如何播放？如何知道这些二进制数据哪些是音频哪些是视频，如何知道每一帧音视频数据在文件中的边界，如何知道该音视频的内容是通过什么编码算法编码的，如何知道播放一帧数据之后再隔多长时间播放下一帧数据，如果像有的电影文件需要多种字幕又如何组织。所以这就必须要有一种文件格式能够组织这些音视频数据并且附加这些播放必须的信息在文件中。这就是媒体文件的封装。现存有很多种媒体文件，有的是某个公司的专利，有的是国际标准，例如MP4，MP3，AVI，RMVB等等等等。所以如果要保存这些流媒体数据到文件中，则必须通过一定的文件封装格式将这些音视频数据保存在具有一定格式的媒体文件中。
目前使用的最多的流媒体传输协议当然是RTMP和RTSP了。微软的MMS基本在工作中接触的不多，特别是当前比较火爆的互联网直播。还有一个需要特别提到的HTML5出来之后，很多以前通过flash客户端承载RTMP协议的播放方式被以HLS替换了。但是实时性要求比较高的直播还是需要通过RTMP或者RTSP协议。HLS严格来说，其实我感觉都不能叫流媒体协议，HLS实际上基本可以认为是一个TS文件的播放列表，没有流媒体协议中的那些逻辑功能，播放，暂停，停止。应该说HLS仅仅是特定情况下出来的，主要是针对跨平台的浏览器进行直播。我们所看到的HLS大部分都是通过移动设备，PC机器上的浏览器来播放的。
需要指出的是，在与苹果的HLS争夺市场的过程中，同时出现了多种类似的技术，都是用的HTTP协议，一般我们称为HTTP渐进式下载。例如微软的Live Smooth Streaming 中文名称为直播平滑流，这种技术需要微软IIS7及以上版本的web服务器和Silverlight客户端支持。另外一种是开源的技术好像并不是某个公司出品，叫Http Pseudo-Streaming 中文名是伪流。目前只看到一个基于Apache服务器的插件H264 Streaming Module for Apache，客户端貌似也是使用Flash Player。还有一种叫HTTP Dynamic Streaming 中文称做HTTP动态流，是Adobe公司的技术方案，其服务端需要Flash Media Server支持，客户端则是Flash Player。其实现在的Flash Media Server 也已经支持HLS了。苹果的HLS就不说了现在很多服务器以及开源代码都支持HLS，客户端呢只要支持HTML5的浏览器基本也都支持HLS，现在的HLS已经是主流。最后要说的是新出现的一种技术标准，MPEG-DASH目的为了统一这些技术方案，还在标准化中，如果真的标准化，也有可能取代HLS，毕竟HLS还没有称为正式标准，只是苹果公司提交了个草案。
RTMP协议的发展得益于flash播放器的广泛传播，而RTSP协议则得益于其协议的开源。本系列要讲解的crtmpserver就是基于RTMP协议的开源流媒体服务器，开发语言为C++。等同的产品还有Red5 语言为Java也是开源。另外一个比较有影响力是wowza属于闭源产品。此外RTMPDump项目是用的比较多的RTMP客户端开源项目，其中的librtmp库使用的很广泛，C语言编写。另外OpenRTMFP是基于p2p技术的RTMP。
尽请期待crtmpserver的后续章节。
原文：http://www.cnblogs.com/wangqiguo/p/5965292.html