rtsp協議范文
時間：2023-04-10 23:41:46
導語：如何才能寫好一篇rtsp協議，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。
篇1
關鍵字：VRRP ； MSTP ； 路由冗余； 負載均衡
中圖分類號：TP393.02 文獻標識碼：A DOI：10.3969/j.issn.1003-6970.2013.07.034
本文著錄格式：[1]程寧.VRRP和MSTP協議在企業園區網的應用與研究[J].軟件，2313，34（7）：100-103
0 引言
隨著信息技術的不斷發展，越來越多的企業開始建設自己的園區網。在設計園區網絡時，為了使網絡工作的更有效率，對于大型園區網絡普通采用三層架構，即接入層、匯聚層和核心層，如圖1所示；對于規模較小的網絡也可簡化為二層架構，即接入層和核心層。
如圖1所示，網絡共分為三層，其中接入層允許終端用戶連接到網絡；匯聚層是多個接入層的匯聚點，它必須能夠處理來自接入層設備的所有通信量，并提供到核心層的上行鏈路；核心層作為網絡的中心結點負責網絡內各子網之間的數據轉發并提供互聯網接入服務。為了提高網絡的可管理性，抑制網絡中的廣播流量，隔離不同的廣播域，可以根據用戶所處的物理位置或隸屬關系劃分不同的VLAN[1]。為了提高可靠性每一層的設備和上一層的設備之間可以存在多條冗余鏈路，以避免出現因為單點故障導致網絡癱瘓。由于網絡中存在著冗余鏈路，利用MSTP技術消除環路和不同VLAN間的流量負載均衡；利用VRRP技術實現路由冗余和負載均衡設計。
1 VRRP和MSTP協議分析
1.1 VRRP協議分析[1-3]
虛擬路由冗余協議VRRP﹙Virtual Router Redundancy Protocol﹚是由IETF制定的，是一種容錯協議，為具有組播或者廣播能力的局域網設計。
VRRP協議將兩臺或多臺路由設備虛擬成一個虛擬路由設備，對外提供一個或多個虛擬的IP地址。使用VRRP創建的虛擬路由器被稱為VRRP組，在 VRRP 路由器組中，按優先級選舉 Master 路由器和Backup路由器。Master 路由器實現針對虛擬路由器 IP 的各種網絡功能，如 ARP 請求、ICMP 消息和數據的轉發等；Backup 路由器不擁有該 IP，除了接收 Master路由器發送的 VRRP 通告信息外，不執行對外的網絡功能。僅當主機失效時，Backup 路由器接管原先 Master 路由器的網絡功能。
在VRRP協議中，Master周期性以組播的形式發送VRRP通告報文，以便Backup了解Master的工作狀態。如果Backup在一定時間內沒有收到VRRP通告報文，則認為Master出現故障，重新選舉Master，以保證通信不會中斷，從而保證通訊的連續性和可靠性。
1.2 MSTP協議分析[1][4-6]
多生成樹協議MSTP（Multiple Spanning Tree Protocol）是IEEE 802.1s中定義的一種STP和VLAN結合使用的新型生成樹協議。STP（生成樹協議）通過在網絡中構造一棵自然樹的方法達到裁剪冗余環路的目的，同時實現鏈路備份和路徑最優化。但STP最大的缺陷在于收斂速度過慢，至少需要30秒的收斂時間。為了解決STP協議的這個缺陷，IEEE推出了802.1w標準，定義了RSTP（快速生成樹協議），與STP相比，收斂速度快得多，最快在1秒之內。但RSTP與STP一樣同屬單生成樹SST（Single Spanning Tree），有它自身的缺陷，主要表現在：第一，在網絡規模比較大的時候會導致較長的收斂時間，拓撲改變也比較大；第二，由于鏈路被阻塞后將不承載任何流量，造成帶寬的極大浪費。為了克服單生成樹的這些缺陷，與是支持VLAN的生成樹協議（PVST/PVST+）應運而生。
PVST/PVST+協議能夠保證每一個VLAN都不存在環路。經過改進的PVST+協議在VLNA1運行的是普通STP協議，在其他VLAN上運行PVST協議。PVST+協議可以與STP/RSTP互通。但PVST/PVST+協議也有自身的缺陷：第一，由于每個VLAN都需要生成一棵樹，PVST BPDU的通信量將正比于Trunk的VLAN個數。第二，在VLAN個數比較多時，維護多棵生成樹的計算量和資源占用量將急劇增長。多實例化的MSTP協議應運而生。
多生成樹協議MSTP（Multiple Spanning Tree Protocol）是IEEE 802.1s中定義的一種新型多實例化生成樹協議。MSTP中引入了“實例”（Instance）和“域”（Region） “的概念。所謂“實例”就是多個VLAN的一個集合，這種通過多個VLAN捆綁到一個實例中去的方法可以節省通信開銷和資源占用率。MSTP各個實例拓撲的計算是獨立的，在這些實例上就可以實現負載均衡。
MSTP協議把支持MSTP的交換機和不支持MSTP交換機劃分成不同的區域，分別稱作MST域和SST域。在MST域內部運行多實例化的生成樹，交換機間使用MSTP BPDU交換拓撲信息；在MST域的邊緣運行RSTP兼容的內部生成樹IST（Internal Spanning Tree）。SST域內的交換機使用STP/RSTP/PVST+BPDU交換拓撲信息。在MST域與SST域之間的邊緣上，SST設備會認為對接的設備也是一臺RSTP設備。而MST設備在邊緣端口上的狀態將取決于內部生成樹的狀態，也就是說端口上所有VLAN的生成樹狀態將保持一致。
2 VRRP和MSTP技術在企業網中的應用方案設計
2.1 案例需求
某企業為了滿足公司經營和統一管理的實際需要，需要建設自己的信息化網絡。該公司設有市場部、人力資源部、財務部、售后服務部等4個部門，要求在組網時充分考慮網絡的管理性和可靠性。
為了真實地模擬企業網的互連環境，搭建如圖2所示的企業網絡架構圖，該網絡架構為典型單核心的三層架構。其中核心層用1臺S5750交換機模擬，匯聚層用2臺S3550交換機模擬，接入層用2臺S2126G交換機模擬。為了抑制網絡中的廣播流量，隔離不同的廣播域，將4個部門劃分在不同的VLAN，設計了VLAN10（市場部）、VLAN20（人力資源部）、VLAN30（財務部）、VLAN10（售后服務部）共4個子網，所有接入層的的設備都可以經過匯聚層和核心層的交換設備訪問網絡中心服務器或外部網絡，相同VLAN間的計算機可以實現相互訪問。
為了提高網絡的可靠性，路由冗余和負載均衡是需要考慮的問題，因此設計通過匯聚層訪問網絡中心或外部網絡的數據流，利用VRRP實現路由冗余和負載均衡，不同地理位置同一VLAN間計算機通信的數據流，利用MSTP實現路由冗余和負載均衡。
2.2 實現過程
2.2.1 VRRP安全策略設計
對于需經過S31和S32的數據流，設計規劃如下，VLAN10和VLAN30子網到網絡中心或外部的數據以S31為主核心交換機，S32為備份交換機，在S31交換機上對VLAN10和VLAN30設置同等的訪問優先級，優先級設置為254，而VLAN20和VLAN40則采用默認優先級，默認值為100；VLAN20和VLAN40子網到網絡中心和外部的數據以S32為核心交換機，S31為主核心交換機，在S32交換機上對VLAN20和VLAN40設置同等的訪問優先級，優先級設置為254，而VLAN10和VLAN30則采用默認優先級。
2.2.2 MSTP安全策略設計
對于不同地理位置同一VLAN間的數據流，設計規劃如下：將VLAN10和VLAN30加入到實例1中，將VLAN20和VLAN40加入到實例2中，并設置S31為實例2的根節點，設置S32為實例1的根結點。在S31上設置實例1的優先級為4096，實例2的優先級為8192；在S32上設置實例如的優先級為8192，實例2的優先級為4096。
2.2.3 IP地址規劃
2.2.4 配置過程
具體的配置過程如下：
1、基本信息和VRRP的配置
3 結束語
在深入了解VRRP和MSTP協議實現原理的基礎上，通過具體案例實現VRRP+MSTP結合實施的思路和實現方法，消除了網絡中的單點故障，建立一個可靠的企業園區網。
參考文獻
[1]吳兆紅，陳增吉 .大型園區網絡可靠性設計與實現 [J]. 山東師范大學學報， 2008， 23（4）： 43-46.
[2]王軼群 .VRRP路由協議介紹及配置 [J]. 赤峰學院學報（自然科學版）， 2013（3）： 20-22.
[3]王可 .一種高可靠性園區網設計思路與實現 [J]. 消費電子， 2012（7）： 123.
[4]劉藍田，王黎 .多生成樹（MST）協議特性及其應用 [J]. 現代電子工程， 2009（3）： 25-27.
篇2
關鍵詞：Gstreamer； 流媒體； RTSP； RTP/RTCP
中圖分類號：TN919.8 文獻標識碼：A 文章編號：1006-3315（2013）03-149-002
1．前言
流媒體技術以流的方式在網絡中傳輸媒體，具有良好的實時性和交互性。隨著3G、4G等高速移動通信技術的發展成熟和多媒體智能移動設備的普及，流媒體技術獲得了廣泛應用和迅速發展。本文基于GStreamer架構，采用RTP/RTCP協議實現數據傳輸，設計了一種流媒體播放器，處理芯片采用OMAP3430，操作系統為嵌入式Linux系統，借助高速網絡，可以實現高質量的流媒體播放。
2．相關技術介紹
2.1流媒體技術。流媒體是指以流的方式在網絡中傳輸音頻、視頻和多媒體文件的形式。流媒體文件格式是支持采用流式傳輸及播放的媒體格式。流式傳輸方式是將視頻和音頻等多媒體文件經過特殊的壓縮方式分成一個個壓縮包，由服務器向用戶計算機連續、實時傳送。用戶采用內容緩存的方式，只需要進行很短時間的緩沖，就可以一邊播放一邊下載，而不需要提前下載整個文件。
流媒體傳輸一般都是采用建立在udp協議上的rtp/rtsp實時傳輸協議。相對于注重傳輸質量的tcp協議來說，udp協議更加注重傳輸速度，這種協議對于實時性要求很高的流媒體文件來說，無疑是更加合適的。
2.2Gstreamer概述。GStreamer是一種流媒體應用框架，采用了基于插件（plugin）和管道（pipeline）的體系結構，框架中的所有的功能模塊都被實現成可以插拔的組件（component），并且在需要的時候能夠很方便地安裝到任意一個管道上，由于所有插件都通過管道機制進行統一的數據交換，因此很容易利用已有的各種插件“組裝”出一個功能完善的多媒體應用程序。其主要功能模塊包括元件、襯墊、箱柜等。
元件(Elements)是Gstreamer框架中所有可用組件的基礎，是組成管道的基本構件。元件可以分為數據源元件、過濾器元件、接收器元件等，實現數據的輸入、處理和輸出等功能。
襯墊（pad）是元件（element）與外界的連接通道，每個襯墊都帶有特定的功能信息，通過將不同元件的襯墊依次連接起來構成一條媒體處理管道，使數據在流經管道的過程能夠被各個元件正常處理，最終就可以實現特定的多媒體功能。
箱柜(Bins):箱柜是一個可以裝載元件的容器，同時其自身也是一個GstElement對象，也能夠被用來容納其他的箱柜對象。
2.3實時傳輸協議（RTP/RTCP）。RTP/RTCP協議棧由兩個相互緊湊的協議組成，其中RTP協議負責傳送具有實時特征的多媒體數據，而RTCP協議負責反饋控制、監測QoS、監視和傳遞相關信息。由于流媒體數據傳輸對于傳輸實時性的要求遠高于傳輸可靠性，RTP/RTCP數據通常采用UDP/IP封裝，它們共同完成網絡傳輸層的功能。
2.4實時流媒體協議（RTSP）。RTSP協議是一種對流媒體數據的傳輸進行控制的應用級協議。通過RTSP協議，可以實現音視頻的控制、點播等功能。
3．流媒體播放器的實現
本文設計的流媒體播放器，可以分為以下幾個模塊：用戶界面、RTSP控制模塊、RTP/RTCP傳輸模塊、數據轉換模塊、解碼模塊、視音頻輸出模塊。如圖1所示。用戶通過用戶界面與客戶端交互，RTSP模塊響應用戶界面發送的命令，建立RTP數據傳輸會話，會話建立之后，由RTP/RTCP模塊循環接收RTP數據包并進行排序，然后轉換模塊對RTP數據進行解包，轉換成原始的音視頻數據，然后送入解碼模塊進行解碼，最后通過音視頻輸出模塊將媒體展示給用戶。
圖1流媒體播放器架構
用戶界面是客戶端跟用戶之間交互的界面，它包括兩部分內容：一是媒體播放控制，比如暫停、快進等；二是媒體內容的展示，比如視頻畫面的顯示等。在Linux系統下，本文利用GTK+庫開發GUI框架。
RTSP模塊用于會話的建立和控制，它提供響應界面操作的接口，直接響應界面發送的命令。RTSP也提供互聯的雙方或多方的一個傳輸方式和編碼方式的協商操作，在網絡允許的情況下，建立一條最佳的傳輸通道。當客戶端用戶選擇服務器上某項流媒體內容的時候，播放器會通過RTSP協議，與服務器建立會話，通知服務器往本地RTP接收端口發送音視頻數據。
RTP/RTCP模塊為流媒體播放器的核心組成部分，當RTSP建立傳輸會話之后，RTP和RTCP會各使用一個端口，RTP端口會循環接收RTP數據包,同時RTCP端口會周期性的發送RTCP報，RTCP包中包含已發送的數據包的數量、丟失的數據包的數據等統計資料，因此，服務器可以利用這些信息動態的改變傳輸速率，甚至改變有效載荷類型。RTP包由RTP包頭和RTP數據構成，RTP包頭中包含了一些可以較好保證流數據連續性實時性的信息，如序列號、時間戳等。序列號可以保證到達客戶端的RTP包的連續，而時間戳可以同步音視頻包。根據包頭中的時間戳接收的數據包進行重新排序，然后傳送到轉換模塊進行處理。
4．小結
本文采用Gstreamer架構，對RTP/RTCP/RTSP協議進行了深入研究，設計了一種基于Linux系統的流媒體播放器，通過構建RTP/RTCP流媒體傳輸插件，實現了流媒體數據的實時傳輸和播放，在終端設備中可以取得良好的流媒體播放效果。
這種基于Gsreamer的媒體播放器具備良好的靈活性和可移植性，借助高速傳播網絡，特別適合在各種不同類型的智能終端實現流媒體的接收和播放等功能，在視頻監控、遠程會議、視頻教學、多媒體娛樂等多種不同場合都可以獲得廣泛應用。
參考文獻：
[1]孫弼陽，李虹，王穎．移動流媒體業務的技術與應用[J]現代電信科技，2008（06）：13-18
[2]陳丹，郭先會.RTP/RTCP協議在3GPP移動流媒體業務中的研究與應用[J]山西電子技術，2010(06):65-66
[3]陳洪敏．基于RTP/RTCP協議流媒體傳輸的研究[J]福建電腦.2010(02):93-94
[4]王蕊，劉衛東，王金童．基于GStreamer的媒體播放研究[J]電子設計工程.2012(03):34-36
篇3
【關鍵詞】移動通信網絡 監控系統 設計
移動終端不斷普及，臺式機、筆記本和移動終端的界限越來越模糊，很多功能都可以轉移到移動終端上，同時移動終端無論從聽說讀寫還是從感知方面都擁有電腦所沒有的優勢。作為移動互聯網業務之一，移動平臺的網絡監控，也開始逐漸發展起來。
1 移動通信Android平臺簡介
Android的系統架構和其操作系統一樣，采用了分層的架構。 Android結構分為四個層，從高層到低層分別是應用程序層、應用程序框架層、系統運行庫層和Linux內核層。Android會同一系列核心應用程序包一起，該應用程序包包括客戶端，SMS短消息程序，日歷，地圖，瀏覽器，聯系人管理程序等。所有的應用程序都是使用JAVA語言編寫的。Android系統既是一個完全開放的系統，也是一個完整的生態系統。
2 移動通信Android開發環境
2.1 安裝Java語言運行環境
Android應用程序采用Java代碼開發，在Win 7系統下，需要Java編譯器JDK，經典版本是JDK1.6，安裝JDK之前要先安裝JRE，即Java運行時環境，就是Java運行虛擬機。
2.2 下載安裝Eclipse和Android SDK
為了更好地可視化地編譯Java代碼，還需要一個Java編譯的IDE，Eclipse是一個開放源代碼的、基于Java的可擴展開發平臺。Eclipse是編譯Java的優秀的可擴展的IDE，本文使用Eclipse環境結合Android SDK進行Java代碼的開發。下載Eclipse并解壓到某一目錄，就能使用。AndrnidSDK的同樣只需到相應網站下載，解壓即可"這里還需AndroidsDK。
2.3 更新Eelipse，安裝Android開發插件ADT
Google為Android定制了一個Eelipse插件，即AndroidDevelopment
Kit（ADT）"ADT插件專用于擴展Eclipse的功能，為用戶能夠快速地開發Android項目提供方便"例如，快速建立Andro記項目，使用XML布局文件創建應用程序界面等" 安裝好ADT后，安裝好ADT后，就能創建Android Project了。
3 移動通信網絡監控系統方案設計
3.1 系統架構
該系統開發一個開放源碼的解決方案，能夠用很小的開銷在手機或者服務器上交換現場視頻。用戶只需要一個Android移動設備和通過WiFi或蜂窩網絡。建立的網絡連接，就可以直接上傳或者播放現場視頻，達到實時監控的目的。
3.2 系統編碼協議和實時傳輸協議
3.2.1 H.263
H.263是由ITU-T制定的網絡會議用的低碼率視頻編碼標準，屬于網絡信息編解碼器。H.263最初設計為基于H.324的系統進行傳輸（即基于公共交換電話網和其它基于電路交換的網絡進行網絡會議和網絡電話）。后來發現H.263也可以成功的應用與H.323（基于RTP/IP 網絡的會議系統），H.320（基于綜合業務數字網的會議系統），RTSP（流式媒體傳輸系統）和SIP（基于因特網的會議）。H.263在2010年和2012年調整為更高質量的流。H.263從眾多類似的信息編碼/解碼標準中脫穎而出，因為它被谷歌Android操作系統所采用，因此目前市場上大多數的Android設備都支持。除了良好的兼容性，H.263是一種低帶寬流，使得能夠在第三代（3G）蜂窩網絡上工作。
3.2.2 實時傳輸協議（RTP）
實時傳輸協議（RTP），是定義了一種傳輸音頻和視頻的報文格式，這些音頻和視頻在互聯網或本地網絡上采用各種不同的編碼器類型進行編碼。RTP通過UDP進行傳輸，而不需要TCP確認或TCP ACK數據包。UDP作為向服務器傳送的報文類型原因之一就是不需要ACK數據包。例如，如果發送視頻的設備或用戶進入一個較差的蜂窩覆蓋區域，可能會導致沒有足夠的帶寬將所有的數據包及時地從服務器發送給用戶來觀看事件。這將會導致一個時斷時續的視頻，不過視頻仍在傳輸。最壞的情況是用戶進入一個完全沒有蜂窩網絡的區域，在用戶端的播放裝置就會完全停止；直到設備到達了一個可以傳輸數據包的區域，播放器才能重新顯示。
3.2.3 實時流傳輸協議
實時流傳輸協議（RTSP）是用來控制播放RTP流。RTSP服務器允許播放器接收從設備發送的RTP數據包。播放器（例如VLC或ffmpeg）不能直接打開一個RTP流，因此，RTSP服務器需要提供其他的流信息并控制流數據包的開始和停止。RTSP服務器是基于RFC2326。它包含以下命令：選項，描述，宣布，設置，播放，暫停和拆卸。基于RFC4566的會話描述協議（SDP）與描述命令配合使用。
4 系統實現方案
該系統將信息編解碼協議，RTP協議以及RTSP協議相互關聯并組成一個界面友好的、操作簡單的應用程序。系統應實現由Android設備的獲取信息流，傳輸至信息服務器，并可以在基于WEB瀏覽器的終端網頁上的播放實時信息流。
服務器打開許多不同的偵聽端口接收傳入連接。端口使用的協議是TCP和UDP。服務器產生兩個監聽器，一個用于客戶或播放器查看接收到的信息，另一個用于用戶或手機發送信息。每個新的TCP或UDP端口需要一個額外的線程。每產生一個新的線程類型就要增加一個新的Java類。一個并發哈希表將用于同步用戶觀看信息和手機線程之間的信息流。
參考文獻：
篇4
【關鍵詞】Android；視頻監控；智能手機
1 移動流媒體技術
移動流媒體技術就是把連續的聲音影像信息經過壓縮處理后傳送到網絡服務器上，讓終端用戶能夠在下載的同時觀看收聽，而不需要等到全部的多媒體文件下載完成就可以即時觀看的技術。移動流媒體技術的出現是伴隨這移動通信技術的發展和網絡音視頻技術的進步，其只要是關于流媒體數據從采集到播放整個過程中所需要的核心技術。流媒體播放技術有優點也有缺點。優點是能夠及時傳送隨時播放，缺點是由于網絡的速率不穩定性，當播放速率大于傳輸速率時，視頻播放將出現停滯，時斷時續的現象。
2 Android的視頻監控系統
基于Android的視頻監控系統分為五個模塊：依次為采集模塊、編碼模塊、視頻傳輸模塊、解碼模塊、顯示模塊，下面分別進行詳細介紹。
2.1 視頻采集模塊
Android攝像頭采集到的視頻格式為YUV420格式的視頻流。采集模塊的實現可以在Android的應用層中通過編寫代碼來實現。
2.2 編碼模塊
數字視頻編碼標準主要由兩個標準化組織制定。MPEG制定的視頻編碼標準有MPEG-1，MPEG-2，MPEG-4。ITU一T制定的視頻編碼標準有H.261和H.263。為了促進下一代多媒體通信的應用， MPEG和VCEG共同成立了聯合視頻工作組（JVT），共同開發了視頻編碼標準H.264。H.264是目前最先進的視頻編碼標準。
H.264視頻編碼標準是目前最新的技術，雖然H.264遵循了原來壓縮標準的架構，但是H.264具有一些新的特性，H.264標準分兩層結構，包含網絡抽象層（NAL）和視頻編碼層（VCL）。網絡抽象層用于數據打包和傳輸，編碼層負責視頻壓縮編碼，這種分層結構，實現了傳輸和編碼的分離。由于H.264標準引入了數據分割等抗誤碼技術，實現了在復雜環境下的使用，可以適應不同網絡的傳輸要求。由于采用高度復雜的實現算法，H.264是目前低碼率下壓縮率最高的編碼標準，在帶寬不穩定的無線網絡上有著無法比擬的優點。
2.3 傳輸模塊
流媒體傳輸和控制協議在應用層主要涉及到HTTP，RTSP，RTP和RTCP協議，在傳輸層有TCP和UDP協議。HTTP是建立在傳輸控制協議（TCP）之上的超文本傳輸協議。TCP/IP協議是專為數據傳輸而設計的，能夠保證傳輸的可靠性。RTP是在一對一或一對多的情況下針對流媒體數據流工作，不僅能夠提供時間信息而且可以保證數據流的同步。通常RTP建立在UDP之上，使用UDP傳輸數據。RTP本身沒有可靠的傳送機制，其流量控制和擁塞控制是由實時傳輸協議（RTCP）來提供的。RTP和RTCP共同協作才能完成流媒體的傳輸和控制。實時流協議（RTCP）是應用層協議，位于RTP和RTCP協議層之上，通過IP網絡傳輸多媒體數據，在傳輸機制上采用TCP和RTP完成數據傳輸。RTSP用于控制實時數據的發送，提供用于音視頻流的VCR遠程控制功能和用于控制流媒體的播放、暫停、記錄等操作。會話描述協議SDP，SDP是用來描述RTSP，以便說明一個流媒體會話的基本屬性。結合移動視頻監控系統對通信實現的特點，本文采用RTP，RTSP，RTCP和HTTP協議完成視頻監控系統的通信和遠程控制。
一個最基本的流媒體系統包括編碼器，流媒體服務器和客戶端播放器三個部分。各個模塊之間的數據通信交換都是按照特定的協議。編碼器用來將原始的音視頻轉換成合適的流媒體格式文件，服務器用來接收和轉發編碼后的媒體流，客戶端則是負責解碼和播放接收到的流媒體數據。流媒體傳輸有兩種方式，一種是順序流式傳輸，一種是實時流式傳輸。
（1）順序流式傳輸。順序流式傳輸就是順序下載。用順序流式傳輸方法基于標準HTTP或FTP服務器來傳輸文件，通常容易管理，方便用戶的使用。整個下載過程是無損的，能夠保證視頻的高質量，但是用于網絡傳輸速率的問題，一般需要等待較久的時間。順序流式傳輸常用于對視頻質量要求較高的場合，對實時性，隨機訪問性要求較高的場合則不適用。
（2）實時流式傳輸。實時流式傳輸能夠保證信號帶寬與網絡連接的匹配，實現實時傳送，適合現場直播，支持隨機訪問，用戶可進行快進后退操作。實時流式傳輸需要傳輸網絡協議和專用的流媒體服務器。由于這些協議與防火墻有關，在使用時一需經過配置。系統設置，管理比順序流式傳輸復雜。由于必須匹配連接帶寬，在低速連接設備時或者網絡擁塞時，會出現丟幀現象，導致視頻質量下降。
2.4 解碼模塊
解碼從性質來來講，其實是編碼過程的逆過程。編碼采用H.264進行編碼，所以該模塊也采用H.264進行解碼。解碼器的整體設計可以分成兩部分，一部分是視頻數據的解碼部分，主要用C語言來實現，采用Android NDK+C的實現機制。另外，一部分是視頻的顯示部分，主要采用Android提供的組件來實現，采用Android SDK+Java的實現機制。而這兩部分的集合，則是通過java提供的jni機制來實現Java和C語言之間的通信。整個解碼流程可分為三個功能模塊：前段碼流處理、H.264解碼和后段視頻顯示。
（1）前段碼流處理：主要負責文件的讀取，從碼流中分隔出NAL然后交給底層進行解碼處理。
（2）H.264解碼：整個解碼的核心部分，通過本地C語言的實現和解碼庫對碼流數據進行處理，完成H.264解碼實現圖像重建。
（3）后端視頻顯示：接收H.264解碼模塊解碼后的視頻數據，在客戶端進行顯示。
通過分析三個模塊的功能可知，H.264解碼模塊是最耗費資源的。H.264視頻標準為了更好的適應網絡傳輸的特性，采用了分層設計的思想既視頻編碼層VCL和網絡提取層NAL。
2.5 顯示模塊
通過調用Android自帶的顯示器，來顯示解碼后的本地數據流，從而達到實時視頻的顯示效果。
3 結束語
本文介紹了移動流媒體技術的概念及特點，考慮到網絡速率的不穩定性帶來的一些列影響，設計了一個基于Android的視頻監控系統，系統分為五個模塊，依次為采集模塊、編碼模塊、視頻傳輸模塊、解碼模塊、顯示模塊，這種系統很好地解決了視頻監控系統的安全性、實時性和穩定性等要求。
【參考文獻】
[1]溫敏，艾麗蓉，王志國.Android智能手機系統中文件實時監控的研究與實現[J].科學技術與工程，2009（4）：1716-1719.
篇5
關鍵詞：3G技術；J2ME；手機視頻監控
中圖分類號：TP277
移動互聯網飛速發展給人們帶來了多樣化的網絡智能終端與互聯網功能，人們只需將所需的應用程序安裝在手機上即可享受此程序所帶來的服務，人們完全能夠實現在辦公和生活。并且隨著3G時代的來臨，手機視頻監控系統將會逐漸成為3G視頻應用中的重點，在通過手機視頻監控系統進行道路管理、公安執法、街道巡查以及事故應急指揮等操作已經基本實現，而在手機視頻監控系統中所采用的J2ME技術更是為手機客戶端進行遠程視頻接收與查看提供了更為便捷的方式，J2ME技術通過服務端口進行攝像和數據采集，并將數據傳送至中心服務器進行視頻圖像壓縮，為用戶提供高清流暢的視頻資源，用戶只需通過手機即可對所需視頻進行瀏覽。
1 關鍵技術
1.1 H.264技術
H.264是由ITU（國際電信聯盟）和ISO（國際標準化組織）聯合組建的數字視頻壓縮格式，在ITU-T中其是以H.26x系列為名稱命名，在ISO/IEC中，它又被稱為MPEG-4高級視頻編碼。H.264技術的提出主要為了在現有的視頻編碼標準器的基礎上進行帶寬優化，為相同帶寬下的使用者提供更為優質的視頻圖像。H.264不僅能夠為用戶提供連續性的流暢高質量視頻圖像，還具有極強的容錯能力，讓使用者在網絡環境不穩定的情況下避免出現數據丟失的情況。采用先進整數變換、幀間預測與幀內預測技術的H.264系統技術具有超高的數據壓縮比率，能夠使高清流暢的視頻圖像順利傳送至用戶接收端口，在傳輸過程中實現帶寬減少，節約數據資源。
1.2 J2ME技術
J2ME又稱Java ME，其包括JVM規范與API規范技術，是通過JCP制定、與Java SE、Java EE并稱Java技術的三大版本。J2ME的虛擬機技術可以為用戶提供無線和有線連接，使用戶能夠隨需進行應用程序的使用。J2ME采用了JAVA虛擬機技術為各類的嵌入式消費電子設備提供JAVA語言平臺，是一種高度優化下的JAVA運行環境，其運行目標多樣化，能夠滿足各方面的用戶需求。
1.3 RTSP協議
RTSP不僅是一種實時流傳輸協議，同時也是TCP/IP系統中的一項應用層協議，其可以有效控制流媒體數據進行有線或無線網絡數據的傳送，還能夠為用戶提供視頻模式的遠程控制功能，包括對視頻圖像進行快進、后退、停止和定位等基本操作，RTSP還允許用戶進行同時多個串流需求控制，在服務器端口可根據需求選擇是否使用TCP或UDP來進行數據內容的串流傳送。除此之外，RTSP還可根據實際負載情況進行服務器轉換和重新導向加載功能，避免數據負載造成服務器延遲，并通過與低層協議結合為基于網絡環境下的數據傳輸提供流化服務。
2 基于J2ME的手機實時監控系統的設計
2.1 系統設計
手機視頻監控系統體系結構如圖1所示，手機視頻監控系統主要由前端采集、中心服務器和客戶終端構成，通過前端采集視頻圖像，并在監控中間的服務器中進行數據分析、整理并壓縮，最后通過有線和無線網絡環境傳輸至客戶終端進行視頻圖像的釋放。
2.2 客戶端
監控系統客戶端口通過了J2ME平臺進行設計，主要用于滿足用戶登錄需求與信息的收發，客戶端讀取服務器響應信息后自動選擇視頻數據源來接收圖像并實現實時播放，同時可以根據用戶需求進行視頻切換、屏幕圖案捕捉、保存視頻信息等處理，用戶只需通過服務器登陸并進行驗證，在通過驗證后從服務器發送的視頻設備列表中提取需要的視頻源，選擇接收視頻圖像即可，在視頻播放期間還可進行各種基本的簡易操作。
2.3 視頻服務器
該系統既要向終端提供和傳輸圖像，還要給客戶提供可在web端口進行瀏覽的視頻數據，這就要求J2ME系統必須滿足不同客戶端口的數據傳輸要求，設置不同規格的視頻壓縮模式。可采用低碼流、高質量圖像的H.264來進行視頻壓縮。H.264的轉碼模塊主要由核心轉碼器、接收和發送模塊構成，接收模塊與網絡監控相連，為用戶提供調用指令，同時接收和提取來自監控端口的格式編碼、幀率、分辨率和碼率等視頻流，核心轉碼器將視頻流信息轉換成H.264視頻格式，并同步用戶選擇來修改視頻分辨率，轉碼后進行TS/ES流分裝，最后通過網絡為用戶提供視頻數據。
3 基于J2ME的手機實時監控系統的實現
3.1 服務器端
服務器開發工具為VC6.0，采用了Windows 2003 sever操作系統，是一款微軟制作的C++編譯器。在操作過程中，先采用InitStreamClientLib函數對系統進行初始化，同時利用StartServer函數初始化服務器，接著啟動流媒體服務器，設置本地文件路徑，再啟用Run Server函數啟動服務器端口，如果需要結束服務端軟件，調用停止服務系統，再關閉系統服務即可。當服務端口接收到用戶需求信息時會自動開啟獨立數據傳輸與客戶端進行數據連接，然后利用圖像捕捉系統進行圖像捕捉并壓縮，最后將經過處理的圖像以JPEG的格式發送至用戶的手機接收端口。
3.2 手機客戶端
手機系統客戶端是一種方式移動信息設備程序，支持用戶在MIDP設備上運行MIDP應用并利用僅利用MIDP規范各種API的運行。其中WTK（Sun J2ME Wireless Toolkit）是Sun開發者研制的一款無線開發工具包，目的在于幫助開放人員更為便捷的進行J2ME的開發。而Eclipse（集成開發環境）則為無線開發者提供了一個全新的框架服務，并通過插件組件為使用者構建一個統一的開發環境。手機系統客戶端利用多樣化線程為用戶進行不同數據的傳輸與存儲，同時調用socket來與服務器端口進行通訊，為了給使用者一個更好的用戶體現，手機系統客戶端界面選用了MIDP（移動信息設備配置文件）來顯示用戶圖形界面，其主要運用程序包括Choice Group、Alert、Item、Form、Text Field、List等。在系統線程中主要使用的網絡連接主要通過Java.lang.Thread來進行數據傳輸，并未用戶提供Socket UDPDatagram Connection、Connection、ServerSocketConnection數據源接口，使MIDlet在TCP/IP層能夠通過socket作為BSD UNIX的進程通信機制來描述端口和IP地址。
4 結語
綜上所述，基于J2ME的手機實時監控系統的設計在近些年來已經逐漸成為3G時代下視頻應用的重要組成部分，使用者通過手機客戶端對服務器端所傳輸的數據來對視頻進行瀏覽和查看，為網絡數據的傳播提供了多元化的方式。且隨著J2ME系統中關鍵技術的進步和發展，J2ME手機實時監控系統將會為人們的生活提供更多的便捷服務，其在未來必然會擁有廣闊的發展空間。
參考文獻：
[1]夏幫貴.J2ME的手機視頻點播系統設計[J].電腦編程技巧與維護，2009（12）.
[2]劉桂英，周琴.基于J2ME平臺的手機實時監控的實現方法[J].工礦自動化，2008（1）：67-69.
篇6
關鍵詞:VOD;客戶端軟件;流媒體流量均衡裝置;ip filter driver hook
中圖分類號:TN919.85文獻標識碼:A
文章編號:1004-373X(2009)20-100-03
Implementation of Client End Software for New VOD Scheme
YANG Zhenlun,JIANG Yajun,HUANG Zhongwei
(Guangzhou Panyu Polytechnic College,Guangzhou,511483,China)
Abstract:Based on VOD scheme of load balancing equipments in stream medium,a new client end software is proposed.The client end software is developed under ip filter driver hook and raw socket.It redirects the users′ VOD demand in the way of network drivers operation.Cooperating with the advanced graded application structure of load balancing equipments of stream medium,it optimizes the application structure of VOD scheme and decreases the additional load of load balancing equipments of stream medium,improves the flexibility,efficiency and application prospects of VOD scheme.
Keywords:VOD;client end software;load balancing equipments of stream medium;ip filter driver hook
0 引 言
針對中小型園區網VOD應用中因網絡帶寬及點播服務器I/O帶寬不足導致的系統阻塞問題,作者前期的研究成果提出了一種新型網絡設備流媒體流量均衡裝置(以下簡稱流量均衡裝置),基于該裝置的VOD方案通過在VOD系統中添加多個流量均衡裝置,從而減輕點播服務器和主干網絡的負載,解決系統阻塞問題[1]。
該方案依賴流量均衡裝置內部的均衡策略,通過各個單點設備之間的協同來實現全局流量均衡,而由于每個單點設備只能獲取對應區域的點播狀況,因此實現全局均衡則需要各個設備進行頻繁且大量的信息交換,增加了每個單點設備的負載,也導致全局流量均衡收斂時間的延長,并且新的流量均衡設備加入后,需要一段時間才能融合到系統中,這限制了該VOD優化方案的應用。
為解決該問題,在此提出一種應用于該VOD方案的客戶端軟件,前述的VOD應用方案在引入了該客戶端軟件后,能進一步優化VOD應用結構,提高運行效率,增強該方案的實用性。
這里將分別對改進方案結構以及客戶端軟件的設計進行說明。
1 改進方案結構
通常的VOD系統都配有Web服務器,以提供節目列表[2],原來基于流量均衡裝置的VOD應用方案的點播需要Web服務器修改客戶機上網頁插件的屬性,使得用戶的點播請求重定向到每個區域指定的流量均衡裝置中,再由流量均衡裝置為之提供服務。由于目前VOD系統有若干種主流的點播軟件方案,用戶可能使用Real player,Media player或QuickTime player等幾種客戶端中的一種[3]。該方式需要根據客戶機上的不同點播軟件提供不同的配置方式,而實現全局流量均衡需要各個單點的流量均衡裝置之間的交互來獲知整個園區網的點播狀況,為了達到較快的全局均衡收斂速度,這種信息交互的頻率較高,這給資源相對有限的流量均衡裝置帶來一定的額外負載。如果降低信息交互的頻率,則會導致收斂性能的降低。
改進的VOD應用方案主要是在點播的客戶機上添加了一個與流量均衡裝置配合的客戶端軟件,該軟件除了能實現將客戶機的點播請求轉發到某個流量均衡裝置,實現各種點播軟件對流媒體流量均衡裝置的透明使用外,主要還提供一個額外的通信接口,流量均衡裝置可以通過該通信接口修改相應點播客戶機的點播請求轉發方向。在這種情況下,全局流量均衡主要是通過將點播客戶機的點播請求,依據全局網絡狀況轉發到最合適的流量均衡裝置處而得到實現。
為了實現這個目的,對VOD應用方案進行微調,根據具體數量將網絡中的流量均衡裝置分為兩級或者三級,每一級的下一層流量均衡裝置將所屬區域的網絡狀況發到上一層的流量均衡裝置中。最終匯總到一個事先指定的主控流量均衡裝置中,該流量均衡裝置根據全局流量均衡策略以及實際網絡狀況控制所有點播客戶機上客戶端軟件的點播轉發方向,如圖1所示。
2 客戶端軟件設計
該改進方案的關鍵在于客戶端軟件。客戶端軟件需要實現的最主要功能是將客戶機的點播請求重定向到流量均衡裝置中,并且引導服務器將流媒體數據發送到流量均衡裝置中。由于目前主流流媒體協議RTSP協議簇在發送流媒體數據前,必須在服務器及客戶端之間經過多次RTSP協商,確定具體參數,而后續的操作則根據RTSP協商的結果進行。如果在客戶機對點播軟件發起的RTSP協商過程進行干預時,則完全可實現點播全過程的重定向。本文客戶端軟件的設計思想正是基于這一點。實現RTSP協商數據包的重定向實質是實現數據包的截獲、修改和轉發,在客戶端發起連接時,從網絡底層將請求數據包攔截,并根據接收到的命令將其目的IP地址修改再發出去,接收到回復包再進行反向的處理,而這一切對于客戶機的點播軟件都是透明的。
由于目前VOD系統中的用戶端以采用Windows操作系統的微機為主,該客戶端軟件的設計面向Windows。在Windows下實現這些功能需要使用內核模式驅動程序[4]。目前適用于該客戶端要求的可選內核模式驅動模式包括:微端口NIC 驅動程序(Miniport NIC Drivers) 、中間層驅動程序( Intermediate Drivers) 、協議驅動程序(Protocol Drivers)以及過濾器鉤子驅動程序(IP Filter Driver Hook)等[5-7]。相比較而言,過濾器鉤子驅動程序具有處理流程簡單,效率較高的特點[8],并且從功能上能很好地滿足要求。該方案采用過濾器鉤子驅動程序進行設計。
過濾器鉤子驅動程序依賴于Microsoft 提供的IP 協議過濾驅動程序,在Windows 2000/XP 系統中,System 32\\drivers目錄下的ipfltdrv.sys是Microsoft 提供的IP 協議過濾驅動程序,它允許用戶注冊自己的IP 數據包處理函數,即過濾器鉤子函數[9]。本機所有進出的IP包都經操作系統的IP過濾驅動程序處理,而IP過濾驅動程序調用用戶定義的過濾器鉤子函數進行處理,確定是丟棄或者傳送。
該客戶端軟件由處于內核態的過濾器鉤子驅動程序和處于用戶態的應用程序組成,應用程序包括接收主控流量均衡裝置命令的監聽線程和配合驅動程序工作的服務線程,如圖2所示。
圖1 改進方案結構示意圖
圖2 客戶端軟件結構圖
過濾器鉤子驅動程序中設計主要是進行過濾鉤子函數的編寫。該客戶端軟件過濾器鉤子驅動程序的鉤子函數完成的工作主要是比較本機進出的數據包是否符合設定的轉發方向設置,如果符合則攔截,進行改寫后傳送,具體流程如圖3所示。
圖3 過濾器鉤子驅動程序流程圖
過濾器鉤子驅動程序工作在IP層,只能改寫IP包的內容,對于本機發送到其他機器的包,由于其MAC地址已經設定好,只改寫IP地址不能實現數據包的重定向。為解決該問題,驅動程序修改目標IP為本機IP,端口號為約定傳送端口后傳送數據包。由于基于原始套接字能實現自由收發TCP包的功能[10]。應用程序中的服務線程采用原始套接字方式與驅動程序配合進行二次處理:在約定的傳送端口進行監聽,獲取驅動程序發送的需要,重定向的IP包,根據設定的規則改寫對應IP地址及端口號,再通過原始套接字轉發至相應的流量均衡裝置,其流程圖如圖4所示。
命令監聽線程等待主控流量均衡裝置發送的命令,一旦接收到命令,則通過修改程序的配置來實現轉發方向的更改,具體流程如圖5所示。
圖4 應用程序服務線程流程圖
圖5 應用程序命令監聽線程流程圖
3 結 語
本文在前期的研究成果即基于流媒體流量均衡裝置的VOD方案基礎上,提出一種改進方法。在點播的用戶計算機上添加一個客戶端軟件,減少了流量均衡裝置間的信息交互,降低了流量均衡裝置的負載,并且該軟件直接對用戶發送的點播請求網絡包進行攔截和改寫,能與各種不同的VOD客戶端配合使用,具有較高的靈活性和適用性,從而拓展了該新型VOD方案的應用前景。
參考文獻
[1]楊震倫,蔣亞軍,黃中偉.基于MIPS的流媒體流量均衡設備的設計[J].計算機應用與軟件,2008(11):125-127.
[2]胡斌.基于Web流媒體系統的設計與實現[J].現代電子技術,2009,32(2):111-113.
[3]薛元昕,韓維.論流媒體技術及流媒體服務器的建立[J].現代電子技術,2004,27(16):28-31.
[4]王蘭英,居錦武.Windows內核模式驅動程序運行環境的分析[J].微計算機信息,2005(23):201-202.
[5]廖永紅,李洛,黃戰.基于Windows 200x的WDM體系的IP過濾實現技術[J].計算機工程與設計,2007,22(11):5 425-5 427.
[6]裴林,曹斌.基于NDIS中間層的網絡數據包攔截技術及實現[J].計算機安全,2008(12):13-15.
[7]李明欣,佘.基于NDIS中間驅動的入侵檢測[J].計算機工程與設計,2007(1):51-52.
[8]呂建軍,羅萬伯,陳蓉,等.基于過濾器鉤子驅動的數據包過濾研究與實現[J].四川大學學報:自然科學版,2005,41(4):754-757.
篇7
關鍵詞：小型局域網；多媒體中心；MIPS；Linux；Darwin streaming server
0 引言
在小型網絡中一般沒有專用的多媒體點播服務器，而相當多的網絡用戶都有音樂和視頻節目的視聽需要，每個用戶都保存一份音樂及視頻文件拷貝的方式，這不但浪費空間，也不利于節目的共享。應用系統若采用個人計算機PC實現小型多媒體服務，則在功耗，穩定性等各方面又存在問題。小型網絡多媒體中心(small-sized network multimedia center，簡稱SNMC)正是針對以上問題而設計的一種新型網絡設備。
SNMC一般獨立接入局域網運行，圖1是一種常見的應用結構。SNMC采用嵌入式架構，提供海量的多媒體節目存儲空間，提供擴展存儲空間的接口，提供MP3音樂和視頻節目的點播，提供Web管理界面。除了提供多媒體服務外，SNMC還可以同時作為NAS(網絡附加存儲)設備及打印服務器等。它在各種小型局域網，如小型企業，家庭，高校學生宿舍等場合具有廣闊的應用前景。
1 硬件設計
SNMC的硬件結構如圖2所示。其硬件設計基于MIPS架構的CPU－BCM1122。MIPS是業界領先的一種高效精簡指令集計算機(RISC)體系結構，具有低功耗，高性能的特點u’，目前在各種嵌入式應用尤其是網絡基礎設備及家庭娛樂應用等方面得到廣泛的應用。BroadCom公司的BCM1122是一款低功耗、高性能的通信處理器，基于MIPS64內核，主頻400MHz，處理能力達到880 Dhrystone MIPS，并且功耗低至4W；片上集成了一個G比特以太網控制器及一個快速以太網控制器，具有兼容PCI2.2標準，可配置為HOST模式的PCI總線接口，非常適合于SNMC的設計。
工作在園區網環境下，SNMC需要以太網接口，使用BCM1122片上集成的快速以太網控制器加外接物理層芯片即可實現網絡接口。同時SNMC需要廉價的大容量的存儲空間作為VOD節目緩存。而目前常規應用的海量存儲主流方向已經由IDE硬盤向SATA硬盤轉變，SATA硬盤具有容量大，速度快和價格低等優勢。BCM1122芯片上集成了PCI HOST控制器，直接擴展SATA控制器后可連接多個SATA硬盤。另外SNMC還提供了擴展存儲空間以及外接打印機的USB HOST接口，可采用外接USB控制器的方式實現。其硬件結構如圖2所示，其中MEM29PL64LM是8MB的FLASH存儲器，MT46V64M16是128MB的DDR SDRAM，CH375是USB控制器，RTL8201BL是網絡物理層芯片，SiI3512是SATA控制器。
2 軟件設計
2.1 軟件系統結構
SNMC是功能較為復雜的設備，需要操作系統支持。基于嵌入式Linux進行SNMC的軟件系統開發具有以下可行性及優點：①Linux開放源碼，具有很好的可裁減性及可配置性；②Linux具有強大的硬件驅動支持；③Linux的網絡功能強大。
開源社區已經實現了MIPS體系結構的Linux移植，可直接獲取源碼包并根據設計的硬件添加相應驅動程序并進行配置編譯即可。
Linux提供了多種服務軟件包，如ftp server，samba服務器等，這些服務軟件包都能為實現SNMC的功能提供支持。另外SNMC需要提供視音頻的點播服務器以及基于Web的管理界面。基于Linux實現SNMC軟件系統的方案如圖3所示。
2.2 視音頻點播服務模塊
目前視音頻點播服務系統主要包括三種：第一是Real公司的Helix Server，第二是微軟公司的Windows Media Server，第三種是Apple公司的Darwin Streaming Server，其中HelixServer和Darwin Streaming Server采用的是標準的RTSP協議，而Windows Media Server采用微軟內部的協議。目前基于標準RTSP的兩種方案由于采
用了開源策略，可擴展性和靈活性都較高，占據較大的市場份額。基于該原因，SNMC的視音頻點播服務模塊采用基于RTSP的方案。其具體實現可采用多種方式：自主研發周期長，穩定性難以保證，升級需要不斷投入；而現有的有蘋果公司的Darwin streaming server，具有開源，穩定性好的特點，并且apple公司有固定的研發團隊對之進行維護更新，在遵循APPLE公司的APSL協議的基礎上能自由地對Darwin streaming server進行修改，公布和。所以本方案直接采用蘋果公司的Darwin streaming server。獲取源碼包后采用面向MIPS處理器的GCC編譯工具編譯后即可使用。
2.3 Web管理模塊
視音頻點播服務模塊只實現了SNMC的基本功能，SNMC還需要提供用戶管理(包括分別對點播用戶，文件管理用戶的權限以及密碼進行管理等)，多媒體文件管理(包括對文件進行上傳／下載，歸類等操作)，系統管理(包括時間設置，網絡設置，磁盤管理等)等功能。在SNMC中采用Web來實現這些管理功能，其框圖如圖4所示。
SNMC中的Web管理模塊的實現主要基于CGI接口，采用PERL編寫的相應的腳本，運行在輕量級的Web服務器程序THTTPD上，具有消耗系統資源少，便于配置使用的特點。
篇8
【關鍵詞】 SIP 融合通信客戶端 軟件體系架構
一、引言
目前，現代電力企業員工日常辦公活動中，溝通交流越來越重要。而隨著技術的發展，利用先進的技術打破當前通信手段（如電話、短信、電子郵件和多媒體會議等）中以設備和網絡為中心的限制，實現只要通過最常使用的通信工具和應用，就可以便捷高效地與上級、同事、客戶及合作伙伴保持聯系，這是人們一直以來期望的目標，而移動性和統一通信的結合可以達成這個目標。本文將結合移動設備自有的特性，討論統一通信移動終端的融合技術。
二、融合通信移動終端設計架構
2.1 融合通信移動終端概述
融合通信通常是指把計算機技術與傳統通信技術融合一體的新通信模式，融合計算機網絡與傳統通信網絡在一個網絡平臺上，實現電話、傳真、數據傳輸、音視頻會議、呼叫中心、即時通信等眾多應用服務。隨著移動互聯的快速發展，特別是是近幾年iPhone、Android等智能手機的快速普及，越來越多的移動設備開始進入企業IT環境當中。
2.2 融合通信移動終端面臨的問題
融合通信移動終端設計的目標是要實現在任何地方、利用任何設備，與任何通信實體進行跨平臺、跨地域、跨設備的透明通信，且能夠保證網絡安全通暢，這使得客戶端設計面臨以下的主要問題：（1）統一通信平臺的多樣化，如市場上擁有成熟統一通信產品的就有思科、華為、中興、西門子、微軟、IBM等等，如何保證客戶端都能夠和這些廠商產品兼容；（2）終端系統種類和運行環境多樣化，如市面常見的就有iOS、Android和Windows Phone等；（3）移動網絡多樣性和復雜性，而企業出于安全性考慮，使得移動客戶端接入需要考慮的問題變得復雜化；（4）業務功能的可靠性。如語音、視頻等實時性業務對IP承載網的網絡質量要求很高，而移動設備的網絡一般都沒有達到這么高的帶寬，如何保證音頻/視頻業務質量。
2.3 融合通信移動終端總體架構
2.3.1 功能架構
結合融合通信的功能要求和所面臨的問題，我們設計的功能框架圖如圖1所示：
移動終端：融合通信平臺的用戶側最終呈現的應用。該客戶端安裝在企業工作人員或者顧客的手機上。
管道側：用來為平臺側與終端側傳輸數據。
服務端：平臺側依據SOA框架搭建，包括框架管理界面、邏輯處理層、接口層和數據層。平臺側為終端上的服務能力提供支持，其服務能力能夠利用接口進行添加和擴展。
2.3.2 設計體系架構
為了解決移動終端開發所面臨的問題，我們提出了基于中間件的開發模式，即把所有除實時音視頻業務外的所有其他業務統一封裝整合（如基于SOAP協議的Webservice），而對于實時性的音視頻業務，采用通用的SIP協議和RTP/RTSP協議結合的方式處理。結構圖如圖 2所示：
實現原理：（1）所有非實時音視頻業務全部通過中間件適配形成統一的WebService接口提供給客戶端；這樣可解決多種統一通信平臺接入、多種業務系統接入的問題；所有協議使用Https協議進行傳輸，內容通過3DES加密和GZIP壓縮，保證傳輸的安全性；（2）而所有實時音視頻業務則通過SIP會話進行控制，具體協商通過SDP實現，所有業務添加對Qos質量控制支持，確保業務功能的可靠性；（3）實時音視頻業務會話協商完成后，音視頻數據流通過RTP/SRTP協議直接與統一通信對應的音視頻服務器進行對接，確保通用性。
三、移動終端統一通信融合的關鍵技術
3.1 SIP協議
SIP由IETF RFC定義，用于多方多媒體通信。按照IETFRFC2543的定義，SIP是一個基于文本的應用層控制協議，獨立于底層傳輸協議TCP/UDP/SCTP，用于建立、修改和終止IP網上的雙方或多方多媒體會話。SIP協議借鑒了HTTP、SMTP等協議，支持、重定向及登記定位用戶等功能，支持用戶移動。通過與RTP/RTCP、SDP、RTSP等協議及DNS配合，SIP支持語音、視頻、數據、E-mail、狀態、IM、聊天、游戲等。SIP協議可在TCP或UDP之上傳送，由于SIP本身具有握手機制，可首選UDP。
3.2 視頻編解碼
因為視頻內容傳輸需要消耗大量的網絡帶寬資源，采用合適的視頻編碼技術也是系統的關鍵。根據已有的編碼標準來看，能夠適合碼流在1M到2M，同時又能保證高清的圖像質量，比較好的標準有MPEG-4、 H.264、VC-1和AVS幾種。H.264屬于下一代編碼技術標準，是所有壓縮技術里面壓縮率最高的，在支持實時標清電視節目時只需要1.5Mbit/s帶寬、點播電視只需要1.2Mbit/s帶寬，其畫質就可以達到DVD效果，這顯然有利于未來通信與娛樂、有線與無線的業務開展。因此，從技術的演進來看， H.264視頻編碼標準被認為是下一階段的必然選擇。因此，本系統優先實現編碼H.264。
3.3 業務質量控制
語音、視頻等實時性業務對IP承載網的網絡質量要求很高，為了保障語音、視頻業務QoS質量，在局域網中將語音、視頻業務與OA等信息數據業務采取不同的VLAN進行隔離，要求在交換機上作配置相應QoS策略，實現對語音、視頻等實時業務媒體流優先轉發。
四、結果展示
通過以上的技術研究，搭建起一臺中間件服務器，作為與即時消息服務器、UC服務器和信息系統服務器進行數據傳輸的中間平臺，使用這些服務器提供的開發開發接口開發所需要的功能。
同時，在蘋果iOS系統上開發完成了“融合通信移動客戶端”，主要功能包括以下功能：（1）移動應用門戶：融合門戶、OA等信息系統，形成統一的移動應用門戶；（2）SSO單點登錄：為所有移動化信息系統提供統一的認證功能；（3）通訊功能：個人通訊錄、企業通訊錄、群組、短信群發、智能搜索、快速定位、點擊撥號、一號通、語音會議等業務功能；（4）即時消息：融合騰訊通即時消息功能，可與騰訊通PC版進行互通。
篇9
關鍵詞： FMS； 流媒體； 流媒體傳輸協議； RTP； RTSP； RTMP； MMS； 寬帶網絡
中圖分類號：TP37 文獻標志碼：A 文章編號：1006-8228(2012)07-67-02
0 引言
互聯網在過去的數十年中發生了翻天覆地的變化。在互聯網普及的早期階段，我們不得不適應數據傳輸時延引起的“World Wide Waiting”，但是，互聯網的發展速度讓我們震驚——從最初的調制解調器帶給我們數十Kbps的數據傳輸速率，到ADSL 512K、1M、2M、4M、再到3G時代的悄然來臨，移動互聯網登上舞臺，也就用了10余年的時間。人們從最初在網上玩文字MUD游戲，看簡單的文字圖片信息，到后來上QQ聊天、開立空間、建設博客，玩大型的網絡游戲，再到后來在PC上或拿著iPad看電影……。互聯網的技術發展已為我們的生活帶來了層出不窮的新鮮體驗。
與此同時，我們教育工作者關注到，教育漸漸不依賴“固定時間”、“固定地點”的模式，而隨著互聯網的發展走到了校園外。學生們只要有臺PC，能夠連接到互聯網，就可以進行學習。這就是我們所看到的遠程教育，它的出現和普及，也在對現有的教育模式進行著一場革命。
遠程教育的技術平臺隨著網絡帶寬的升級，時時在經歷著更新變化。我們曾經花費很多時間和精力去研究基于窄帶網絡的視頻數據的傳輸效率，對視頻信息壓縮算法及格式的選擇、以及對采用什么瀏覽器端視頻播放器軟件的論證和實驗等繁復的工作之后，我們又欣然看到流媒體服務器軟件的出現，世界進入了視頻的流媒體時代。
1 早期的流媒體技術及方案
Microsoft和Real，作為在當時非常重要的流媒體軟件提供商，占據著早期流媒體技術市場的大多數份額。在這里我們有必要簡單回顧一下兩款曾非常流行的視頻流媒體服務器軟件。
⑴ WMS（Windows Media Service）
WMS是當時在Windows服務器平臺上構建流媒體服務的重要選擇之一。WMS為微軟的Windows媒體播放器（Windows Media Player）提供基于MMS（Microsoft Media Server）協議的流媒體視頻點播及直播服務。MMS是一種流媒體的傳輸協議，用來訪問并流式接收Windows Media服務器中以ASF文件的URL所標識的視頻源。觀眾可以在瀏覽器中直接輸入其URL，但協議必須為MMS，即以MMS://開始。
WMS的實施需要用戶在瀏覽器端安裝并激活Windows Media Player的插件。在服務器端，需要使用Microsoft Windows Server系列服務器操作系統，這在當時Windows服務器系統占優勢的情況下是很容易被大范圍應用的。但隨著Linux主導的網絡服務器操作系統快速搶占了大部分市場份額，以及Real Player伴隨著rm、rmvb等新的視頻格式出現并成為了多數用戶視頻回放的主要選擇，很多流媒體內容者寧愿選擇跨平臺的另一套解決方案：Real Server。
⑵ Real Server
Real Server的成功是借助了其流行的視頻壓縮格式-rm、rmvb流媒體服務端軟件，它以流暢的播放效果吸引了眾多用戶。Real Server使用RTSP（Real Time Streaming Protocol）協議進行視頻數據的傳輸。它是由哥倫比亞大學、網景公司和Real Networks公司所提交的，更易于擴展、更適配于HTTP協議、更安全的流媒體傳輸協議。Real Server曾經成為很多遠程教育機構、電視臺及獨立流媒體內容商的重要選擇。
但Real Server同樣存在對用戶端插件的依賴。在Windows Media Player，Real Player及Quick Time的多年搶占市場份額的混戰中，人們急需一種更統一、更簡單，更方便的互聯網視頻播放方式。這個時候，Flash依托其廣泛安裝的Flas播放插件，作為新的視頻播放軟件競爭者，浮出了水面。
2 新的流媒體服務器軟件-FMS
Adobe公司不惜重金收購了MacroMedia，將Flash技術收入囊中。這一頗具前瞻性的戰略舉動，奠定了Adobe公司作為新的視頻流媒體技術提供商堅實的市場地位。Flash Player憑借其壟斷性的裝機率，很容易就把一種新型的視頻播放方式帶到了用戶面前，那就是在Flash Player中集成了視頻播放功能。因為互聯網用戶幾乎人人都會安裝Flash Player插件，這使嵌于網頁中的視頻播放器在很短的時間被Flash所統一，占據了90％以上的份額。
Adobe將其視頻領域的產品線視作其互聯網戰略的重頭戲，適時推出了Adobe Flash Media Server，就是我們所說的FMS。FMS與用戶端瀏覽器中的Flash Player以RTMP協議進行通信，更高效地傳輸視頻流數據及控制指令，并以眾多優點成為流媒體者的首選。其推出的新的FLV視頻格式，也很快成為網絡視頻文件的重要格式選擇。下面，我們分析一下這些集合式的優勢如何被我們應用到遠程教育系統中。
3 FMS的優勢在遠程教育系統中的應用
我們可以看到，FMS流媒體技術框架有著諸多優勢，是非常適合應用在遠程教育系統中的。
篇10
>> 一種網絡視頻監控系統的設計與實現 撥號上網環境下的一種遠程視頻監控實現方法 一種基于ARM處理器的視頻監控系統關鍵技術的實現 一種輸電線路防外破視頻監控系統設計與實現 一種基于Docker的數據中心云平臺實現方法及系統 一種基于網絡的銀行視頻監控系統的研究與設計 一種移動視頻監控及定位系統的設計 一種移動多點遠程無線視頻監控系統的設計 一種適用于視頻監控系統的快速模式選擇算法 一種基于智能圖像識別的遠程視頻監控系統 一種改進的從交通監控視頻中提取關鍵幀的方法 一種基于網絡的家用視頻監控方案 一種基于數據中心的集中監控系統的設計 一種IP網絡的視頻會議系統的開發及實現 一種基于P2P的視頻共享系統的研究與實現 一種軟件實現的音視頻通信系統 一種數字視頻廣播通用接口轉換電路的實現方法 一種新型污水泵站遠程監控系統的設計與實現 一種基于SQLite內存數據庫的監控系統設計與實現 一種網絡流量監控系統的設計與實現 常見問題解答 當前所在位置：l.
[6] 黃金雪. Socket高效網絡服務端研究[J]. 現代計算機， 2011（10）： 22-25.
[7] Stephan Wenger. H.264/AVC over IP[J]. IEEE Transactions on Circu its and System for Video Techno-logy， 2003，7（13）： 64-65.
[8] 劉焱，鐘國輝，劉玉. 基于RTSP協議的流媒體雙向認證模型的研究[J]. 計算機應用與軟件， 2009，26（8）： 83-85.
[9] Li Huaming， Tan Jindong. Heartbeat-Driven Medium-Access Control for Body Sensor Networks[J]. IEEE Transactions on Information Technology in Biomedicine， 2010，14（1）： 44-51.