黎鋆洪 曾霞

摘 要：隨著移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展，在無(wú)線(xiàn)終端刷視頻、看直播已經(jīng)成為人們?nèi)粘Ｉ钪械囊徊糠帧，F(xiàn)在互聯(lián)網(wǎng)上的大部分視頻碼率比較大，用戶(hù)使用的移動(dòng)設(shè)備的屏幕分辨率和尺寸無(wú)法滿(mǎn)足互聯(lián)網(wǎng)視頻碼率的需求，加上外界環(huán)境的影響，導(dǎo)致移動(dòng)用戶(hù)的可用帶寬不穩(wěn)定，直接降低了用戶(hù)觀(guān)看視頻的體驗(yàn)?；诖吮尘?，文章對(duì)移動(dòng)互聯(lián)視頻傳輸優(yōu)化的要點(diǎn)進(jìn)行分析，并提出一種解決方案的系統(tǒng)架構(gòu)。

關(guān)鍵詞：移動(dòng)互聯(lián)網(wǎng);視頻傳輸;優(yōu)化;要點(diǎn)分析

0? ? 引言

以往解決網(wǎng)絡(luò)視頻傳輸問(wèn)題是通過(guò)客戶(hù)端傳遞過(guò)來(lái)的反饋信息，判斷網(wǎng)絡(luò)的傳輸情況，進(jìn)而通過(guò)調(diào)整發(fā)送速度或改變碼率等優(yōu)化措施，解決網(wǎng)絡(luò)擁塞情況，甚至有時(shí)為了適應(yīng)網(wǎng)絡(luò)實(shí)際情況，需要從鏈路層、傳輸層和應(yīng)用層等方面采取優(yōu)化手段[1]。然而，這種解決方式需要建立在視頻服務(wù)器和客戶(hù)端播放器共同配合的基礎(chǔ)上，對(duì)于普通用戶(hù)和運(yùn)營(yíng)商來(lái)說(shuō)，解決效果卻不盡人意。

1? ? 系統(tǒng)架構(gòu)

通常網(wǎng)絡(luò)運(yùn)營(yíng)商的網(wǎng)絡(luò)架構(gòu)是先讓移動(dòng)終端和附近的基站建立無(wú)線(xiàn)通信點(diǎn)到點(diǎn)的物理連接，即基站和基站之間的控制設(shè)備連接，再通過(guò)分組控制功能與分組數(shù)據(jù)服務(wù)節(jié)點(diǎn)進(jìn)行連接，接著與核心交換機(jī)進(jìn)行連接之后穿過(guò)防火墻，實(shí)現(xiàn)接入路由器和互聯(lián)網(wǎng)的連接。然而，這種網(wǎng)絡(luò)架構(gòu)具有較高的不穩(wěn)定性，用戶(hù)觀(guān)看視頻的體驗(yàn)感較差?，F(xiàn)在的網(wǎng)絡(luò)系統(tǒng)增加了視頻傳輸優(yōu)化方案，即在核心交換機(jī)上安置一個(gè)四層的負(fù)載均衡器，將用戶(hù)請(qǐng)求重新定向到視頻加速服務(wù)器中。

目前，大多數(shù)網(wǎng)絡(luò)視頻包括了當(dāng)今最火熱的視頻服務(wù)網(wǎng)站，傳輸方式都是通過(guò)HTTP協(xié)議實(shí)現(xiàn)的，這些視頻服務(wù)網(wǎng)站所使用的傳輸端口為常規(guī)的80端口，部分可能是特殊的端口。為此，視頻緩存模塊要對(duì)URL進(jìn)行判斷，當(dāng)URL請(qǐng)求符合指定規(guī)則時(shí)，方可進(jìn)入視頻傳輸流程進(jìn)行優(yōu)化處理，反之則會(huì)進(jìn)入常規(guī)的網(wǎng)絡(luò)處理流程。配備視頻加速服務(wù)器和負(fù)載均衡器，可以增強(qiáng)系統(tǒng)的并發(fā)能力，確保計(jì)算結(jié)果的準(zhǔn)確性。

