這是推流端的實現，推流端設計的原則總結下來就是自適應，推流誰都可以做，開源的也很多。但是為什麼有的做得好，有的做得不好呢？就是看自適應做的好不好。

總結下來有三點自適應，一個是幀率和位元速率自適應，這是大家都能想到的。我推流，如果網路卡了，我就降點幀率或者降一點位元速率，把這個事情做好，把流能正常推上去，不要卡頓。也是這張圖裡畫到的，在傳送網路的時候，我們做了一個QS模組，我們團隊除了做工程化的人之外，還會有四五個博士專門做演算法的。

在這裡就有一些體現，我們在位元速率自適應的時候，是直接可以回饋給編碼器的，讓編碼器動態調整自己的位元速率，儘量保證質量無損，傳出來的視訊位元速率下降，視訊平滑。幀率的控制就比較簡單了，當我們發現網路卡頓了，我們就會反饋給幀率控制模組。

在採集的時候做一些丟棄的操作，目的就是把我們傳送的頻寬降下來。這個我們是基於TCP做的，肯定沒有UDP的效果好，UDP是我們下一步的嘗試，現在還沒有開始。因為UDP還涉及到源站的一些架構重構，我們還沒有來得及做，現在基於TCP的效果其實已經不錯了。後面除了這種簡單的自適應之外，我們還加了一個演算法類的，那個效果就會更明顯。

第二種自適應是軟硬自適應，這個很好理解，像硬體編碼的優點就是手機不燙，缺點一大堆，用MediaRecorder的話，音視訊很難同步，用MediaCodec的話，版本相容有問題，現在還不太好普及。用軟編的話位元速率低，畫質好，除了CPU特別燙，別的都是優點。

怎麼能把這兩個結合起來？我們現在在做的一些策略性的東西，這個就是個體力活，就我們在自己這邊來配置黑白名單，有一些Top50到Top100的高階機型我們用人來測，效能沒有問題的話，我們就上軟編。因為剛才也聽到了軟編都是優點，除了燙。

熱門機型有一些低端的，軟編受不了的就改成硬編。因為硬編是體力工作，所以適配的機型肯定是有限的，沒有誰敢保證能夠全平臺、全機型適配硬編，所以下面的一些非熱門機型，我們來不及適配就軟編。這樣做下來的話，基本能達到99%以上的適配率。在一些大使用者那邊已經驗證過了這個資料。

第三個自適應，演算法自適應。我們是真正的第一家能夠把h.265做成商業化的公司。現在所有的都在提h.265，不知道大家對h.265了不瞭解，有沒有人聽說過h.265可以商業化在Web端無外掛播放？我們現在做到了在賽揚機器上可以播30FPS的720P視訊，在瀏覽器上不用裝任何外掛，這是我們持續優化的結果。當然這個不適合移動的場景，是我們在接另外一個場景的時候用到的。

在移動端我們做到了IOS手機720P編碼，做到15FPS，然後CPU不會打滿，可能是50%到70%之間。之前資料是打滿一個核。這是因為我們之前有很多做演算法的團隊，最開始是做技術授權，後來想在一些產品上落地，移動直播其實是h.265的一個很好的落地的場景，為什麼這麼說呢？

推流端的任務是把更好的畫質推上來，網路有限的情況下，我怎麼能推上來更好的畫質？h.265相對h.264來說能把頻寬省掉30%。30%的概念是在視訊點播類的應用裡能省點錢，在初創應用來說根本就不在乎，因為主播更貴，誰在乎這樣30%的頻寬。

但是在移動推流就不一樣了，30%是從480P到720P的變化，就是你本來只能推480P上來的畫質，經過h.265這種編碼之後能推上來720P的，主播的需求就是網路夠好，CPU夠好，我為什麼不推更好的視訊上去呢？這就是h.265的一個場景，我用演算法的優勢，你的機器只要能夠讓我做到用265來自適應，我就可以推上去更好的畫質。