短視頻APP源碼直播APP源碼什麼樣的好

短視頻所面臨的架構問題
短視頻相比於文本數據而言,有着一些差異:
1.數據大小的差異。
比如一條美拍,經過視頻壓縮和清晰度的權衡,10s的視頻大小1MB多,而一條5分鐘視頻的美拍甚至要達到幾十M,相比與幾十字節或者幾百字節的文本要大得多。因爲數據量要大得多,所以也會面臨一些問題:如何上傳、如何存放、以及如何播放的問題。
關於上傳,要在手機上傳這麼一個視頻,特別是弱網環境要上傳這麼一個文件,上傳的成功率會比較低,晚高峯的時候,省際網絡的擁塞情況下,要更爲明顯得多。所以針對上傳,需要基於CDN走動態加速來優化網絡鏈路(通過基調實測過對於提升穩定性和速度有一定幫助),同時對於比較大的視頻需要做好分片上傳,減少失敗重傳的成本和失敗概率等來提升可用性。同時不同CDN廠商的鏈路狀況在不同的運營商不同地區可能表現不一,所以也需要結合基調測試,選擇一些比較適合自己的CDN廠商鏈路。
同時因爲數據相對比較大,當數據量達到一定規模,存儲容量會面臨一些挑戰,目前美拍的視頻容量級別也達到PB級別的規模,所以要求存儲本身能夠具備比較強的線性擴展能力,並且有足夠的資源冗餘,而傳統的Mysql等數據庫比較難來支持這個場景,所以往往藉助於專用的分佈式對象存儲,通過自建的服務或者雲存儲服務能夠解決,得益於近幾年雲存儲的發展,目前美拍主要還是使用雲存儲服務來解決。自身的分佈式對象存儲主要用於解決一些內部場景,比如對於數據隱私性和安全性要求比較高的場景。
關於對於播放,因爲文件比較大,也容易受到網絡的影響,所以爲了規避卡頓,一些細節也需要處理。比如對於60s,300s的視頻,需要考慮到文件比較大,同時有拖動的需求,所以一般使用http range的方式,或者基於HLS的點播播放方式,基於前者比較簡單粗暴,不過基於播放器的機制,也能夠滿足需求,也能實現點播拖動。而直接基於HLS的方式會更友好,特別是更長的一些視頻,比如5分鐘甚至更大的視頻,不過這種需要單獨的轉碼支持。之前美拍主要是短視頻爲主,所以更多使用http range的方式。而後續隨着5分鐘或者更大視頻的場景,也在逐步做一些嘗試。同時對於播放而言,在弱化環境下,可能也會面臨一些問題,比如播放時長卡頓的問題,這種一般通過網絡鏈路優化;或者通過多碼率的

自適應優化,比如多路轉碼,然後根據特定算法模型量化用戶網絡情況進行選碼率,網絡差的用低碼率的方式。
2.數據的格式標準差異
相比與文本數據,短視頻本身是二進制數據,有比較固定的編碼標準,比如H.264、H.265等,有着比較固定和通用的一些格式標準。
3.數據的處理需求
視頻本身能夠承載的信息比較多,所以會面臨有大量的數據處理需求,比如水印、幀縮略圖、轉碼等,以及短視頻鑑黃等。而視頻處理的操作是非常慢的,會帶來巨大的資源開銷。
美拍對於視頻的處理,主要分爲兩塊:客戶端處理,視頻處理儘量往客戶端靠,利用現有強大的手機處理性能來規避減少服務器壓力,同時這也會面臨一些低端機型的處理效率問題,不過特別低端的機型用於上傳美拍本身比較少數,所以問題不算明顯。客戶端主要是對於視頻的效果疊加、人臉識別和各種美顏美化算法的處理,我們這邊客戶端有實驗室團隊,在專門做這種效果算法的優化工作。同時客戶端處理還會增加一些必要的轉碼和水印的視頻處理。目前客戶端的視頻編解碼方式,會有軟編碼和硬編碼的方式,軟編碼主要是兼容性比較好,編碼效果好些,不過缺點就是能耗高且慢些。而硬編碼藉助於顯卡等,能夠得到比較低的能耗並且更快,不過兼容和效果要差一些,特別是對於一些低配的機型。所以目前往往採用結合的方式。服務端的處理,主要是進行視頻的一些審覈轉碼工作,也有一些抽幀生成截圖的工作等,目前使用ffmpeg進行一些處理。服務端本身需要考慮的一些點,就是因爲資源消耗比較高,所以需要機器數會多,所以在服務端做的視頻處理操作,會盡量控制在一個合理的範圍。同時因爲可能美拍這種場景,也會遇到這些熱點事件的突變峯值,所以轉碼服務集羣本身需要具備可彈性伸縮和異步化消峯機制,以便來適應這種突增請求的場景。

  1. 審覈問題
    視頻內容本身可以有任意多樣的表現形式,所以也是一個涉黃涉恐的多發地帶,而這是一個無法規避掉的需求,因爲沒有處理好,可能分分鐘被封站。審覈的最大的問題,主要是會面臨視頻時長過長,會帶來人力審覈成本的提升。比如100萬個視頻,每個平均是30s的話,那麼就3000W 秒,大概需要347人日。

通過技術手段可以做一些工作,比如:接入一些比較好的第三方的視頻識別模塊,如果能夠過濾掉85%保證沒有問題的視頻的話,那麼工作量會縮減到15%。不過之前在接入使用的時候,發現效果沒有達到預期,目前也在逐步嘗試些其他方案。通過抽幀的方式,比如只抽取某幾幀的方式進行檢查。通過轉碼的方式,比如一個60s的美拍視頻,通過2倍速的方式,無聲,140 * 140的分辨率轉換,大概大小能夠在650kB左右,這樣加速了播放的過程的同時,還能夠減少審覈帶寬的消耗,減少了下載過程。基於大數據分析,分析一些高危地帶、用戶畫像等,然後通過一些黑名單進行一些處理,或者對於某些潛在高危用戶進行完整視頻的審覈,而對於低危用戶進行抽幀的方式等等。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章