2? ? 視頻緩存

視頻緩存模塊的功能主要是臨時(shí)保留用戶(hù)訪(fǎng)問(wèn)較多且壓縮后的視頻文件。當(dāng)用戶(hù)對(duì)緩存模塊中的視頻進(jìn)行再次訪(fǎng)問(wèn)時(shí)，可直接訪(fǎng)問(wèn)視頻，不再進(jìn)行二次壓縮，大大降低了運(yùn)營(yíng)商網(wǎng)絡(luò)中重要視頻，流量和視頻壓縮模塊的壓力[2]。通過(guò)在現(xiàn)階段主流開(kāi)源代理軟件Squid上搭建視頻緩存模塊，對(duì)壓縮的視頻文件進(jìn)行配置并編寫(xiě)特定子模塊，實(shí)現(xiàn)視頻緩存功能。

客戶(hù)端通信主要用來(lái)接收用戶(hù)視頻請(qǐng)求，同時(shí)將緩存管理器中得到的視頻傳輸給用戶(hù)。服務(wù)器端通信根據(jù)用戶(hù)的視頻請(qǐng)求獲取相關(guān)視頻，通常指的是視頻壓縮模塊。當(dāng)服務(wù)器端發(fā)生故障或負(fù)載情況嚴(yán)重而無(wú)法連接時(shí)，為避免用戶(hù)請(qǐng)求中斷的發(fā)生需要直接接入視頻網(wǎng)站的服務(wù)器。視頻網(wǎng)站服務(wù)器把同一個(gè)視頻文件分發(fā)到多臺(tái)服務(wù)器中，確保負(fù)載均衡與網(wǎng)絡(luò)暢通，因此同一個(gè)視頻文件的請(qǐng)求會(huì)產(chǎn)生不同的URL。緩存管理器會(huì)判斷這些不同的URL，以此確定是否來(lái)自對(duì)同一項(xiàng)內(nèi)容的訪(fǎng)問(wèn)，為了防止不同的URL導(dǎo)致同一內(nèi)容的視頻被壓縮或多次緩存，需要編寫(xiě)URL重寫(xiě)子模塊。根據(jù)當(dāng)前幾大視頻網(wǎng)站視頻請(qǐng)求URL的特點(diǎn)找出唯一可以對(duì)視頻文件進(jìn)行標(biāo)識(shí)的部分，將不同URL的同一視頻文件重新編寫(xiě)為同一個(gè)，具體的URL重新編寫(xiě)流程為：當(dāng)接收到用戶(hù)請(qǐng)求的URL信息時(shí)，采用正則表達(dá)式對(duì)URL的模式進(jìn)行分析，從而判斷這條URL信息是否為可識(shí)別的視頻請(qǐng)求。如果不是則不用修改，因?yàn)楫?dāng)前幾大視頻網(wǎng)站的視頻請(qǐng)求都有專(zhuān)屬特定模式，而根據(jù)這些特定模式抽取表示視頻ID的部分，利用ID在“可用URL庫(kù)”中進(jìn)行查找，若是找出相對(duì)應(yīng)的URL，就會(huì)將其替換原始的URL，使得緩存可以命中，不然不能輕易修改原始URL。此外，只有在系統(tǒng)啟動(dòng)的情況下才可以創(chuàng)建“可用URL庫(kù)”，同時(shí)在運(yùn)行過(guò)程中不斷對(duì)其進(jìn)行更新與維護(hù)。

