本文转载自薰衣草的旋律的crtmpserver系列(一)：流媒体概述，如有侵权，请联系删除。
概述
所谓流媒体按照字面意思理解就是像流一样的媒体，看起来像是废话。流媒体现在司空见惯，所以一般人大概不会有疑问。事实上在流媒体还没有出现的时候，基本上通过网络播放电影就不太现实。通过网络播放电影的时候必须先将整个文件下载到电脑上然后才能播放，所以一般都要缓冲很久，这也是为什么最开始迅雷等下载工具流行的原因，其实大多数都是用来下电影了。
流媒体最大的特点即是能够做到边下载边播放，而不需要预先将整个文件全部下载完成之后才能播放，这样极大的改善了用户体验，也提高了实时性，使得网络直播成为可能。
那么流媒体是如何做到边下载边播放的呢，我们要了解流媒体系统的组成。
流媒体系统的组成
一个完整的流媒体系统由这些部分组成，信号采集，编码，传输，解码，输出。
信号采集
我们所说的流媒体系统都是要在计算机系统上面进行处理的，而系统中最主要的元素是音频和视频，从物理上面来说音频实际上是一种通过物理震动形成的机械波，音频采集即是将这种物理波转换为电信号进而转换成二进制的音频数据，一般采集得到的原始音频数据是 PCM 数据。
视频是什么，视频实际上是顺序呈现出来的一幅幅连续的静止图像，所以视频实际上是由一幅幅静止的图像组成，视频的采集就是连续不断的采集这些静止的图像的过程，这些一幅幅的图像一般被称为帧。那么这些被称为帧的静止图像又是怎么被采集的呢，实际上图像的表现形式并不是像声音一样的波，初中的物理我们就学过成像，我们之所以能够看到图像，是因为照射在物体上的光反射到我们的眼睛进入视网膜，传导到视神经最后被我们大脑感知。所以图像的采集是对光信号的采集与转换，将光信号转换为二进制的图像帧的过程，一般我们得到的原始图像数据格式是 YUV 格式。
编码
什么是编码，为什么要编码。假设我们的网络容量是无限的，传输速度也是无限大的，这当然是不需要编码的。而实际上并不是，我们采集到的原始音视频数据量是很大的，所以我们需要想办法，将采集到的原始的音视频二进制数据量尽量变小，方便在网络上进行传输，同时又需要在还原(解码)的时候尽量接近原始音视频(损失，编码也有分为有损和无损)。我们有时候称编码也叫压缩编码，其实压缩这个概念类似我们平时的压缩文件的原理一样，在最常见的概念中，有帧内压缩和帧间压缩。
-
帧内压缩：假设一副图像的背景是纯红色，前面站个人(拍证件照的场景)。在编码的时候一副图像被分成很多小块(宏块)，这样由于背景中会有很多相邻的小块都是纯红色，很多纯红色的小块都可以根据其周围的小块推断出来，而不需要单独编码，这就是帧内压缩，这种压缩是在一个帧内部进行的，跟其前后的图像没有关系。
-
帧间压缩：如果一个视频中相邻的 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 了。还有一个需要特别提到的，HTML5 出来之后，很多以前通过 flash 客户端承载 RTMP 协议的播放方式被以 HLS 替换了。但是实时性要求比较高的直播还是需要通过 RTMP 或者 RTSP 协议。HLS 严格来说，其实我感觉都不能叫流媒体协议，HLS 实际上基本可以认为是一个 TS 文件的播放列表，没有流媒体协议中的那些逻辑功能，播放，暂停，停止。应该说 HLS 仅仅是特定情况下出来的，主要是针对跨平台的浏览器进行直播。我们所看到的 HLS 大部分都是通过移动设备，PC 机器上的浏览器来播放的。而微软的 MMS 基本在工作中接触的不多，特别是当前比较火爆的互联网直播。
需要指出的是，在与苹果的 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。