前言：最近公司的籃球館模塊優(yōu)化提上日程，因為籃球館錄制視頻的的特殊性，目前輸出的視頻有兩種形式，一種是1080，一種是4k，現(xiàn)在主要優(yōu)化的是1080的情況下，目前這種情況下每個視頻都是8G左右的大小，時長基本上都在6個小時左右，周末的話是9個小時，包大小一般在8G 到15G

一、視頻加載速度優(yōu)化

注意：視頻的清晰度是由碼率和分辨率決定的，分辨率和碼率是相輔相成的，碼率越高，分辨率就會越大，包體積越大，也就越清晰，目前這種方式在1080p 幾千碼率的情況下是適用的，4k高清 幾萬碼率的情況下? 暫不適用。正在尋找優(yōu)化方案

以往版本：
前幾個版本我們采用的是mp4+AVPlayer播放器的方式，這種方式的缺點很明顯，緩沖比較慢? 動則加載一兩分鐘才開始播放

優(yōu)化歷程 ：
在此先說說市面上幾種優(yōu)化解決方案
1.七牛（或者其他平臺）云存儲+CDN服務(wù)
2.mp4+本地Server邊下邊播
3.m3u8+本地server邊下邊播

1.第一種方案，是利用CDN的多個節(jié)點，給與客戶端最大帶寬的方式，讓用戶的網(wǎng)速發(fā)揮到極致，一般是按照流量收費，這個各大平臺都可以看得到，具體優(yōu)缺點平臺文檔一般都挺詳細的。不符合公司目前要求，過濾

2.第二種方案，利用KTVHttpCache搭建本地代理，AVPlayer向本地代理服務(wù)器發(fā)送請求，代理服務(wù)器接收到請求后，向存儲服務(wù)器發(fā)起請求，獲取到數(shù)據(jù)后，存放到本地一份，傳輸給AVplayer一份，這種方式必須得整個視頻緩存完畢，下次播放時優(yōu)先從本地獲取，如果本地不存在再從存儲服務(wù)器獲取，對于首次打開時并沒有任何優(yōu)化，但是如果第一次緩存完整，第二次打開時因為是從本地加載，對于體驗會好很多，對于要求不高的，這種方式足矣

3.第三種方案，利用m3u8的切片特性，錄制視頻的時候講視頻切為2秒一個的ts文件，m3u8文檔記錄每個視頻文件的索引
利用SJMediaCacheServer進行代理服務(wù)，沒有采用KTVHttpCache 的原因是，不知道為什么m3u8在KTVHttpCache上無法正常緩存，在開啟代理的同時將切片保存到本地,因為切片的特性，首開的時候只需要解析到m3u8加載2秒的一個切片即可開始播放，大大提升了用戶的首開體驗，SJMediaCacheServer對切片的緩存可以讓用戶在第二次打開的時候無論是否首次緩存是否完整都可以從本地獲取視頻開頭的切片進行播放，這種方案對于用戶首開和二次加載的體驗，都有大大的提升，同時這種方案還可以對以后的剪輯操作有很大利好

二、視頻剪輯優(yōu)化

以往版本：
剪輯的時候是先傳輸給服務(wù)器需要剪輯哪一段，生成這一段的視頻后再進行下載，下載完成才可以進行本地剪輯操作，從傳給服務(wù)器需要哪一段視頻到服務(wù)器生成這段視頻鏈接這里耗費時間太長

優(yōu)化歷程：
1.從本地沙盒獲取緩存的ts文件通過FFmpeg轉(zhuǎn)碼成mp4進行剪輯操作
2.正在摸索

1.第一種方案，利用了SJMediaCacheServer緩存在本地沙盒的切片，通過兩秒一個切片，計算出需要哪些切片來進行合并，合并成一個總的ts文件，再通過FFmpeg轉(zhuǎn)碼成mp4進行編輯，經(jīng)過測試這個方案相比較以前體驗提升不大，主要耗時在FFmpeg過程，在7plus上轉(zhuǎn)碼速度較慢，F(xiàn)Fmpeg集成有些不友好，可以從下邊第一個文檔鏈接中直接把作者集成好的FFmpeg拖到自己的項目里使用，集成和解決錯誤可以參考下邊的文檔

參考鏈接：
《iOS集成FFmpeg及視頻格式轉(zhuǎn)碼》
《iOS 分享一個邊播邊緩存的庫(支持FILE和HLS)》
《iOS 視頻緩存KTVHTTPCache原理和實現(xiàn)》
《抖音iOS端落地720P視頻實時超分技術(shù)，可顯著提升視頻畫質(zhì)》
《從350ms到80ms，揭秘阿里工程師 iOS 短視頻優(yōu)化方案》