而緩存管理器可以對(duì)URL的模式進(jìn)行分析，進(jìn)而對(duì)已知類(lèi)型的視頻請(qǐng)求URL進(jìn)行選擇，并從中抽取視頻ID與URL建立映射關(guān)系，最終形成原始的“可用URL庫(kù)”[3]。由于系統(tǒng)運(yùn)行有可能更新緩存庫(kù)中的內(nèi)容，一旦發(fā)現(xiàn)有視頻被移出或加入，則需要對(duì)“可用URL庫(kù)”中相對(duì)應(yīng)的URL進(jìn)行刪除或者添加處理。Squid軟件具有多種配置方法實(shí)現(xiàn)緩存管理，利用Squid軟件搭建視頻緩存模塊的具體流程為：首先，將緩存的寫(xiě)入機(jī)制、地址及存儲(chǔ)上限進(jìn)行相關(guān)設(shè)置，配置為cache-dir aufs/var/cache 200000 16 256，代表著寫(xiě)入機(jī)制是采用了異步線(xiàn)程，同時(shí)將存儲(chǔ)結(jié)構(gòu)分為兩級(jí)目錄式構(gòu)建在/var/cache的路徑下，第一級(jí)目錄數(shù)為16個(gè)，第二級(jí)目錄數(shù)為256個(gè)，上限為200 000 MB;其次是緩存置換策略的配置。如果以命中率為優(yōu)先原則的緩存置換策略，會(huì)將大小為20 MB的視頻優(yōu)先移出緩存，該文件一旦被命中，主干網(wǎng)將節(jié)約20 MB的流量。因此，視頻傳輸優(yōu)化應(yīng)采用以字節(jié)命中率為目標(biāo)的緩存置換策略，即heap LFUDA，配置方法為：cache-replacement-policy heap LFUDA。緩存可以在磁盤(pán)以及內(nèi)存中進(jìn)行存儲(chǔ)，進(jìn)一步增強(qiáng)響應(yīng)速度，相應(yīng)的配置為：cache-mem 1 800 MB和maximum?-object-size-in-memory 10 MB。其中，1 800 MB則表示用來(lái)緩存的內(nèi)存不得超過(guò)1 800 MB，而10 MB則表示緩存的文件的大小不得超過(guò)10 MB。最后，為了降低文件還在傳輸?shù)脩?hù)觀(guān)看完視頻造成的資源浪費(fèi)，可以配置：quick-abort-pct 85，表示若是視頻文件已經(jīng)上傳了85%，即使用戶(hù)結(jié)束了請(qǐng)求，Squid仍可繼續(xù)執(zhí)行這個(gè)請(qǐng)求直到整個(gè)文件上傳成功并存儲(chǔ)到緩存庫(kù)中為止。

3? ? 視頻壓縮

目前，大多數(shù)視頻網(wǎng)站提供的視頻碼率都比較高，而現(xiàn)階段的移動(dòng)互聯(lián)網(wǎng)容易受外界環(huán)境的影響，如基站信號(hào)覆蓋面的大小、信號(hào)的強(qiáng)弱、附近用戶(hù)的數(shù)量。通過(guò)采用減小視頻碼率的方式可以流暢地觀(guān)看高碼率視頻，滿(mǎn)足接入端的帶寬要求。此外，移動(dòng)終端的屏幕尺寸和分辨率比PC終端的要小很多，PC終端傳輸?shù)囊曨l的分辨率過(guò)高容易浪費(fèi)資源。因此，在視頻壓縮的過(guò)程中，技術(shù)人員還應(yīng)適當(dāng)降低視頻的分辨率，這樣既可以節(jié)省流量，又可以降低接入端網(wǎng)絡(luò)負(fù)載。視頻壓縮模塊的運(yùn)行原理：當(dāng)視頻緩存模塊發(fā)出視頻請(qǐng)求后，經(jīng)過(guò)任務(wù)調(diào)度將請(qǐng)求發(fā)送到視頻服務(wù)器，之后獲得原始視頻，隨后將原始視頻傳送至視頻壓縮子模塊進(jìn)行壓縮，最后再將壓縮好的視頻回傳到視頻緩存模塊。

