目录
如同物流体系里物流中心的概念一样，流媒体服务器负责内容的高效分发。
虽然由于近年基于HTTP的流媒体协议大行其道，通用HTTP服务器附加流媒体协议插件的方案广泛应用，侵占了支持多协议的专用流媒体服务器的市场份额，但鉴于通用HTTP服务器和专用流媒体服务器之间对于高I/O、高并发、低延迟以及高可靠的追求高度一致，充分理解相关技术仍然对流媒体体系的搭建和优化非常重要。
功能需求囊括点播和直播两类。
直播服务则需要先将基于IP网络，由流媒体协议封装的音视频流导入服务器，再通过服务器转化成不同设备可以接收的流媒体封装，发送给各个客户端。
客户端支持
协议支持
不论点播，还是直播，由于不同的流媒体协议规定了不同的传输格式，也即对相同的音视频编码格式基础上采取了不同的封装，所以服务器主要的工作是
1、将文件转化为流媒体协议
2、流媒体协议转化为文件
3、一种流媒体协议转化为另一种流媒体协议
转化时根据文件格式和流媒体协议格式进行解包和封包（英文是Packetize和De-packetzie）
以H.264和AAC格式的音视频内容，在传输时需要封装为NAL格式和ADTS、LOAS格式，再封装到不同的协议包中，例如RTP包、TS包等，以此为单位发送或接收。
自服务器到客户端的流媒体传输，利用了前文介绍的MPEG2-TS、RTSP/RTP、RTMP、HLS、MPEG-DASH等协议。
MPEG2-TS和其他流媒体协议的不同之处在于，它只能用于主动推流的Push模式，而其他协议可能采取Pull或Push两种不同模式。
MPEG2-TS主要适用于有线电视领域，任何用户默认都是持续接收电视节目，其他协议则在设计时较多地考虑由客户端按需发起流媒体的传输连接。服务器导入直播流时，于不同的场景可以采取Pull和Push两种方式。
流媒体服务器常见的应用位置是视频网站的源站，以及CDN服务中包括源站（Origin）、中间站（Proxy）、边缘站（Edge）在内的各级节点，构成视频分发的核心。
专门的CDN服务商需要对服务器进行改造，实现VirtualHosting功能，其主要概念是对一台服务器进行虚拟化拆分。由于客户大小不同，对不同地域的边缘服务大半仅是零散地使用，为每个客户单独分配计算、存储和网络资源并不经济，其使用的流媒体服务器，可以根据用户请求的资源信息或Cookie分辨出其来自于哪家客户，在服务器内部的按需分配资源和计费。
应用特点
针对于点播流：
对HTTP服务器而言，需要缓存的文件片段是基于Range请求获得的。
可以假设是某一个文件的从3000到7000字节，但于音视频文件则略有不同，由于视频关键帧概念的存在，获取或存储不完整的GOP数据并无意义，因此不论返回用户请求的内容还是在本地缓存音视频片段，都以贴近所请位置的GOP为单位较有效率，此时缓存中应有音视频片段对应的时间戳信息以便索引。
针对直播流：
因为用户可以从任意时间开始观看，为节约带宽并加快播放启动的速度，服务器应从自身持有的音视频流的队列中找到关键帧，由该处起始服务，避免发送不完整的GOP数据。
当用户在不同频道间切换时，如果音视频格式相同，流媒体服务器可以使用当前与用户之间的连接，从新频道的关键帧开始发送等方法（见图4-25），达到最佳的用户体验。
（直播流的频道无缝切换）
因为视频流的传输受到带宽、网络传输稳定性、客户端等待渲染等多方面限制，从编码器、源站服务器、代理服务器到边缘站服务器，以及播放器本身，每一个环节都会保持一份缓存，这有助于整个传输过程的流畅，但代价即是播放器的播放存在延迟，若在直播情况下，还将导致看到的节目系数秒乃至数十秒之前所发生的内容。服务器内部通常维护的Packet队列，可根据不同场景调整大小，在直播特有的追求低延时的场景下，该队列甚至可以被取消，即服务器收到任一Packet都会立刻处理转发。
流媒体服务器由于其流式服务的特性，对可靠性提出了极高的要求，毕竟用户偶尔访问网页失败，只需刷新重试即可获得服务，但视频播放中途失败对用户体验的打击要大得多，直播用户可能希望继续观看适才错失的片段，点播用户则预期观看进度可以被自动恢复。
较苛刻的服务器测试会构造各种模拟应用，经历7天或更长时间的播放测试，覆盖时间戳溢出，频繁播放等用例。对直播服务在高并发环境下仍要求全天候无中断的要求，服务器需支持热备份，可行的方式是预先配置多个冗余的直播流，服务器负责判断和切换，下图给出了一种直播流冗余备份方案的示意。
（一种直播流的冗余备份方案）
广告投放
不论点播抑或直播，对广告的动态插入均是普遍需求，根据广告投放的人群不同，其插入的位置有所不同。
对于直播服务：
例如，若将一份广告如同电视频道一样期望投放给所有用户，则首先适合在网站的编码侧直接编入直播流中，次选则是网站的直播源服务器上，替换原节目中的若干GOP，此时如广告长度和被替换的GOP不同，可以考虑对广告进行重新编码，丢弃部分帧，对整个直播节目的Timeline进行调整等手段。
如果希望可以针对不同人群投放不同广告，尤其是基于地理位置的投放，则投放可以在边缘站的流媒体服务器上进行。
对于点播服务：
对于点播服务，可行的做法是直接嵌入广告内容到实际内容之前
之后或某两个GOP之间，此时需由服务器调整Timeline[插图]，保证播放的连续性。由于在已有音视频节目中嵌入广告的技术复杂性，更实用的方法是向播放器提供形成包含广告和实际节目的播放列表，将Timline的调整交由客户端完成。
针对直播服务的另一项常见需求，是用户选择对其中某个片段进行录像，以便日后回味。在流媒体服务器上开发这项功能是常见的选择，其中，与摄像采集设备一样对音视频流编码没有必要，相反，由于不论视频还是音频，各个流媒体协议定义的Packet都包含时间戳信息，对于视频有每一帧的起止信息和是否关键帧的标记，很容易将其收集并转换为视频文件。
No comments yet.