基於ip網的多媒體實時授課系統的製作方法
2023-09-19 22:45:25 1
專利名稱：基於ip網的多媒體實時授課系統的製作方法
一、所屬領域本發明屬於計算機設計與應用技術領域，涉及計算機軟體、信息傳遞技術、多媒體技術以及網絡教育/遠程教育。特別涉及一種基於IP網的多媒體實時授課系統在上述專利1中，發明人提出了一套在分組交換網下開展多媒體視頻會議的方法，該套方法主要有以下特點1)支持群組交互模式下多媒體數據的發送、接收；2)多媒體數據採用RTP(Real-time Transport Protocol)協議進行傳輸；3)採用RSVP(Resource reSer Vation Protocol)協議對交互過程中的視音頻質量進行控制；4)數據傳輸支持單播(unicast)、組播(multicast)、廣播(broadcast)三種模式；5)交互過程可以保存為本地媒體文件；6)採用目錄管理機制對會議成員進行管理。
7)採用軟硬體相結合的實現策略。
在專利2中，發明人提出了一套在視頻會議系統中創建呼叫的過程，該過程主要描述了呼叫雙方的認證、授權、能力協商，此外還定義了呼叫消息所攜帶數據的內容與格式。目前，視頻會議系統一般都採用類似的呼叫機制。
在專利3中，發明人提出了一套在分組交換網下開展多媒體視頻會議的方法，並實現了該系統。此套方法與系統主要有以下特點1)支持多個分組間基於RTP協議的組播數據發送、接收；2)採用目錄管理機制對會議成員進行管理；3)通過創建虛擬實境環境，實現分組間的用戶相互感知，並能通過虛擬對象進行交互；
4)採用目錄管理機制對會議成員進行管理；5)交互過程可以保存為本地媒體文件；6)採用軟硬體相結合的實現策略。
根據上述查新，現有系統在通信方面存在以下四方面的問題1.不能支持組播數據的跨網段傳輸，網絡帶寬資源利用率較低，進而導致系統所能支持的端結點數目以及分布範圍都存在很大局限性。
2.大多數同步實時授課系統直接採用了視頻會議系統中的多點群組交互機制，這種交互機制不適合於實時授課。採用這種交互機制，不僅增加了上層管理的複雜程度，同時也造成不必要的系統資源開銷，特別是網絡帶寬資源的開銷。
3.缺乏自適應的QoS控制機制，主要表現在一、QoS控制機制無法適應網絡狀態的動態性。二、QoS控制機制對分布環境異構性的適應能力較差。
4.缺乏課件自動生成機制，只能將教學現場保存為媒體文件，無法生成教案與教學現場同步的課件。
2.組播數據跨網段傳輸機制研究目的解決媒體數據的跨網段(子網)高效傳輸問題，以及視頻、音頻融合問題。
研究背景在交互式多媒體同步實時授課中，當結點數多於兩個時，需要引入稱為多點控制單元(Multipoint Control Unit，MCU)的實體(Entity)。它的功能主要包括兩點①支持各結點的視頻、音頻數據的跨網段傳輸並進行有效控制；②對交互過程中的視頻、音頻數據進行融合處理。
目前，MCU大多採用集中式，由專門的MCU硬體實現，成本高，擴展性差。
本發明的解決策略在RealClass系統的設計中，本發明提出並實現了一種基於軟體的分布式MCU機制，即在每個獨立的網段，設置一個MCU，從而形成一個級聯的樹型MCU。採用單播和組播相結合的數據發送策略，即各MCU之間採用單播數據發送，各個網段內部採用組播數據發送，這樣不僅可以大大節省網絡帶寬，而且還實現了組播數據的跨網段傳輸和視頻、音頻數據的融合，有效地提高了系統的可擴展性。
3.視音頻融合機制研究目的研究解決授課端和聽課端視頻、音頻融合的問題，將兩路或多路視頻、音頻數據合併成一路數據，使得融合後的視頻具有「畫中畫」的效果，對於音頻，則具有「混音」效果。
問題背景在實時教學系統中，視頻、音頻融合是十分需要的。因為聽課端需要感受到一個「真實」的教學環境，因此需要把授課端及正在和授課端進行交互的「焦點」聽課端的視頻、音頻數據進行融合，這樣不僅可以大大減少數據量和網絡帶寬的佔用，而且還可以為異地聽課端提供一個更加形象、逼真的教學視聽環境。
目前，有關視頻、音頻融合的基本原理大致雷同，本系統的特點是採用軟體實現，支持兩路或四路視頻融合，和MCU有機集成，無需附加軟硬體。
4.動態自適應QoS控制機制研究目的在沒有傳輸質量保障的IP網上，研究解決如何保障實時教學過程的多媒體數據傳輸質量的問題，即如何解決傳輸過程中延遲、抖動、丟包等問題。
問題背景現有TCP/IP協議採用的是盡力而為(best-effort)的服務機制，該機制雖能較好地滿足諸如WWW、Email、FTP等Internet的非實時應用，但它不適合於諸如網絡實時教學等的實時多媒體應用。因此，要實現基於IP網的交互式同步實時授課，必須在現有TCP/IP傳輸機制的基礎上增加服務質量(QoS，Quality of Service)控制機制。
目前，國際上的一些標準化組織，如IETF等已提出了基於IP網實現QoS控制機制的相關協議和模型，如RTP/RTCP協議、IntServ/RSVP模型、DiffServ模型及MPLS模型等。這些協議和模型為QoS控制機制的深層研究提供了較好的基礎，但在實際應用中都存在一定的局限性。主要表現為(1)無法適應網絡狀態的動態性，現有QoS控制機制無法根據可用帶寬、丟包率等網絡狀態參數的動態變化而動態調整控制策略，即不具備自適應能力。
(2)對分布環境異構性的適應能力較差。分布環境的異構性主要表現在分布的各個結點其軟硬體體系結構和數據發送方式可能存在差異。前者表現為結點可能具有不同的接入速率、主機性能，甚至不同的作業系統；後者則表現為結點可能採用組播或單播發送方式。現有QoS控制機制基本上不具備適應上述分布異構環境，可擴展性較差。
(3)目前QoS控制機制僅局限於從網絡角度提出解決策略。這種單一策略的控制機制在網絡負載較重時，提供的服務質量明顯下降。
本發明提出了一種基於分層結構的動態自適應QoS分布控制模型。其主要設計思想為一方面，借鑑DiffServ模型中基於端結點的分布控制思想，並在端結點引入動態自適應的流控機制，使得本模型不僅具有可擴展性，而且還能根據網絡狀態自動調整控制策略。另一方面，採用多角度解決策略，將與QoS控制相關的網絡技術、視頻編碼技術以及FEC(ForwardError Correction)容錯技術等進行有機集成，從而使得本模型在帶寬受限的情況下也能為媒體流傳輸提供合適的服務質量。
5.多媒體教學現場同步錄製技術研究目的同步實時錄製教學現場及教案內容，生成流媒體課件，供學生課後點播學習。
問題背景能夠在實時教學過程中，一邊進行實時授課，一邊自動進行同步課件錄製與生成，是一件十分有意義的工作。不僅能夠快速簡捷地生成課件資源，減少課件製作的重複工作，而且為學生課後自主點播學習提供了機會。
目前，這方面工作存在的問題是數據量太大，生成的課件無法進行後期修改和維護，模式單一。
本發明的解決方法根據教學實際，本發明提出了兩種解決思路一種是實時採集教案內容、教學現場的視頻、音頻數據，並壓縮生成流媒體(如rm或MPEG-IV等格式)文件，供課後點播；二是將教學內容轉換成超文本(HTML文檔)，並和實時錄製視頻、音頻同步集成，形成「HTML+流媒體」格式的課件。這兩種解決方案各有特點，可以視實際情況選擇使用，主要區別在於是否對授課端計算機屏幕上的教案部分實現流式視頻編碼。
本發明通過教學現場的多媒體錄製和網絡傳輸，實現教學現場的直播，並通過師生多媒體多模式交互、教師自然板書授課、教學內容檢索、應用程式共享、課件同步瀏覽、電子白板、課件實時錄製、課堂管理等功能，解決傳統課堂教學在時間和空間上的制約問題，大大擴展了教學規模，能夠實現名師授課及教育資源的共享。
圖2、本發明的實時授課系統RealClass的授課端工作機制示意圖；圖3、本發明的實時授課系統RealClass的聽課端工作機制示意圖；圖4、本發明的實時授課系統RealClass的課堂服務中心工作機制示意圖；圖5、本發明的實時授課系統RealClass的MCU實現框架示意圖；圖6、RealClass系統中埠使用規定；圖7、MCU實現的分布式MCU的工作機制示意圖；圖8、視頻數據融合的工作機制示意圖；圖9、融合後的視頻效果示意圖；
圖10、本發明的音頻數據融合的工作機制示意圖；圖11、基於分層結構的動態自適應QoS控制模型示意圖；圖12、本發明的RealScreen系統的工作機制示意圖；圖13、本發明的HTML-Recorder工具的工作機制示意圖；圖14、HTML-Recorder工具生成的課件形式示意圖；圖15、授課端用戶界面；圖16、聽課端用戶界面；圖17、課堂服務中心的用戶界面。
其中授課端，是指教師通過網絡為聽課端提供授課現場的實時視頻、音頻及電子教案，並通過電子白板、應用程式共享以及文本Chat等工具與聽課端進行交互，此外授課教師還可對整個教學過程進行控制的授課平臺。
授課端由一實現與課堂服務中心進行狀態、控制信息的交互，並能根據交互結果對底層的視頻、音頻數據採集、傳輸、發送、回放進行的事務管理模塊，底層的視頻、音頻數據處理是由Avmeeting控制項實現；Avmeeting控制項從本地的媒體設備中讀取視頻、音頻數據，並通過QoS數據發送控制項發送到本網段，即授課端網段的MCU；同時調用QoS數據接收模塊從本網段MCU讀取焦點聽課端的視頻、音頻數據，並將此數據與授課端的媒體數據在本地進行回放。
聽課端是指學生通過網絡接收授課端的視頻、音頻及電子教案信息，當聽課端獲得交互權限後，還可與授課端進行視頻、音頻或其它方式的交互，聽課端與聽課端之間在授課教師許可的情況下也可通過分組方式進行交互的聽課平臺。
聽課端由一實現與課堂服務中心進行狀態、控制信息的交互，並能根據交互結果對底層的視頻、音頻數據採集、傳輸、發送、回放進行的事務管理模塊，底層的視頻、音頻數據處理同樣是由Avmeeting控制項實現；Avmeeting控制項從本地的媒體設備中讀取視頻、音頻數據，並通過QoS數據發送控制項發送到授課端網段的MCU；同時調用QoS數據接收模塊從本網段MCU讀取授課端的視頻、音頻數據，對於非焦點聽課端，讀取的是授課端和焦點聽課端融合後的數據，並將此數據與本地的媒體數據在本地進行回放。
課堂服務中心是指管理員用於對授課系統進行監控的控制臺，並充當視頻會議系統中的GateKeeper；其通過與授課端、聽課端、MCU的狀態和控制消息交互，實時獲取RealClass系統的狀態，並對RealClass系統各個端結點的工作進行控制。
多點控制單元(Multipoint Control Unit，MCU)是完成系統中視頻、音頻數據的路由、轉發以及處理，系統採用了分布式MCU機制，即在系統所分布的每個網段中都存在一個MCU結點。5.2子系統設計以下對RealClass系統中的各個子系統(包括授課端子系統、聽課端子系統、課堂服務中心子系統及MCU子系統)的工作機制進行說明，對於各個子系統的詳細設計說明參看相應的詳細設計方案。5.2.1授課端工作機制授課端的工作機製圖2所示，其中授課端事務管理模塊主要實現與課堂服務中心進行狀態、控制信息的交互，並能根據交互結果對底層的視頻、音頻數據採集、傳輸、發送、回放進行。底層的視頻、音頻數據處理是由Avmeeting控制項實現的。Avmeeting控制項從本地的媒體設備中讀取視頻、音頻數據，通過QoS數據發送控制項發送到本網段(授課端網段)的MCU；同時調用QoS數據接收模塊從本網段MCU讀取焦點聽課端的視頻、音頻數據，並將此數據與授課端的媒體數據在本地進行回放。5.2.2聽課端工作機制聽課端的工作機製圖3所示，其中聽課端事務管理模塊主要實現與課堂服務中心進行狀態、控制信息的交互，並能根據交互結果對底層的視頻、音頻數據採集、傳輸、發送、回放進行。底層的視頻、音頻數據處理同樣是由Avmeeting控制項實現的。Avmeeting控制項從本地的媒體設備中讀取視頻、音頻數據，並通過QoS數據發送控制項發送到授課端網段的MCU；同時調用QoS數據接收模塊從本網段MCU讀取授課端的視頻、音頻數據(對於非焦點聽課端，讀取的是授課端和焦點聽課端融合後的數據)，並將此數據與本地的媒體數據在本地進行回放。5.2.3課堂服務中心工作機制課堂服務中心工作機制如圖4所示。其通過與授課端、聽課端、MCU的狀態和控制消息交互，實時獲取RealClass系統的狀態，並對RealClass系統各個端結點的工作進行控制。5.2.4 MCU工作機制MCU可分為多點控制器MC和多點處理器MP兩部分，其實現框架如圖5所示。
MC包含多點交互控制和QoS參數確定兩個模塊。多點交互控制模塊的主要功能是通過對MP的操作實現對遠程教學過程中的授課端和聽課端的視頻、音頻交互控制，此外，它還根據與課堂服務中心交互的命令與狀態信息生成當前MCU與其它端結點(授課端、聽課端、其它MCU)連接的狀態信息。QoS參數確定模塊根據此狀態生成當前MCU的各個輸出媒體流的QoS參數，此參數將傳遞給MP中的QoS控制機制，作為其為每個輸出媒體流分配網絡帶寬的依據。
MP可分為QoS控制機制和視頻、音頻數據處理兩個模塊。其中視頻、音頻數據處理模塊是MP的核心模塊，由MC中的多點交互控制模塊驅動。視頻、音頻數據處理模塊獲取QoS控制機制整形後的數據，對其進行數據融合和轉發等處理，並將處理後的數據傳送到QoS控制機制進行發送。MP的QoS控制機制根據MC傳遞來的QoS參數以及當前的網絡狀態進行QoS控制，主要包括對視頻、音頻數據處理模塊處理後的多媒體數據進行帶寬分配和發送，以及對由其它端結點發送來的多媒體數據進行整形。5.2.5各個模塊間的接口由MCU實現框架圖，MCU的內部接口包括以下幾個部分■MC中的QoS參數確定模塊與多點交互控制模塊之間的接口MC中的QoS參數確定模塊與多點交互控制模塊之間的接口是多點交互控制模塊根據由課堂服務中心發送來的全局MCU狀態、本網段端結點狀態生成的全局MCU狀態列表和本網段端結點狀態列表。
■MC中的QoS參數確定模塊與MP中的QoS控制機制之間的接口MC中的QoS參數確定模塊與MP中的QoS控制機制之間的接口是QoS參數確定模塊根據全局MCU狀態列表和本網段端結點狀態列表生成的各個輸出媒體流的QoS參數，即媒體流的帶寬許可範圍。
■MC中的多點交互控制模塊與MP中的視音頻數據處理模塊之間的接口MC中的多點交互控制模塊與MP中的視音頻數據處理模塊之間的接口是由MC生成的或轉發課堂服務中心的視音頻數據融合命令、視音頻數據轉發命令。
■MP中的QoS控制機制與視音頻數據處理模塊之間的接口MP中的QoS控制機制與視音頻數據處理模塊之間的接口包括經QoS控制機制整形後傳輸到視音頻數據處理模塊的數據，以及經視音頻數據處理模塊的處理後傳輸到QoS控制機制的數據。
由MCU與RealClass系統中的其他端結點的交互關係，MCU的外部接口包括以下幾個部分■MC中的多點交互控制模塊與課堂服務中心之間的接口MC中的多點交互控制模塊與課堂服務中心之間的接口主要是兩者之間交互的命令和狀態，包括(1)由MCU向課堂服務中心發送的命令和狀態，主要有MCU登錄命令、MCU退出命令、端結點視音頻控制命令。
(2)由課堂服務中心向MCU發送的命令和狀態，主要有全局MCU狀態、本網段端結點狀態、視音頻數據融合命令、視音頻數據轉發命令。
■MP中的QoS控制機制與授課端和聽課端的接口MP中的QoS控制機制與授課端、聽課端、其它MCU的接口主要指他們之間視音頻數據收發埠的規定，對埠合理的規定，可以大大簡化交互的控制邏輯。
在RealClass系統中，規定授課端向2001埠發送視頻數據，向2000埠發送音頻數據，從4001埠接收視頻數據，從4000埠接收音頻數據；聽課端向3001埠發送視頻數據，向3000埠發送音頻數據，從4001埠接收視頻數據，從4000埠接收音頻數據；MCU從2000～2001埠獲取讀取授課端視音頻數據，從3000～3001埠獲取讀取聽課端視音頻數據，處理後向4000～4001埠發送視音頻數據。如圖6示。■MP中的QoS控制機制與其他MCU中的QoS控制機制之間的接口MP中的QoS控制機制與其他MCU中的QoS控制機制之間的接口即MP之間的接口。在RealClass系統中，規定MP之間進行視音頻數據交互時，視頻數據使用5001埠，音頻頻數據使用5000埠。如圖6示。5.3主要關鍵技術5.3.1組播數據跨網段傳輸機制由於IP網一般不支持組播數據的跨網段發送，在本系統中，本發明基於分布式MCU實現了組播數據的跨網段，其原理如圖7所示。主要思想是採用級聯的MCU對組播數據進行轉發。具體工作機制如下I.授課端將本地視頻、音頻數據單播發送到授課端MCU，並接收經授課端MCU組播發送的數據，此數據是授課端視頻、音頻與焦點聽課端視頻、音頻融合後的數據。
II.授課端MCU將接收到的授課端視頻、音頻數據與焦點聽課端視頻、音頻數據融合後，單播發送到各個非授課端MCU上，並組播到本地的授課端與各個聽課端。
III.非授課端MCU將來自授課端MCU的視頻、音頻數據組播到本地各個聽課端。
IV.焦點聽課端將本地視頻、音頻數據單播發送到授課端MCU。
上述機制使得同步實時授課系統的負載不再受限於聽課端的結點數目，而僅受限於聽課端所分布的網段數目，從而有效地提高了系統的可擴展性。
在交互過程中，本發明提出了一種適合實時教學的多媒體群組交互模式——鏡頭焦點交互模式，其含義為在同一時刻，允許一個稱為「焦點」的聽課端結點與教師進行交互，並將兩者的多媒體數據經MCU融合後發送到其餘各個結點，從而實現實時同步教學過程的傳輸。在這一過程中，學生可以隨時向教師提出交互請求，教師可根據需要隨時切換焦點。採用這種鏡頭焦點交互模式，不僅簡化了實時授課系統的上層管理，而且還避免了不必要的帶寬資源開銷。5.3.2視頻、音頻數據融合技術本發明的解決方法■視頻融合當MCU中的MP接收到兩路視頻數據後，對其進行解碼，解碼後的數據為CIF格式或BMP格式，若解碼後為BMP格式，則首先將其轉化為CIF格式。對於兩路CIF格式的數據，首先將其中一路視頻幀轉化成一路QCIF格式，然後再和另一路視頻幀進行融合，根據視頻的原編碼算法，再對融合後的視頻幀進行編碼。視頻融合的工作機制如圖8所示。融合後的視頻效果如圖9所示。
■音頻融合當MP接收到兩路音頻數據後，對其進行解碼，解碼後的數據為線性的音頻數據，然後將兩路線性的音頻數據進行代數迭加，進而根據音頻的原編碼算法，再對迭加後的音頻數據進行編碼。音頻融合的工作機制如圖10所示。5.3.3動態自適應QoS控制機制本QoS控制模型的實現要點為■基於端結點的分布控制機制本模型引入了具有自適應能力的流控機制，它能根據當前網絡狀態為視頻數據流動態分配網絡帶寬，同時對每個視頻數據包能否進入網絡進行準入判斷。網絡狀態主要包括可用帶寬、傳輸延遲以及丟包率。該機制所依據的網絡狀態是端結點間的整體狀態，這充分掩蓋了內部結點的異構性，使得該模型能較好地適用於異構的分布環境。
■基於分層結構的多角度解決策略和以往不同的是本發明對QoS問題的解決採用的是多角度、多層次的解決策略。把QoS控制模型分為QoS控制層、RTP層以及FEC層三個層次，如圖11所示，並將網絡傳輸、視頻編碼以及FEC容錯這三個QoS的具體控制措施有機分布到這三個層次之中。
QoS控制層主要實現多媒體數據傳輸的準入控制、流量控制和區分服務。主要措施為對音頻數據流採用固定帶寬分配策略；對於視頻數據流，則採用動態自適應的帶寬分配策略，在此基礎上，根據每個視頻數據包的編碼特徵確定其是否可以進入網絡，即是否發送到RTP層。
RTP層主要實現多媒體數據包的實時、有序傳輸，並通過RTCP包的交互動態獲取當前數據傳輸的時延、抖動、丟包率等網絡狀態參數，這些參數不僅是QoS控制層進行帶寬分配的依據，也是FEC層實施動態FEC機制的主要依據。
FEC層主要功能是為上層提供一條透明的可靠傳輸通路，避免因網絡傳輸丟包導致的重傳。本層還引入了反饋機制，即根據當前的丟包率，動態控制FEC數據包的發送。
上述三個層次之間有明確的接口，每一層通過其接口向上層提供透明的服務。在發送端，媒體數據由應用程式經QoS控制層、RTP層以及FEC層逐層分解並添加包頭信息後發送到網絡系統；在接收端，媒體數據由網絡系統經FEC層、RTP層以及QoS控制層逐層還原後返回到應用程式。
■QoS控制層QoS控制層的主要功能是對輸出媒體流進行流量限制。根據多媒體應用對視音頻數據QoS需求特點，本模型中，採用音頻數據優先的策略，基於帶寬預留思想為音頻數據流分配固定帶寬；對於視頻數據，則採用動態自適應的帶寬分配機制，並在此基礎上，引入基於視頻編碼特徵的信包調度模塊，使得當網絡負載較重時，只發送對QoS影響較大的媒體數據。以下對視頻數據的帶寬分配機制與信包調度機制進行說明，並給出調度算法。
視頻數據的帶寬分配採用了「線性增長成倍衰減」的策略，此策略為若當前的數據包丟失率小於某個閾值，則線性增加分配帶寬值；若當前的數據包丟失率大於某個閾值，則將當前帶寬值乘上衰減比例因子，作為新的分配帶寬值。基於上述策略的帶寬分配機制既能充分利用帶寬資源，又能有效地降低丟包率。
視頻數據的信包調度由令牌管理模塊和數據包發送判定模塊協同完成。令牌管理模塊的工作機制是基於「漏桶算法」[2]，其主要作用是對媒體數據發送速率進行限制，使得發送速率符合帶寬分配模塊所確定的速率。該子模塊以帶寬分配模塊所確定的速率生成令牌，如令牌池中令牌已滿，則令牌停止生成；當數據包發送判定子模塊確定要發送一個數據包時，首先通知該子模塊減去數據包大小的令牌數。數據包發送判定子模塊根據當前令牌池中的令牌數以及當前視頻數據包的編碼特徵判定是否將數據包發送到網絡。根據H.261、H.263、MPEGI、MPEG II等視頻編碼的特性，視頻編碼幀可以分為I幀(幀內編碼)、P幀(幀間編碼)以及B幀(雙向預測)[4，5]。考慮到I幀、P幀、B幀解碼過程中的相互依賴關係，傳輸視頻數據必須遵循以下原則(1)在傳輸過程中，I幀優先級最高，P幀優先級次之，B幀優先級最低；(2)傳輸P幀的前提是必須傳輸與之關聯的I幀或P幀；(3)傳輸B幀的前提是必須傳輸與之前後相鄰的I幀或P幀。
基於上述三個規則，提出如下調度算法對視頻數據包的發送進行判定，此算法的主要思想是在帶寬受限的情況下，儘可能多地發送優先級高的數據包。調度算法描述如下case 數據包幀類型 ofI幀 if B幀隊列非空 and當前令牌數＞(當前數據包大小+B幀隊列大小)then發送B幀數據包和當前數據包並將令牌數減去此次發送數據包大小之和elseif 當前令牌數＞ 當前數據包大小 then發送當前數據包並將令牌數減去當前數據包大小；清空B幀隊列；P幀 if B幀隊列非空 and當前令牌數＞ (當前數據包大小+B幀隊列大小+平均關鍵幀大小) then發送B幀數據包和當前數據包並將令牌數減去此次發送數據包大小之和；elseif 此幀關聯的I幀已發送 and當前令牌數＞ (當前數據包大小+平均關鍵幀大小) then發送當前數據包並將令牌數減去當前數據包大小；清空B幀隊列；B幀 if 此幀的前一個I幀或P幀已發送 then將此幀放入隊列；end.
其中，平均關鍵幀大小可通過對多個關鍵幀的大小統計獲得，B幀隊列大小指當前隊列中所有B幀大小之和。
若在信包調度過程中不考慮數據包的編碼特性，則在接收端接收到數據後，很可能因為其相關的I幀數據或P幀數據沒有發送而無法解碼，成為無用數據，這使得信道的實際利用率大大降低。本算法保證了在數據包不丟失的情況下，發送到對方的編碼數據都可被正確解碼，且解碼後的數據具有最優的表現質量。
■3.2FEC層FEC層的主要功能是基於FEC容錯技術為上層提供一條的「較可靠」的傳輸通道，FEC層雖無法提供完全可靠的數據傳輸，但能有效地降低丟包率。其工作機理是在發送端把k個原始數據包編碼生成n(n＞k)個數據包，使得n中的任何k個數據包都能夠恢復出原始數據包，這樣在接收端只要接收到任意m(m＞k-1)個數據包，就可以恢復原始的k個數據包，即允許傳輸過程最多丟失n-k個數據包[3，6]。相對於目前網絡傳輸中常用的ARQ(AutomaticRepeat Request)控制機制，FEC機制主要有以下優點(1)FEC機制是由數據發送端實現的，不需要與數據接收端進行交互，實現機制較ARQ簡單；(2)適用於組播或廣播模式的數據發送，在這種一對多的發送模式下，性能不會隨著接收方的數目增加而下降，即具有較好的可擴展性[3]。
FEC機制的主要缺點就是在網絡丟包率比較低的情況下，仍然生成固定數目的冗餘數據包，這些數據包不僅佔用了一定網絡帶寬，而且也增大了傳輸延遲[3]。
本模型的FEC層將FEC機制和反饋機制結合起來，實現了動態自適應的FEC機制。該機制不僅能有效地降低數據傳輸過程中的丟包率，而且在丟包率較低的情況下能有效減少冗餘數據佔用的帶寬。其主要機理為(1)根據媒體流丟包率的許可範圍，確定n、k值；(2)採用公式①確定實際發送的數據包數m(k≤m≤n)，此數值應保證在當前丟包率情況下，接收方仍能以較高的概率恢復編碼前的k個數據包；(3)編碼器順序將k個數據包編碼成n個數據包；(4)隨機選擇m個數據包發送。
在動態FEC機制中，m的確定是其中的關鍵。設當前採用n，k編碼，當前丟包率為r，允許丟包率為R(R＜r)，m應滿足下述公式i=0m-kCmi(1-r)m-iri>(1-R)k----(1)]]>其中，上式的左邊表示當前丟包率為r時，接收端接收到m中的k個以上(包括k個)數據包的概率，即能還原出k個數據包的概率；上式的右邊表示在允許丟包率為R時，接收端正確接收到k個連續數據包的概率，顯然，只有滿足上述不等式關係時，才有必要進行FEC編碼。採用枚舉法，逐個選取m值(k≤m≤n)代入上式測試，最後選取能使上式成立的最小m值。當r＜R或r＞＞R時，可能不存在使上述公式成立的m值，則當前沒有必要進行FEC編碼，FEC層直接將RTP數據包發送到網絡系統。因而，上述公式不僅用於計算FEC編碼傳輸中應實際發送的數據包數，而且也可用於判斷是否對RTP數據包進行FEC編碼。5.3.4多媒體教學現場同步錄製技術■流媒體課件實時錄製工具——RealScreenRealScreen工具採用的是技術路線一，它不僅可以實現實時教學的流媒體課件錄製，而且還可以實現教學現場的直播，RealScreen由授課端、伺服器端以及聽課端三個部分組成。其中授課端主要實現了教學現場與教案內容的錄製與編碼；伺服器端主要實現流媒體課件的發布與點播服務，聽課端實現課件的回放。RealScreen的工作原理如圖12所示。
在授課端，RealScreen通過定時截取屏幕或窗口獲得當前教案內容的內存BMP映像，同時將當前視頻捕獲設備採集到的視頻幀數據轉化成內存BMP格式，然後將兩部分BMP數據在位圖基礎上進行融合，並將融合後的數據發送到流媒體壓縮引擎上；RealScreen同時還將音頻設備採集到的音頻數據也發送到該引擎。壓縮引擎將接收到的融合數據作為視頻數據進行實時編碼，同時將接收到的音頻數據也進行實時編碼，並將編碼後數據一起發送到流媒體伺服器。此外，流媒體壓縮引擎還可將編碼數據以RM文件形式在本地進行保存。在伺服器端，流媒體伺服器將接收到的數據以RM文件形式進行保存，同時根據聽課端的請求，採用RTSP/RTP協議將流媒體數據傳輸到聽課端。在聽課端，用戶採用RealPlayer將接收到的編碼數據進行解碼、回放。
RealScreen將授課教案和視頻、音頻進行有機融合，這使得RealScreen不僅可以支持任何形式的教案，自動、同步、實時地生成流媒體課件，而且還可以實現教學現場直播和按需點播的同步進行。(如圖12所示)這種方式的缺點是數據量較大，對課件的後期改進比較困難。
■基於「HTML+流媒體」的實時課件錄製工具——HTML-RecorderHTML-Recorder工具採用技術路線二，能夠較好地解決了RealScreen工具存在的數據量大、帶寬佔用多、後期修改困難等問題，其工作原理如圖13示。
HTML-Recorder工具可以和RealClass系統配合運行，是一個後臺程序。它一方面實時地採集教師的視頻、音頻數據並生成ASF流媒體文件，另一方面它將教師對教案的操作實時記錄在時間戳日誌中，包括教案換頁、顯示每個條目的時間戳等。當運行結束時，HTML-Recorder自動將時間戳寫入ASF文件；並將PowerPoint格式的教案轉化為一系列HTML網頁及相關媒體文件；最後，將攜帶時間戳的ASF文件與HTML格式的教師教案按照固定的框架(Frame)進行封裝，從而生成教學課件。界面形式如圖14示。
與RealScreen工具相比，HTML-Recorder工具生成的課件在傳輸時只佔用相對較小的帶寬，並具有更好視頻、音頻質量，而且生成的課件可以進行後期修改，但缺點是目前課件的格式只支持Powerpoint格式。
RealScreen工具和HTML-Recorder工具的有機結合，可以提供完善的課件錄製功能。5.3.5界面設計界面是系統功能和特點的集中反映，為了真正實現交互式同步實時授課的效果，需要將授課端現場、課件內容及其它必要的輔助功能以多窗口的形式展現在教師或學生的面前。
■授課端用戶界面授課端用戶界面如圖15示。包括授課端視頻顯示區、聽課端視頻顯示區、課件內容瀏覽區、功能按鈕區、聽課端狀態顯示區等5部分。其中聽課端視頻顯示區可以由教師任意切換到任一聽課端。
■聽課端用戶界面聽課端用戶界面如圖16示。包括聽課端視頻顯示區、授課端視頻顯示區、課件瀏覽區、功能按鈕區、授課端狀態顯示區等5部分，其中，課件瀏覽區和授課端顯示區這兩部分與授課端保持一致。
■課堂服務中心的用戶界面課堂服務中心的用戶界面如圖17示。包括聽課端視頻顯示區、授課端視頻顯示區、授課端狀態顯示區、聽課端狀態顯示區、功能按鈕區以及MCU狀態信息顯示區等6部分。其中，聽課端視頻顯示區可以任意切換到任何一個聽課點上。
本發明與現有技術相比，所產生的效果是1.聽課端個數可同時支持20個以上教室的同步實時授課，並可同時支持4個以上不同子網之間的視音頻交互。
2.課件格式支持HTML/XML文檔、Word文檔、Powerpoint、MPEG4、RM、RAM、VRML等格式的課件，並能方便地擴充新的格式。
3.課件質量以640×480窗口或800×600全屏方式清晰顯示課件內容。
4.視頻交互遵循H.261標準實現視頻數據實時採集和回放、融合，視頻質量由QoS控制機制保證。
5.語音交互遵循G.711標準實現音頻數據實時採集和回放、融合。
6.視音頻同步唇音同步誤差≤0.5秒。
7.系統延時系統的影像、聲音及課件內容在Internet/校園網上傳輸時延小於2秒。
8.應用程式共享遵循T.120協議，支持各種Windows應用程式共享。
9.電子白板遵循T.120協議。
權利要求
1.一種基於IP網的多媒體實時授課系統RealClass，其特徵在於它包括，授課端、聽課端、課堂服務中心以及多點控制單元(Multipoint Control Unit，MCU)四個部分組成；其中授課端是指教師通過網絡為聽課端提供授課現場的實時視頻、音頻及電子教案，並通過電子白板、應用程式共享以及文本Chat等工具與聽課端進行交互，此外授課教師還可對整個教學過程進行控制的授課平臺；授課端由一實現與課堂服務中心進行狀態、控制信息的交互，並能根據交互結果對底層的視頻、音頻數據採集、傳輸、發送、回放進行的事務管理模塊，底層的視頻、音頻數據處理是由Avmeeting控制項實現；Avmeeting控制項從本地的媒體設備中讀取視頻、音頻數據，並通過QoS數據發送控制項發送到本網段，即授課端網段的MCU；同時調用QoS數據接收模塊從本網段MCU讀取焦點聽課端的視頻、音頻數據，並將此數據與授課端的媒體數據在本地進行回放；聽課端是指學生通過網絡接收授課端的視頻、音頻及電子教案信息，當聽課端獲得交互權限後，還可與授課端進行視頻、音頻或其它方式的交互，聽課端與聽課端之間在授課教師許可的情況下也可通過分組方式進行交互的聽課平臺；聽課端由一實現與課堂服務中心進行狀態、控制信息的交互，並能根據交互結果對底層的視頻、音頻數據採集、傳輸、發送、回放進行的事務管理模塊，底層的視頻、音頻數據處理同樣是由Avmeeting控制項實現；Avmeeting控制項從本地的媒體設備中讀取視頻、音頻數據，並通過QoS數據發送控制項發送到授課端網段的MCU；同時調用QoS數據接收模塊從本網段MCU讀取授課端的視頻、音頻數據，對於非焦點聽課端，讀取的是授課端和焦點聽課端融合後的數據，並將此數據與本地的媒體數據在本地進行回放；課堂服務中心是指管理員用於對授課系統進行監控的控制臺，並充當視頻會議系統中的GateKeeper；其通過與授課端、聽課端、MCU的狀態和控制消息交互，實時獲取RealClass系統的狀態，並對RealClass系統各個端結點的工作進行控制；多點控制單元(Multipoint Control Unit，MCU)是完成系統中視頻、音頻數據的路由、轉發以及處理，系統採用了分布式MCU機制，即在系統所分布的每個網段中都存在一個MCU結點多點控制單元(Multipoint Control Unit，MCU)可分為多點控制器MC和多點處理器MP兩部分；多點控制器MC包含多點交互控制和QoS參數確定兩個模塊；多點交互控制模塊的通過對多點處理器MP的操作實現對遠程教學過程中的授課端和聽課端的視頻、音頻交互控制，此外，它還根據與課堂服務中心交互的命令與狀態信息生成當前MCU與其它端結點，即授課端、聽課端、其它MCU連接的狀態信息；QoS參數確定模塊根據此狀態生成當前MCU的各個輸出媒體流的QoS參數，此參數將傳遞給多點處理器MP中的QoS控制機制，作為其為每個輸出媒體流分配網絡帶寬的依據；MP可分為QoS控制機制和視頻、音頻數據處理兩個模塊；其中視頻、音頻數據處理模塊是MP的核心模塊，由MC中的多點交互控制模塊驅動，視頻、音頻數據處理模塊獲取QoS控制機制整形後的數據，對其進行數據融合和轉發等處理，並將處理後的數據傳送到QoS控制機制進行發送；MP的QoS控制機制根據MC傳遞來的QoS參數以及當前的網絡狀態進行QoS控制，包括對視頻、音頻數據處理模塊處理後的多媒體數據進行帶寬分配和發送，以及對由其它端結點發送來的多媒體數據進行整形。
2.根據權利要求1所述的基於IP網的多媒體實時授課系統RealClass，其特徵在於所述的QoS控制機制是一種基於分層結構的動態自適應QoS分布控制模型，該模型一方面採用基於端結點的分布控制，並在端結點引入動態自適應的流控機制，使得本模型不僅具有較強的可擴展性，而且還能根據網絡狀態自動調整控制策略；另一方面，採用多角度解決策略，將與QoS控制相關的網絡技術、視頻編碼技術以及FEC(Forward Error Correction)容錯技術基於分層結構進行有機集成，從而使得QoS模型在帶寬受限的情況下也能為媒體流傳輸提供較好的服務質量；對QoS問題的解決採用的是多角度、多層次的解決策略；把QoS控制模型分為QoS控制層、RTP層以及FEC層三個層次，並將網絡傳輸、視頻編碼以及FEC容錯這三個QoS的具體控制措施有機分布到這三個層次之中；QoS控制層主要實現多媒體數據傳輸的準入控制、流量控制和區分服務；主要措施為對音頻數據流採用固定帶寬分配策略；對於視頻數據流，則採用動態自適應的帶寬分配策略；在此基礎上，根據H.261、H.263、MPEG I、MPEG II等視頻編碼的特性，視頻編碼幀可以分為設計了一個選擇發送視頻幀的算法，本算法保證了在數據包不丟失的情況下，發送到對方的編碼數據都可被正確解碼，且解碼後的數據具有最優的表現質量；RTP層主要實現多媒體數據包的實時、有序傳輸，並通過RTCP包的交互動態獲取當前數據傳輸的時延、抖動、丟包率等網絡狀態參數，這些參數不僅是QoS控制層進行帶寬分配的依據，也是FEC層實施動態FEC機制的主要依據；FEC層主要功能是為上層提供一條透明的可靠傳輸通路，避免因網絡傳輸丟包導致的重傳；本層還引入了反饋機制，即根據當前的丟包率，動態控制FEC數據包的發送。
3.根據權利要求1所述的基於IP網的多媒體實時授課系統RealClass，其特徵在於所述的多點控制單元MCU是一種基於分布式MCU的組播數據的跨網段傳輸機制；MCU分布在每個網段中；在各網段內部，MCU向同網段的各個結點以組播方式發送數據；在各網段之間，授課端MCU向其它各個網段MCU以單播方式發送數據；此外，授課端與焦點聽課端的數據則單播發送到授課端MCU；該機制實現了廣域網上視音頻數據的組播傳輸，有效提高了網絡帶寬利用率，使得系統具有較好的可擴展性。
4.根據權利要求1所述的基於IP網的多媒體實時授課系統RealClass，其特徵在於所述的視頻、音頻數據採用兩種課件同步錄製機制一種是實時錄製工具RealScreen，即實時採集教案內容、教學現場的視頻、音頻數據，並壓縮生成流媒體(如rm或MPEG-IV等格式)文件，供課後點播；二是HTML-Recorder，即將教學內容轉換成超文本(HTML文檔)，並和實時錄製視頻、音頻同步集成，形成「HTML+流媒體」格式的課件；實時錄製工具RealScreen採用了第一種技術路線在授課端，RealScreen通過定時截取屏幕或窗口獲得當前教案內容的內存BMP映像，同時將當前視頻捕獲設備採集到的視頻幀數據轉化成內存BMP格式，然後將兩部分BMP數據在位圖基礎上進行融合，並將融合後的數據發送到流媒體壓縮引擎上；RealScreen同時還將音頻設備採集到的音頻數據也發送到該引擎；壓縮引擎將接收到的融合數據作為視頻數據進行實時編碼，同時將接收到的音頻數據也進行實時編碼，並將編碼後數據一起發送到流媒體伺服器；此外，流媒體壓縮引擎還可將編碼數據以RM文件形式在本地進行保存；HTML-Recorder工具採用技術路線二，HTML-Recorder工具可以和RealClass系統配合運行，是一個後臺程序；它一方面實時地採集教師的視頻、音頻數據並生成ASF流媒體文件，另一方面它將教師對教案的操作實時記錄在時間戳日誌中，包括教案換頁、顯示每個條目的時間戳等；當運行結束時，HTML-Recorder自動將時間戳寫入ASF文件；並將PowerPoint格式的教案轉化為一系列HTML網頁及相關媒體文件；最後，將攜帶時間戳的ASF文件與HTML格式的教師教案按照固定的框架(Frame)進行封裝，從而生成教學課件。
全文摘要
本發明公開了一種基於IP網的多媒體實時授課系統，其由授課端、聽課端、課堂服務中心以及多點控制單元(Multipoint Control Unit，MCU)四個部分組成；它通過教學現場的多媒體錄製和網絡傳輸，實現教學現場的直播，並通過師生多媒體多模式交互、教師自然板書授課、教學內容檢索、應用程式共享、課件同步瀏覽、電子白板、課件實時錄製、課堂管理等功能，解決傳統課堂教學在時間和空間上的制約問題，大大擴展了教學規模，實現名師授課及教育資源的共享。
文檔編號G06F15/16GK1400541SQ0213937
公開日2003年3月5日 申請日期2002年8月20日 優先權日2002年8月20日
發明者鄭慶華, 劉均, 李洋 申請人:西安交通大學