視頻緩存模塊與視頻壓縮模塊的通信方式為ICAP協(xié)議，該協(xié)議的基本架構(gòu)為Client/Server模式，通過(guò)采用Squid搭建視頻緩存模塊實(shí)現(xiàn)ICAP的客戶(hù)端功能，同時(shí)在ICAP服務(wù)器端通過(guò)采用C-ICAP完成視頻壓縮模塊框架的構(gòu)建，而視頻壓縮子模塊是在這個(gè)框架的基礎(chǔ)上，采用FFMprg構(gòu)建完成的。服務(wù)器端接收到原始視頻之后，視頻壓縮子模塊啟動(dòng)FFMpeg轉(zhuǎn)碼進(jìn)程，將輸入、輸出及轉(zhuǎn)碼參數(shù)統(tǒng)一設(shè)置好。由于涉及進(jìn)程間通信，可以將原始視頻通過(guò)一個(gè)輸入管道傳輸給FFMpeg轉(zhuǎn)碼進(jìn)程，同時(shí)從一個(gè)輸出管道將FFMpeg輸出的壓縮后視頻流取出，最后再通過(guò)客戶(hù)端通信子模塊，將壓縮后的視頻流回傳給視頻緩存模塊。

4? ? 結(jié)語(yǔ)

短視頻、網(wǎng)絡(luò)直播等媒介平臺(tái)隨著互聯(lián)網(wǎng)技術(shù)和商業(yè)模式的發(fā)展在網(wǎng)絡(luò)生態(tài)體系中占有重要地位。然而視頻文件在移動(dòng)網(wǎng)絡(luò)傳輸?shù)倪^(guò)程中經(jīng)常受移動(dòng)網(wǎng)絡(luò)帶寬波動(dòng)的影響，不僅降低了用戶(hù)的上網(wǎng)體驗(yàn)，也不利于網(wǎng)絡(luò)生態(tài)體系的發(fā)展，因此，需要根據(jù)網(wǎng)絡(luò)的實(shí)時(shí)狀態(tài)，及時(shí)調(diào)整視頻傳輸速率，確保視頻文件在網(wǎng)絡(luò)傳輸過(guò)程中能夠暢通無(wú)阻。

[參考文獻(xiàn)]

[1]張桂雷.移動(dòng)互聯(lián)網(wǎng)視頻實(shí)驗(yàn)平臺(tái)中UDP網(wǎng)絡(luò)傳輸?shù)难芯縖J].計(jì)算機(jī)時(shí)代，2017（8）：24-25，28.

[2]祝城鑫.移動(dòng)互聯(lián)網(wǎng)視頻監(jiān)控關(guān)鍵技術(shù)研究與實(shí)現(xiàn)[D].北京：北京郵電大學(xué)，2015.

[3]吳冀衍，程渤，南國(guó)順，等.面向異構(gòu)無(wú)線(xiàn)網(wǎng)移動(dòng)視頻傳輸?shù)穆?lián)合信源信道編碼方式[J].計(jì)算機(jī)學(xué)報(bào)，2015（2）：439-454.

（編輯 王永超）

Key points analysis of video transmission optimization in mobile Internet

Li Junhong1， Zeng Xia2*

（1.Guangzhou Yunxiang Data Technology Co.， Ltd.， Guangzhou， 510000， China;

2.Guangzhou College of Applied Science and Technology， Guangzhou， 510000， China）

Abstract：With the rapid development of mobile Internet， browsing video and watching live telecast in wireless terminal have become a part of peoples daily life. At present， most of the video bit rates on the Internet are relatively large， and the screen resolution and size of the mobile devices used by users can not meet the needs of the Internet video bit rate. The available bandwidth of mobile users is unstable， which directly reduces the users experience of watching video. Based on this background， this paper analyzes the key points of mobile interconnection video transmission optimization， and proposes a solution system architecture.

Key words：mobile Internet; video transmission; optimization; analysis of key points