这个问题实在是一个旧调重弹的问题，视频文件大，下载（播放）就慢，文件小自然就顺畅，这很大略的道理实在是个两端问题——
客户端：视频码流大于客户本地网络带宽就会卡顿。
做事端：如果做事器端看视频的人一多，占用的带宽一大，同样会卡。
之前也有大略粗暴的办理方法：把视频尽可能的压缩，文件小了播放自然就顺畅，但随之而来的时画面模糊声音粗糙，会严重降落用户体验。
于是：视频切片技能就来了——
视频切片：顾名思义将视频文件切成多少小视频进行播放或传输。这里有一个很主要的技能要点——涉及到磁盘读取文件的底层逻辑、视频播放前的准备事情，例如：操作系统会检讨文件是否完全、播放器会检讨媒体文件的时长、编码格式等等。
比如一个200M的视频，cpu接到指令、从硬盘读取、载入内存；这个过程实在是一个单线程过程，行业内叫“文件预读”，以是大文件载入会比小文件慢得多。
如果我们把一个200M的视频文件，切片成10个20M的文件，cpu的多线程也就能发挥浸染，同步把10个或20个文件一起载入内存。仅仅就这个环节就节约了大量韶光。
接下来是播放器的预读过程（本地播放器或浏览器的video标签基本一样），取到一个媒体文件快速读取媒体信息，时长等等，小文件要频年夜文件快得多。
末了是网络传输：浏览器中大文件虽然目前也支持断点续传、分割下载，但对视频文件而言，这功能基本没用；每个视频文件都有“元数据”，一样平常保存在视频的开头位置，元数据指的是：视频编码、音频格式、字幕信息、时长等等； 浏览器如果逼迫把一个视频分割下载，那分割出来的“文件块”由于没有元数据支持，以是依然无法被播放。
以是综上而言：视频切片是一个提高传输效率的终极办理方案，目前各大视频平台都用了这个技能，大略地说——切片便是把一个视频文件按照每5-10秒切成小视频，每个小视频有独立的“元数据”，每个小视频片段实在都是一个完全的视频格式，从而知足随意韶光轴播放的需求。
m3u8格式很多人该当不陌生，这是基于网络传输的一种“文件索引”格式，它就彷佛一个目录，见告浏览器本次播放的任务清单，例如——一个电影切成了1000片，这个索引就有1000个切片文件的文件名和顺序，浏览器随着它播就行。
软件主界面
本软件便是基于这个事理，将视频进行切片，可以知足互联网多线程传输播放，在一个很小的带宽环境下，即可实现流畅播放。
由于视频文件已经切片，对恶意下载多了一层保护，下载者须要把成千上万的视频切片下载完后进行拼接，才能还原视频。增加了视频被盗的技能本钱。各大视频网站实在也就做到这一步而已，当然了也可以延伸加密技能，但不在本文谈论范围内。
代码片段
软件我本着职能单一的原则开拓，没有那么多赞助功能，大略小巧就把一件事高效率的干好。
web端播放效果
web端播放支持随意拖动，延迟比较大文件而言有了质的飞跃。
web端渲染后的代码片段
web端仅仅能看到blob开头的播放地址，从一定程度上可以加大被盗下载的门槛，至幼年白很难搞定。
做事器端切片后的文件
澄清一个误区：
本文提出的内容和编程环境、做事器环境均无关系，实质上这是一个视频文件传输和播放的办理方案。无论是微软系得IIS、Java系得Tomcat、或者Nginx等所有web做事器都能精确发布。
切片视频用的是hls协议，这个协议有很多高大上的阐明，归根结底便是“切片协议”，m3u8上面说过便是切片后的视频碎片目录（一个文本文件），记录着片段顺序等信息。
以是你本地web播放，就不能用纯video标签了，html5的纯video标签是无法播放m3u8列表的，须要下载一个hls.js的库就行了。
如果你被视频播放卡顿等问题缠身、对直播系统、点播系统有更深入的想法，欢迎谈论。
