TSINGSEE青犀视频平台设计中对流媒体的能力考虑的非常全面，既考虑了实时性、也考虑了服务器性能、网络带宽压力，同时也有考虑并发情况的兼顾，此节我们对按需和非按需拉流再做一次解释。
在做解释前，先给大家做个科普，TSINGSEE青犀视频的流媒体平台都采用了优秀的前后端分离设计，让专业的人做专业的业务逻辑。有人肯定疑问为什么要先阐述此点？因为正是采用了这种设计，我们可以把TSINGSEE青犀视频流媒体平台的前端可以看做是一个前端DEMO示例，完全可以自己做一套替换流媒体平台的前端页面。
按需拉流
所谓按需拉流，其实就是字面意思，根据需要再去拉流。根据需要实质上是指有客户端请求，也就是有客户端请求的时候，流媒体服务再去找前端设备进行拉流处理，拉流->解封装->再封装->分发，此目的是为了节省带宽压力，因为前端设备有可能是通过无线网络连接，或者前端网络的压力已经很大，这样做的好处就是根据需要随时调用，把带宽的利用率有效提高。
但是此方法也有一些弊端，比如起播速度慢，因为音视频数据从设备编码产生到播放器解码渲染到窗体不是一直在进行中，而是按需调用才起作用。
非按需拉流
所谓的非按需，其实就是一直拉流这种模式，通俗解释就是流媒体一直从前端设备把音视频拉取，不中断，不管有没有客户端的播放需求，流媒体服务都一直再做拉流->解封装->再封装->分发的工作，此方法必然会带来网络压力的增加，因为不管有没有客户端的播放请求，服务端一直要跟前端设备拉流处理，但是可以做到秒开，因为客户端随时要起播，服务端都有数据，不用等前面设备编码产生、传输、解码再得到流数据。
然而此方法对服务器的压力其实也是很大的，因为目前解封装->再封装都是在内存里面完成的（HTTP-HLS除外），可以相信几百路音视频一直拉着在内存中处理，对服务器压力可想而知有多大。
流媒体并发
再跟大家阐述关于流媒体并发能力的一些知识。
TSINGSEE青犀视频流媒体平台内核是基于Nginx改良的，可以有效面对处理高并发访问，但是分发的每种协议流的并发能力又不是一样的，比如HTTP-HLS此种分发流，其实它最大的并发瓶颈不是在与程序设计能力，而是磁盘的读写性能，因为HTTP-HLS严格意义上来说不是实际的直播流协议，它是写ts切片文件到磁盘，然后播放端不断的再去请求下载此资源去播放。
HTTP-FLV、WebSocket-FLV、WebRTC技术现在已经很优秀了，因为FLASH逐渐被淘汰后，RTMP协议流在WEB再想播放确实要费点劲了，要么用其它插件，要么就是转码了。上述的三种播放流因为都在内存中处理，只要服务器性能跟得上，带宽跟得上，并发能力几乎没有问题。