疫情防控期間高校在線教學直播平臺建設研究*

折波　王強　董凡　覃遵穎　李國棟

摘? ?要：針對新冠肺炎疫情期間高校對在線教學直播的需求，為了給師生提供高質量的在線教學平臺，西安交通大學依托現有智慧教室以及校園網優勢，探索研究建立了一套在線教學直播平臺。平臺按照模塊劃分為視頻流采集存儲、視頻流分發以及視頻流直播模塊。視頻流采集存儲模塊中通過使用標準RTSP協議采集教室3路視頻流并通過存儲算法將視頻存儲到高性能HDFS分布式存儲系統中，視頻流分發模塊使用視頻流故障檢測技術、網絡專線保障視頻流不間斷分發到云直播平臺，視頻流直播模塊將RTMP流轉換為HLS使用自主設計的直播平臺觀看播放保障直播的效果、安全性以及用戶使用的便捷性。教學直播平臺自學校開展線上教學開始穩定運行，目前可以保障學校100余門課程的在線教學。

關鍵詞：在線教學直播;智慧教室;視頻流;RTMP

中圖分類號：TP393.1 文獻標志碼：B 文章編號：1673-8454（2020）19-0074-04

一、引言

2020年伊始，一場突如其來的新型冠狀病毒疫情改變了人們的生活方式，也讓傳統課堂教學模式快速切換到在線教學模式，針對新型冠狀病毒感染肺炎疫情對高校正常開學和課堂教學造成的影響，教育部也印發了《關于在疫情防控期間做好普通高等學校在線教學組織與管理工作的指導意見》[1]，要求采取政府主導、高校主體、社會參與的方式，共同實施并保障高校在疫情防控期間的在線教學，實現“停課不停教、停課不停學”。

持續不退的疫情使得全國各大中小院校不得不選擇在線教學的方式。在這種超大規模用戶群體同時需要在線教學的背景下，為保障疫情防控期間學校教學任務的順利開展，保障教學進度和質量，技術設備以及網絡平臺的選擇對各高校來說都是非常嚴峻的挑戰。西安交通大學充分利用現有的教學平臺（思源學堂、思源學習空間）以及互聯網主流的在線教學平臺（雨課堂、智慧樹、釘釘、愛課堂、騰訊會議、ZOOM等）保障全校5萬余名師生的在線教育教學。由于疫情期間大規模的教學需求和人員訪問，互聯網主流的在線教學平臺如雨課堂、愛課堂等都不堪重負，不能給用戶提供很好的使用體驗，影響教學質量。

為了給學校師生在疫情期間提供高質量的在線教學平臺，西安交通大學依托現有智慧教室以及校園網優勢，探索研究建立了一套在線教學直播平臺，在線教學平臺使用了多路負載、分布式存儲、流分發不間斷檢測、網絡專線保障、云直播平臺資源保障等多項措施為用戶提供720P的直播觀看體驗。

二、在線教學直播平臺建設

西安交通大學現已建成700間智慧教室。智慧教室安裝有視頻采集設備，包括教師攝像頭、學生攝像頭以及VGA采集盒（PPT采集），智慧教室中的每間教室配備24口交換機千兆以太網上聯到樓宇匯聚設備，樓宇匯聚設備萬兆上聯到校園網核心設備，智慧教室網絡鏈路帶寬具備很強的擴展性和豐富的冗余性。本論文研究建設的在線教學直播平臺就是充分利用了現有已經建成的智慧教室中的硬件設備和網絡冗余帶寬，平臺的總體架構模塊劃分如圖1所示。平臺按照模塊劃分為3個模塊，分別為視頻流采集存儲模塊、視頻流分發模塊以及視頻流直播模塊。視頻流采集存儲模塊通過多臺流媒體服務器使用RTSP協議采集教室攝像頭以及VGA采集盒的標準H.264高清視頻流，采集的高清視頻流通過存儲算法存儲到指定的高性能HDFS分布式存儲系統中;視頻流分發模塊是通過多臺流媒體服務器將采集到的視頻流分發到云直播平臺，使用視頻流故障檢測方案、網絡專線充分保障流分發過程的不間斷;視頻流直播模塊是為了保障視頻直播的觀看效果，通過借助社會資源使用商業云直播平臺強大的轉碼能力將RMTP流轉換為HLS流，通過自建視頻直播平臺播放HLS流視頻直播，支持用戶自主選擇切換3路720P高清視頻流直播觀看。

