行政院國家科學委員會專題研究計畫 期中進度報告
子計畫三：網路軟體與 MPEG-4 串流技術之建構與開發(2/3)
計畫類別： 整合型計畫
計畫編號： NSC93-2220-E-006-003-
執行期間： 93 年 08 月 01 日至 94 年 07 月 31 日 執行單位： 國立成功大學工程科學系（所）
計畫主持人： 黃悅民
報告類型： 完整報告
處理方式： 本計畫可公開查詢
中 華 民 國 94 年 5 月 31 日
行政院國家科學委員會專題研究計畫期中報告
網路軟體與MPEG-4 串流技術之建構與開發(2/3)
計畫編號: NSC 93-2220-E-006-003
執行期限: 93 年 8 月 1 日至民國 94 年 7 月 31 日 主持人: 黃悅民 教授 國立成功大學 工程科學學系
一、 中文摘要
本計畫「網路軟體MPEG-4串流技術 之建構與開發」，以DM270為硬體開發 平台，修改網路上免費之串流伺服器軟 體- Fenice，並加入3GP檔案串流機制，
使得我們開發出來的產品可以提供品質 良好的影音串流服務於手機上，另外由 於我們所移植的網路協定可以單獨運作 於系統平台，因此具有相當的獨立性，
相當適合各種不同平台間的產品應用。
關鍵詞：影音串流、嵌入式系統
ABSTRACT
In this project, we studied the free software – Fenice, and added a mechanism for 3GP file streaming to allow our products can provide better A/V streaming services on mobile phone. In addition, the network protocol and A/V streaming system that we developed is independent of the system, so it is easy to portable to other platforms.
Keywords: A/V streaming , embedded system
二、 計畫原由與目的
近年來，隨著無線通訊技術的進步 與發展，手持式行動裝置的普及率逐年 增加，漸漸地超越了個人電腦，成為與 人們關係最密切的電子產品，在此人手 一機的情況下，若能將一般只能在個人 電腦上的服務與應用移植到手持式行動 裝置上，不僅可將服務的觸角推廣到更 多使用者身上，也可增加使用者的便利 性，隨時隨地都可使用，不再受到個人 電腦體積、重量的影響。
人類天生就對影像及聲音特別敏 感，目前行動服務中以文字為主的應用 已經不能滿足我們的原始需求，因此多 媒體發展可說是必然的趨勢，它可以廣 泛應用於娛樂效果、感官刺激、急難救 助、通訊聯絡等，無論在實用性及便利 性都是非常值得發展的一種技術。
由於網際網路技術進展迅速，使得 串流技術研究也變的非常熱門，多媒體 串流應用已經非常普及，但是硬體平台 仍然侷限於個人電腦的寬頻網路上，主 要是因為目前手機的無線網路環境頻寬 不足，連線品質不穩定所致，不過近年 來 Mpeg-4、H.263 壓縮技術的發展，讓 以往龐大的影像資料量可以縮減到適合 於無線網路的頻寬來使用，因此使用手 機來享受影音服務已不再是夢想。觀察 近年的趨勢，大部分針對串流系統所做 的研究，其用戶端平台主要是在個人電 腦上，較少對於手持式裝置的無線網路 環境做探討，因此本計劃針對多媒體串 流系統實際應用在行動網路環境的情況 作一探討。
基於上述的原因，本計劃的目標即 是要建立一套符合標準的多媒體串流伺 服器，除了支援傳統個人電腦之外還要 增加手持式行動裝置上用戶端的相容 性，讓使用者能以隨身攜帶的裝置，在 任何時間、任何地點都享受多媒體影音 服務帶來的樂趣。
三、 結果與討論
3.1 伺服器架構與運作方式
Fenice的架構主要分為兩部分：
RTSP Server與Data transmission
schedule，RTSP Server主要負責處理用 戶端與伺服器的連線相關動作，平時的 動作就是一直以TCP連接埠來聽(listen) 是否有用戶端要求建立新連線，並檢查 是否有RTSP訊息要回覆給目前已在線 上的用戶端，同時以多工方式接收線上 用戶端的RTSP訊息。Data transmission schedule則是循序對每個線上用戶端檢 查是否有要傳送的影音資料封包。
伺服器運作方式如圖一所示，
Fenice原有的兩部分為RTSP Buffer與 Schedule Array，其餘的Data transmission schedule下方check RTP session的流程是 我們所修改並加上去的功能。
RTSP Buffer是一個鏈結串列的結 構，每一個用戶端為一個節點，節點內 存放了此用戶端的RTSP Session、RTP Session、RTCP Session與串流所需用到 的一些變數與相關資訊等，而鏈結串列 的指標部分則指向下一個用戶端。
Schedule Array則是一個陣列的結構，陣 列的個數表示伺服器可以接受的用戶端 總個數。因為Schedule Array主要工作是 負責影音資料的傳輸，所以陣列裡儲存 一些RTP、RTCP Session的指標，指向用 戶端RTSP Buffer中的RTP與RTCP Session資料。
RTSP Server與Data transmission schedule是兩個平行處理的thread，各自 進行自己的工作，RTSP Server會不停的 listen新用戶端，並處理舊用戶端的RTSP 收送命令；Data transmission schedule則 是不停的對Schedule Array中每一個有 效(valid)的元素做資料傳輸檢查，若有 需要傳送影音資料給用戶端，則封裝 RTP封包與傳送的動作也是由Data transmission schedule來負責的。
3GP Parser
Audio / Video Capture 即時或隨選服務
封裝RTP封包 and傳送 RTSP Server
Data Transmission Schedule
是否要傳送 影音資料 YES
NO
On Demand Live
RTSP Buffer
RTSP Session 1
RTSP Session 2
RTSP Session N
END
‧
‧
‧
‧
‧
‧
Check RTP Session
Empty RTSP 1
Valid RTSP 2
Valid ‧‧‧‧ RTSP N Valid Empty‧‧
Schedule Array
check next RTP Session 將Array RTSP N
設為有效
圖一、伺服器運作流程
當伺服器收到新用戶端的連線，則 會去尋找目前用戶端鏈結中最後一個節 點，並建立一個新節點附掛到串列的結 尾上。當用戶端依照 RTSP 順序傳送到 SETUP 時，也就是要建立 RTP 與 RTCP 的傳輸連線，此時伺服器會尋找 Data transmission Schedule 中的 Schedule Array 是否有空元素，如果已經沒有空元 素，表示目前用戶端個數已達上限，無 法再服務，則必須回應 Server Error Code 給用戶端。若是還有空間，伺服器會將 找到的空元素內相關指標指向 RTSP Buffer 中的 RTP、RTCP Session，並把此 元素設為有效(valid)，以便之後 Data transmission schedule 對此用戶端的 RTP、RTCP Session 來做影音傳輸的檢 查。
RTSP Server與Data transmission
schedule之間的運作雖然是獨立的，但彼此 之間還是有資料結構上的關連性，Schedule Array操作的對象其實就是RTSP Buffer中的 RTP與RTCP Session。另外還需要注意的就 是RTSP Server在網路的功能上具備了傳送 與接收兩項工作，傳送的部分主要是RTSP
的command，而接收則是RTSP與RTCP兩者 都要接收。
3.2 3GP檔案Parser流程
經由傳輸機制判斷應該要傳送影音 資料給用戶端之後，Data transmission schedule 就要透過某些方法來找出正確 的影音資料來傳送給用戶端。在隨選服 務中是經由 3GP parser 來處理這項尋找 資料的工作。當用戶端要求播放某一個 檔案，parser 必須解析出檔案中所有的 影音 frame，並且把每一個 frame 包裝成 RTP 封包。因為在 3GP 檔案中，影音資 料已經透過轉檔程式依照 timestamp 循 序的擺放在 chunk 中，所以在隨選服務 裡面 A/V 同步的工作就不需要再額外去 考慮，只要按照檔案的 chunk 順序，一 一將 chunk 中的 sample 取出並傳送就可 以了。
當伺服器收到用戶端傳送的RTSP DESCRIBE時，會以parser解出檔案 header的部份，並取出「stbl」sample table atom中四項重要的資訊：
1. 「stco」chunk offset：
紀錄了此檔案中所有 chunk 的絕對 位置，用來比較 audio 與 video chunk，
找出目前應該要傳送的正確 chunk。
2. 「stsc」sample to chunk：
每個 chunk 中所包含的 sample 個 數，通常 video chunk 不一定會包含相同 的 sample 數，但是 audio chunk 則會包 含固定的 sample。
3. 「stsz」sample size：
每個 sample 的 size 大小，video sample 大小不固定，audio 大小則為固 定。
4. 「stts」time to sample：
每個sample的播放時間，video sample大小一樣是不固定的，audio則根 據AMR定義，每個frame的長度都是20 ms，所以audio sample的時間等於20 ms
乘以sample中的frame個數，例如有1個 sample包含5個frame，那麼此sample的 time為100 ms。
圖二、3GP parser抓取chunk流程圖
取出四個資訊之後，等待Data transmission schedule執行傳輸速率控制 機制來判斷是否要執行parser來取得封 包資料。由圖二中可以看到視訊與音訊 的傳送方式不太一樣。音訊的部份parser 會將整個chunk包裝成一個RTP封包，
RTP封包的payload size就會等於整個 chunk的大小，可由stsc × stsz得知 (sample個數 × sample size)。視訊的部份 則是要每個sample包裝成一個RTP封 包，所以如果當chunk裡包含多個sample 的時候，必須要連續的傳送多個RTP封 包，直到傳送完整個chunk為止。
當chunk傳送完之後，chunk offset 就要往下遞增一個，表示此chunk已經處 理過，下一次parser再做stco比較的時候 就會以新的chunk offset來做比較，找出 正確的chunk來傳送。RTP封包傳送完之 後，整個parser就會暫時結束，把控制權
還給Data transmission schedule，繼續對 下一個用戶端做檢查，等到全部的用戶 端都檢查過一次之後才會再回來對此用 戶端進行傳輸速率控制的檢查。
當所有chunk都傳送完畢，Data transmission schedule會把傳送完成的用 戶端Schedule Array設為無效，往後不會 再對此元素做檢查，意味著只剩下RTSP Server的部份服務該用戶端，處理最後的 TEARDOWN動作。
四、 計畫成果自評
目前本計畫完成了Linux與uClinux 兩種版本，而硬體則選用TI的
TMS320DM270為發展平台。
影音串流系統規劃為隨選(on demand)與即時(live)兩種功能，目前系 統只能提供3GP檔案的隨選服務，未來 還需要將即時服務也完成，其中包括：
1. DM270上之影像模組驅動
DM270上有許多影像硬體模組驅動 程式需要撰寫，此部份主要是將原始 影像擷取的動作完成。
2. 影音codec整合
整合ARM與DSP端之影音encoder之 間資料同步之流程，將DM270上影像 模組擷取到的原始資料傳送給DSP 壓縮，並配合ARM與DSP之間的溝 通機制，將壓縮完之資料回傳給 ARM來使用。
3. A/V同步機制設計等工作。
伺服器要加上即時影音同步的機 制，控管好ARM與DSP的擷取與壓 縮流程，並負責網路傳輸的工作。
參考文獻
[1] H. Schulzrinne, Columbia U., A. Rao, R. Lanphier, ” Real Time Streaming Protocol (RTSP)”, RFC2326, April 1998
[2] M. Handley, V. Jacobson, ”SDP:
Session Description Protocol”, RFC2327, April 1998
[3] H. Schulzrinne, S. Casner, R.
Frederick, V. Jacobson, ” RTP: A Transport Protocol for Real-Time Applications”, RFC1889, January 1996
[4] C. Zhu, ” RTP Payload Format for H.263 Video Streams”, RFC2190, September 1997
[5] C. Bormann, L. Cline, G. Deisher, T.
Gardos, C. Maciocco, D. Newell, J.
Ott, G. Sullivan, S. Wenger, C. Zhu, ” RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)”, RFC2429, October 1998 [6] J. Sjoberg, M. Westerlund, A.
Lakaniemi, Q. Xie, ” Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs”, RFC3267, June 2002
[7] ”Fenice – Open Media Streaming Server”,
http://streaming.polito.it/server/, 2004 [8] RealNetworks Inc., ” RTSP
Interoperability with Realsystem Server”,
http://docs.real.com/docs/rn/RealSyste m_iQ_RTSP.pdf, December 2000 [9] Apple Computer Inc., ”Apple – Open
Source – Darwin Streaming Server”, http://developer.apple.com/darwin/proj ects/streaming, 2004
[10] Apple Computer Inc., ”QuickTime
File Format”, http://developer.apple.com/documentat
ion/QuickTime/PDF/QTFileFormat.pd f, 2001
