一、基础知识
(修改一下标题，好完善继续这个系列)
我们常说的流媒体开发，实际包括两部分（一）编解码，（二）控制与传输协议。
（一）编解码
我们现在常用的编码协议是H.264协议，是MPEG-4协议的第十部分，其图像压缩技术更好，也就更好的适合在低速网络上使用。它的继任者是H.265协议，即高效率视频编码（High Efficiency Video Coding，简称 HEVC），图像压缩技术上更进一步，而且可以支持更高的分辨率。
（二）控制与传输
这里有一系列的网络协议，包括：
实时传输协议RTP（Real-time Transport protocol）
实时传输控制协议RTCP（Real-time Transport Control protocol）
实时流协议RTSP（Real Time Streaming protocol）
资源预留协议RSVP（Resource Reserve Protocol）
1）RTP
RTP是进行端对端传输服务的实时传输协议，通常使用UDP来实时传送音视频数据。RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。载荷封装设计的网络传输是基于IP协议，所以最大传输单元(MTU)最大为1500字节，在使用IP／UDP／RTP的协议层次结构的时候，这其中包括至少20字节的IP头，8字节的UDP头，以及12字节的RTP头。这样，头信息至少要占用40个字节，那么RTP载荷的最大尺寸为1460字节。以H.264 为例，如果一帧数据大于1460，则需要分片打包，然后到接收端再拆包，组合成一帧数据，进行解码播放
2）RTCP
RTCP一般通过TCP协议与应用层的控制中心联系交互，负责提供已经发送的数据包的数量、丢失的数据包数量和数据包的抖动等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTCP和RTP配合使用，不仅可以用来实时获取反馈，控制流量和拥塞控制，还可以实现一对多的广播模式，即一个发送端，对应多个接收端的模式。在会话生存期间，接收端也会收到RTCP数据包，并通过端口号与RTP数据包区分。
3）RTSP
RTSP是应用级的实时流放协议，它主要目标是为单目标广播和多目标广播上的流式多媒体应用提供牢靠的播放性能，以及支持不同厂家提供的客户机和服务机之间的协同工作能力。RTSP的定义描述在RFC 2326文件中。它的所有的操作都是通过服务器和客户方的消息应答来完成的，其消息包括请求（Request）和响应（Response）两种，RTSP正是通过服务器和客户端的消息应答来完成媒体流的创建、初始化（SETUP）、控制（PLAY、PAUSE）以及断线（TEARDOWN）等操作的。不过在做这些之前，需要有一个演示描述（Presentation description）文件，利用该文件提供的信息定位视频服务地址（包括视频服务器地址和端口号）及视频服务的编码方式等信息。由客户端向服务端申请获取。整个过程类似于Socket套接字的工作方式。
4）RSVP
RSVP协议是一种可以提供音频、视频、数据等混合服务的互联网络综合服务（IIS Internet Integrated service ) [RSVP97,RFC1633]。通过它，主机端可以向网络申请特定的QoS，为特定的应用程序提供有保障的数据流服务。同时RSVP在数据流经过的各个路由器节点上对资源进行预留，并维持该状态直到应用程序释放这些资源。RSVP虽然工作在OSI模型的传输层，但本身并不处理传输层的数据，更像是底层的控制协议，在后台执行。RSVP进程通过本地的路由数据库来获取路由信息，路由协议决定报文的走向，RSVP仅关心这些报文在它将走的路径上能否获得满意的服务质量。RSVP采取由接受端发起服务质量（QoS）申请的策略，接收到客户端的申请后，RSVP驻留进程将该请求递交给沿数据传送的反向路径（接受端至发送端）上的各个节点（路由器或是主机）进行资源的申请。因此要注意的是，RSVP协议在资源保留上花费一般是呈对数而不是线形幅度增长。
RSVP采用的是组播【一次将数据包复制到多个通道上，信息可以发送到组内任意地址的客户机，以减少网络上传输的信息包的总量】的方式，避免了点播和广播的缺陷。
另外基于HTTP渐进下载模式的RTMS、HLS等企业自行开发的流媒体传输协议，像HLS多用于直播。