过多的专业常识那里就不讲了，内容比力多。
目前收集上的视频曲播，100%都接纳下面的体例实现。
1.简单说，起首是会场摄像机拍摄画面。
2.摄像机通过AV、SDI等体例输出实时信号（收集摄像头可以间接输出IP流，但纷歧定契合流媒体尺度，一般情况下无法间接利用，仍然需要停止第二步的处置）
3.流媒体编码器（Streaming Encoder）将AV、SDI等信号实时编码为H.264 TS/FLV的IP流（能够通过IP地址拜候的媒体流），在编码同时，一般还会停止分片处置（那个概念后面零丁讲）
4.流媒体办事器/流媒体软件（Streaming Server/Streamer）拉取编码器输出的IP流，并对那个IP流停止缓存和分发
5.若是希望将曲播内容保留为文件存档，还需要停止收录(Ingest)。收录分为信号收录和流媒体收录，也就是间接将AV、SDI等传统信号重编码+封拆保留（转码收录），或间接利用流媒体收录将IP流原封不动的封拆（没有停止重编码，叫源码收录）
分片处置：因为如今的挪动设备操做系统，大多都接纳HTTP协议来实现流媒体曲播（Android还能够用RTMP，但已经处于逐渐被裁减的地位），因而所谓的曲播，现实上是由良多段时间很短的碎片视频文件构成的。以iOS为例，曲播流是以m3u8播放列表形式停止下发的（m3u8是一个播放列表文件，凡是大小只要几kb，而此中包罗的是良多ts视频文件的现实地址）。分片的时间间隔越短，视频缓冲所需的时间也就越短，也不容易呈现长时连续流等情况。而码率越高，分片间隔建议就按情况缩短。
别的，正都雅见知乎以前的一个发问，说为何视频网站点播节目标时间线/进度条拖动都不克不及很准确定位到某一个时间点，而是前后有误差：
为什么通过 Flash 旁观流媒体视频时，在进度条拖拽的效果老是禁绝确？其时有人给出的谜底是因为分片形成的办事器压力。
而现实情况不是如许。分片不会给办事器自己形成压力，只会对内容存储设备的读写性能形成压力，所以分片不会是拖动禁绝确的原因。
原因是，目前几乎100%的支流视频网站都接纳H.264编码和FLV封拆。H.264编码的特点就是包罗关键帧和预测帧（详情请查询视频编码的GOP及IPB帧摆列）。而对H.264拖动时，只能定位到关键帧。因为收集视频更讲究压缩率，而非量量，因而会呈现一个关键帧对应很长一串预测帧的情况。
同时，FLV封拆和MP4封拆类似，一般不包罗分片信息，所以只能依靠文件头里面的关键帧索引来停止Seek，H.264+FLV连系起来，Seek准确度就不高了。
而HTML5无论曲播和点播，都是基于HTTP协议，都存在分片概念，文件封拆也是多个碎片化的ts而非整段flv和mp4，所以HTML5播放器播放的视频，Seek切确度相对高良多，但也会因为收集视频的长GOP而有必然的误差。
再扩散一下：H.264现实是可以做到帧切确的，那就要求编码时接纳短GOP。如许做的成果是，压缩率相对较低，对收集传输要求较高，所以合适视频编纂等范畴利用。