面向并發(fā)服務的流媒體訪問控制技術研究

UDP層檢查其目的端口（如果其UDP套接口已連接，也可能檢查源端口），將數(shù)據(jù)報放到相應套接口的接收隊列。如果需要，就喚醒線程，由線程讀取這個新接收的數(shù)據(jù)報。

3.2 線程的調度控制

線程間通過互斥鎖，實現(xiàn)循環(huán)控制，即在線程處理視頻數(shù)據(jù)前通過互斥變量、信號燈加鎖，主要代碼如下：

sem_wait();

pthread_mutex_lock();

……

thread_next_flag=true;//設置下一個可執(zhí)行線程標志

pthread_mutex_unlock();

sem_post();

為了實現(xiàn)有效的服務，需要保證視頻數(shù)據(jù)流的傳輸具有相對的數(shù)據(jù)完整性。接收端常根據(jù)數(shù)據(jù)的到達情況通過RTP/RTCP協(xié)議的信息反饋，為服務器提供數(shù)據(jù)包接收情況的質量統(tǒng)計反饋信息和QoS檢測的資料；對于接收端而言，數(shù)據(jù)的存放需要占用一定數(shù)量的緩存，以承受網絡帶寬波動，并在傳輸中增加一定冗余信息來重建丟失或受損的數(shù)據(jù)，減少數(shù)據(jù)重傳。

按照上述策略，在Linux 9.0系統(tǒng)下編程實現(xiàn)了數(shù)據(jù)的傳輸，服務器的配置賽揚為2.0GHz,網卡為10/100M自適應。接收端為賽揚1.0GHz，網卡同樣為10/100M，通過交換機互聯(lián)。服務器預創(chuàng)建5個傳輸服務線程，圖中為兩個接收端的數(shù)據(jù)接收延遲情況，均傳送2000個數(shù)據(jù)包，從統(tǒng)計的結果圖來看，除了起始端出現(xiàn)較大的延遲外，延遲抖動均沒有過大的變化。但在沒有使用本文提出的調度控制的情況下，常常出現(xiàn)時延的急劇變化，即某一數(shù)據(jù)流出現(xiàn)了較大時延。

因此，本文的并發(fā)傳輸調度達到了使用要求，效果比較令人滿意。

圖1 多線程數(shù)據(jù)傳送調度控制測試結果

4 結論

由于視頻數(shù)據(jù)傳輸需要較大的數(shù)據(jù)吞吐量，容易出現(xiàn)網絡丟包和延遲較大的情況，以致造成接收端視頻抖動和明顯滯后。視頻數(shù)據(jù)傳輸時出現(xiàn)頻繁抖動，最終影響視頻的服務質量。

本文基于流媒體技術和并發(fā)調度方式，提出了視頻傳輸?shù)木C合方案，利用多線程技術實現(xiàn)多點視頻數(shù)據(jù)并發(fā)傳輸；利用調度控制技術實現(xiàn)以延遲抖動最小的服務。此外結合其它多路復用技術，分布式結構以及組播等方式可支持更多的連接,減少不必要的重疊發(fā)送，減輕系統(tǒng)和網絡的負擔，提高服務器CPU資源和網絡帶寬的利用率，對改善視頻數(shù)據(jù)傳輸?shù)膶崟r性、并發(fā)性，實現(xiàn)網絡視頻的多點實時傳輸、網絡多點實時監(jiān)控等方面具有特別重要的實際意義。

參 考 文 獻

[1] 胡道元.《計算機網絡（高級）》. 北京：清華大學出版社，1999.8 P107。

[2] 張斌 高波等編著《Linux網絡編程》北京：清華大學出版社，2000.1.1 P2-8。

[3] 鐘玉琢.向哲.沈洪《流媒體和視頻服務器》.清華大學出版社.2003.6.1

[4] RFC 1889,RTP: A Transport Protocol for Real-Time Applications, 1996.1

[5] http://www-900.cn.ibm.com/developerworks/cn/linux/sdk/rt/part7/indexeng.htm

[6] RunTime: Synchronizing processes and threads http://www-900.ibm.com/developerWorks/cn/linux/sdk/rt/part5/index_eng.shtml

[7] http://www.douzhe.com/linux/13code/13067.htm

更多計算機與外設信息請關注：21ic計算機與外設頻道