1.視頻流采集存儲模塊

視頻流采集存儲模塊需要對教室中的教師攝像頭、學生攝像頭以及VGA采集盒三路視頻流進行采集，使用標準的RSTP協議[2]，平臺需要對全校700間智慧教室2100路高清視頻流進行采集存儲，在視頻流采集方面需要使用多臺服務器進行多線程采集，在視頻流存儲方面需要設計高性能、大容量、可擴展的分布式存儲系統以滿足對海量視頻資源的存儲要求。

西安交通大學現有智慧教室中視頻流采集設備輸出的視頻流為2Mbps，每間教室每個小時可產生2Mbps*3*3600/（8*1024）=2.6GB數據，按照現有疫情期間每天開設約500門次課程計算，每天可產生的數據量為2.6GB*2*600=3.05TB。按照學校要求，教室視頻保存半年，傳統的NAS存儲無論性能還是容量都無法滿足要求，平臺使用了基于Hadoop的分布式文件存儲系統HDFS，HDFS高容錯性能夠滿足數據存儲安全的需求，高吞吐量的數據訪問滿足平臺的高存儲性能寫入需求，同時可以使用廉價的普通服務器進行部署，大大降低了平臺的存儲成本。

平臺所使用的基于Hadoop的分布式文件存儲系統HDFS采用Hortonworks的開源數據平臺搭建[3-5]，Hadoop平臺部署有HDFS、YARN、Mapreduce2、HBase、Zookeeper、Spark2、Ambari等組件。平臺使用了15臺服務器，每臺服務器安裝有2塊500GB SAS盤做raid1作為系統盤，安裝有16塊6TB的SATA盤作為數據盤，平臺總的存儲容量在1.2PB。

視頻流采集服務器使用了開源的FFmepg軟件，FFmpeg[6-7]是一個開源跨平臺的可以用來記錄、轉換數字音頻和視頻，并能將其轉化為流的開源軟件，FFmpeg支持多線程、多進程。為了保障視頻流采集存儲的穩定性、可靠性、安全性，平臺采用了多臺服務器對智慧教室進行分區采集存儲，每臺服務器只針對固定數量的教室進行采集存儲，針對單間教室視頻流采集存儲的系統架構如圖2所示。為了避免小數據量的大量寫入造成HDFS分布式存儲的低性能，系統使用捕獲線程將教室的三路視頻流采集存儲到本地高性能SSD存儲磁盤中，系統設定一小時生成一個視頻文件，在視頻文件生成后使用存儲線程將視頻文件一次性寫入到后端的HDFS分布式存儲中。

2.視頻流分發模塊

視頻流分發模塊通過多臺流媒體服務器將采集到的視頻流分發到商業云直播平臺，使用網絡專線、視頻流檢測技術充分保障流分發過程的不間斷。為了保障視頻流分發和直播效果，西安交通大學選擇了電信“天翼云商務直播”和移動“和商務直播”，針對“電信天翼云商務直播”和移動“和商務直播”平臺，在對視頻流分發的過程中分別使用校內電信專線和移動專線進行分發，保障網絡推流帶寬。在實際對視頻流分發的過程中，會出現由于教室攝像頭或者VGA采集盒故障導致流采集失敗或者云直播平臺直播間故障導致流分發異常，直播出現異常產生教學事故，因此平臺設計了一套視頻流故障檢測方案來保障流分發的正常以及教室直播出現異常后及時發現處理。

