共计 1071 个字符，预计需要花费 3 分钟才能阅读完成。
前言
现如今，大部分带内容的网站或利用都有视频区了，不说是大厂平台，就连集体开发者也相继在本人网站或小程序上迭代出视频板块。那既然有了视频模块，除个性化举荐，智能审核等这种费钱又耗时的性能外 (集体开发者暂缓)。最根本的视频上传，视频播放天然必不可少吧。
既然要强调省钱，我以后不会对接点播服务了。毕竟为了有肯定的审核和举荐性能，我打算做人工审核。那剩下的对于播放有肯定的体验度，还得要用一下 OSS 了 (还是要花一点嘛)。因为上传有现成的分片上传，播放有 HLS 流，以下着重讲对于视频播放的优化，上传局部就说一下思路哦。
视频上传
因为网站对于上传只有一些图片，所以只用了 OSS 的惯例文件上传。然而视频，不说长视频，当初一些略微几十秒的短视频动则几十兆上百兆，更别说高清的。而且晚期的上传是放在服务端实现，所以当客户端提交大型文件时，不光 nginx(413 Request Entity Too Large) 和 fpm 会报错，到了 OSS 客户端调用也会报错 (Allowed memory size of 268435456 bytes exhausted (tried to allocate 67108896 bytes))。
开始是尝试在服务端改成分片上传，然而测试时发现，每次提交文件过去时都要先将视频本地化，存在服务器上后再分片提交到 OSS，回调胜利删除服务器文件，并且要调整 nginx 等的提交的最大值限度。最初就决定把上传局部放到了前端，服务器只提供 OSS 的长期拜访凭证和接管上传胜利回调。
视频播放
对于视频播放，网站晚期的做法是将 OSS 的视频地址间接丢到前端的 video 标签中，当在手机播放时会呈现卡顿或播放迟缓等问题。最初决定应用 OSS 的 HLS 的构建，就是在后盾将视频推流一份在 OSS 的 LiveChannel 中，前端通过读取 m3u8 播放视频。
思路：
- 前端上传视频，后盾审核胜利调用 OSS 的 LiveChannel 创立。
- 依据通道创立返回的推流地址和播放地址，存入数据库。
- 在服务端起一个过程用 FFMPEG 进行视频推流。
- 前端播放视频时抉择 m3u8 的形式。
