我有个客户在自己的官网给用户*放播**视频，由于视频高清时长又比较长，导致用户端*放播**视频时很卡顿……
这个问题其实是一个老生常谈的问题，视频文件大，*载下**（*放播**）就慢，文件小自然就顺畅，这很简单的道理其实是个两端问题——
客户端：视频码流大于客户本地网络带宽就会卡顿。
服务端：如果服务器端看视频的人一多，占用的带宽一大，同样会卡。
之前也有简单粗暴的解决方法：把视频尽可能的压缩，文件小了*放播**自然就顺畅，但随之而来的时画面模糊声音粗糙，会严重降低用户体验。
于是：视频切片技术就来了——
视频切片：顾名思义将视频文件切成若干小视频进行*放播**或传输。这里有一个很重要的技术要点——涉及到磁盘读取文件的底层逻辑、视频*放播**前的准备工作，例如：操作系统会检查文件是否完整、*放播**器会检查媒体文件的时长、编码格式等等。
比如一个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的库就行了。
如果你被视频*放播**卡顿等问题缠身、对直播系统、点播系统有更深入的想法，欢迎讨论。