視頻流檢測方案包括了對視頻流推送和視頻流存儲兩部分視頻流故障檢測。視頻流推送故障檢測需要保障教室直播的正常進行，在教室設備或者云直播平臺出現故障后及時發現處理并且恢復直播。單臺服務器視頻流推送故障檢測處理流程如圖3所示。平臺每天按照上課時間設定固定時間啟動教室視頻流推送，將所有上課教室的視頻流推送到云直播平臺對應的直播間，同時啟動視頻流推送監控線程，監控線程逐間教室獲取一間教室信息，判斷該教室流推送是否正常，如果該教室視頻流推送正常，那么判斷所有教室是否檢測完成;如果該教室視頻流推送異常，那么重新推送該教室視頻流，判斷視頻流推送是否成功，如果流推送失敗，那么報告教室推送流錯誤信息，通知教室維護人員處理教室直播故障問題，如果推送成功，那么轉到正常處理流程判斷所有教室是否檢測完成;所有教室如果檢測完成，那么線程Sleep 10秒鐘，如果教室沒有檢測完成，那么獲取下一間教室的教室信息，繼續進行教室流推送檢測，直到所有教室檢測完成。所有教室檢測完成后判斷當天直播課程是否全部結束，如果全部結束，那么結束視頻流推送監控線程并關閉教室流推送，如果沒有全部結束，那么繼續逐間檢測所有直播教室流推送。

視頻流存儲故障檢測需要保障了教學視頻存儲的完整性，在教室設備或者云直播平臺出現故障后及時發現處理后保持正常的視頻存儲，不出現丟視頻的情況。視頻流存儲根據教學時間以每小時為單位對視頻流進行存儲，2小時即為一節課程，單臺服務器單個小時內視頻流存儲故障檢測處理流程如圖4所示。平臺每天按照上課時間設定固定時間啟動教室視頻流存儲，設定每個教室流存儲運行1個小時，同時啟動視頻流存儲監控線程，監控線程逐間教室獲取一間教室信息，判斷該教室流存儲是否正常，如果該教室視頻流存儲正常，那么判斷所有教室是否檢測完成;如果該教室視頻流存儲異常，那么首先計算該教室在當前時間節點距離本小時結束的剩余時間，然后重新設定參數（包括視頻流存儲時間、文件名等），重新啟動教室視頻流存儲，由于出現故障的教室最終存儲的視頻流是多個文件，因此需要教室維護人員記錄好故障教室以及故障時間，方便后期對該教室故障時間點的存儲視頻數據進行拼接處理，判斷視頻流存儲是否成功，如果流存儲失敗，那么報告教室視頻流存儲錯誤信息，通知教室維護人員處理教室直播存儲故障問題，如果流存儲成功，那么轉到正常處理流程判斷所有教室是否檢測完成;所有教室如果檢測完成，那么線程Sleep 10秒鐘，如果教室沒有檢測完成，那么獲取下一間教室的教室信息，繼續進行教室流存儲檢測，直到所有教室檢測完成。所有教室檢測完成后判斷本小時流存儲過程是否完成，如果完成那么結束視頻流存儲監控線程并關閉教室流存儲，如果沒有完成，那么繼續逐間檢測所有直播教室流存儲。視頻流存儲以每小時為單位運行，直到每天所有教室課程結束。

3.視頻流直播模塊

視頻流直播模塊是通過直播平臺實現支持視頻流手機電腦以及多瀏覽器兼容進行觀看，西安交通大學在疫情期間借助社會資源選擇了電信“天翼云商務直播”和“移動和商務直播”平臺。由于每間教室有3路視頻流，每路視頻流為2Mbps，為了保障教室直播授課的效果，需要在同一堂課對3路視頻流同時進行播放，不管是電信“天翼云商務直播”還是移動“和商務直播”平臺都不能滿足這種需求。另外，3路視頻流如果使用RTMP進行播放需要6Mbps的碼流，對直播平臺和用戶自身的網絡環境都是極大的挑戰，尤其是疫情期間全國大中小學校都使用在線教學，各大運營商主干線路都滿載的情況下。視頻流直播模塊最終對RTMP視頻流轉碼為HLS流進行播放，HLS工作原理是切片式傳輸，把直播流切成無數片，用戶在觀看視頻時，每次客戶端可以只下載一部分，然后這部分在播放時從許多不同的備用源中下載其他資源，因此HLS協議可以任由用戶的意愿選擇不同的碼率，能夠大大降低直播平臺網絡負載以及保障在用戶網絡環境一般情況下直播的正常觀看。

為了保障視頻直播的觀看效果，視頻流直播模塊設計了視頻直播觀看平臺，視頻流借用云直播平臺強大的轉碼能力將RMTP流轉換為HLS流，然后通過視頻直播觀看平臺播放HLS流進行視頻直播。每間教室直播在一個頁面同時播放3路視頻流，平臺支持用戶自主選擇切換3路視頻流直播觀看，另外視頻直播觀看平臺對接了校內統一身份認證以及課表信息，用戶通過個人賬號信息登錄平臺后可以直接選擇自己的課程進行觀看，保障了平臺的安全性以及用戶使用的便捷性。

三、西安交通大學在線直播平臺運行情況

西安交通大學在線直播平臺自疫情期間學校開展線上教學以來一直穩定運行，目前已經保障了學校100余門課程、800余門次的視頻直播和錄播教學任務。圖5所示為在線直播平臺日常上課情況，教師上課方式與日常上課沒有任何區別，學生都是通過網絡進入到直播課程觀看老師上課，學生在課程直播間中可以看到3路視頻流，對3路視頻流可以任意切換查看，老師上課無需維護人員值守，上課過程中出現任何硬件軟件問題，會根據系統后臺監控或者教師反饋由專門的教室技術保障人員及時處理，保障教學任務。

疫情持續不退，越來越多的課程將加入到在線直播平臺，直播平臺目前經測試已經可以滿足全校在線教學課程的直播需求。圖6所示為單臺服務器（配置為40顆CPU、132G內存）使用移動網絡專線（10Gbps）測試180間教室同時在線教學情況下網絡流量圖，測試從14∶30持續到17∶30，可以從流量圖中看出專線出口出流量達到1000Mbps，持續測試沒有出現斷流現象，在線直播平臺穩定運行。

四、結束語

為滿足高校疫情期間“停課不停教、停課不停學”的教學要求，在全國大中小院校超大規模用戶群體同時需要在線教學的背景下，西安交通大學依托現有智慧教室以及校園網優勢，探索研究建立了一套在線教學直播平臺。平臺總體架構按照模塊劃分為視頻流采集存儲、視頻流分發以及視頻流直播模塊，本文詳細介紹了每個模塊實現的原理和使用的技術。

參考文獻：

[1]教高廳[2020]2號.教育部應對新型冠狀病毒感染肺炎疫情工作領導小組辦公室關于在疫情防控期間做好普通高等學校在線教學組織與管理工作的指導意見[Z].

[2]CHU Dian， JIANG Chun-hua， HAO Zong-bo， et al， "The Design and Implementation of Video Surveillance System Based on H.264， SIP， RTP/RTCP and RTSP，" 2013 Sixth International Symposium on Computational Intelligence and Design， Hangzhou， 2013， pp. 39-43.

[3]李可，李昕.基于Hadoop生態集群管理系統Ambari的研究與分析[J].軟件，2016，37（2）：93-97.

[4]董新華，李瑞軒，周灣灣等.Hadoop系統性能優化與功能增強綜述[J].計算機研究與發展，2013，50（S2）：1-15.

[5]BHATHAL G S， DHIMAN A S， "Big Data Solution： Improvised Distributions Framework of Hadoop，" 2018 Second International Conference on Intelligent Computing and Control Systems （ICICCS）， Madurai， India， 2018， pp.35-38.

[6]LEI Xiao-hua， JIANG Xiu-hua， WANG Cai-hong， "Design and Implementation of a Real-Time Video Stream Analysis System Based on FFMPEG，"2013 Fourth World Congress on Software Engineering， Hong Kong， 2013， pp. 212-216.

[7]D. Radovi， M. upi， S. Stefanovi?and D. Majstorovi？， "Internet radio player implementation using FFmpeg software support，" 2017 International Conference on Smart Systems and Technologies（SST）， Osijek， 2017， pp. 259-262.

（編輯：王曉明）