串流伺服器資料解析及封包包裝

全文

(1)國立交通大學電機學院通訊與網路科技產業研發碩士班碩士論文. 串流伺服器資料解析及封包包裝 Parsing and Packetization in Streaming Server. 研究生：陳瑩甄指導教授：張文鐘. 教授. 中華民國九十六年八月.

(2) 串流伺服器資料解析及封包包裝 Parsing and Packetization in Streaming Server. 研究生：陳瑩甄. Student：Ying-Jen Chen. 指導教授：張文鐘. Advisor：Wen-Thong Chang. 國立交通大學電機學院通訊與網路科技產業研發碩士班碩士論文. A Thesis Submitted to College of Electrical and Computer Engineering National Chiao Tung University in partial Fulfillment of the Requirements for the Degree of Master in. Industrial Technology R & D Master Program on Communication Engineering August 2007 Hsinchu, Taiwan, Republic of China. 中華民國九十六年八月.

(3) 串流伺服器資料解析及封包包裝. 學生：陳瑩甄. 指導教授：張文鐘博士. 國立交通大學電機學院產業研發碩士班. 摘. 要. 現今在即時多媒體應用上的主要課題在於即時(Real-time)的傳輸實況影音與已儲存的多媒體檔案，而多媒體串流技術可以讓使用者在下載多媒體檔案的同時可以先觀賞到已下載的部份，此項技術使得使用者不需要花費下載時間與硬體空間來儲存多媒體檔案。而一個多媒體串流伺服器包含了三個主要的模組，這三個模組各別為: 「標準連線程序建立」、「RTSP 信息溝通協調」與「封包包裝和傳送」。而在本論文中主要討論是「封包包裝和傳送」模組，此一模組是整個伺服器運作的重心所在，最主要在於實現檔案資料的解析與特定的封裝演算法，產生適合網路環境的封包並且傳輸。從 IETF 所制定的標準中可以知道 RTP 對不同影音檔案皆有其建議的封裝方式，本篇論文主要是針對這些封裝方式做探討，著重於影音檔案資料 parser 的運作機制，且提出一個架構在「封包包裝和傳送」模組內的 RTP 封包演算法，並藉由分析 Live555 此套 open source 的架構做為輔助及驗證 RTP 封包演算法是如何被實現的，在本論文中，所要探討的主要在於已儲存的多媒體影音檔案的部份，並以 MPEG 家族的影片格式做為實驗對象。. i.

(4) Parsing and Packetization in Streaming Server. student：Ying-Jen Chen. Advisors：Dr. Wen-Thong Chang. Industrial Technology R & D Master Program of Electrical and Computer Engineering College National Chiao Tung University. ABSTRACT. Today, the main points of real-time multimedia applications are the transmission and the play of live video or stored files. Streaming technology allows people to enjoy the multimedia contents while downloading them. With the advantages of this technology, users don’t need to spend extra time when downloading multimedia contents or spare extra memory space to save them. A streaming server will consists of three important modules, they are " Set up a standard connection procedure "," RTSP Signaling Negotiation " and " packet Packetization and Transmission " respectively. This discourse focuses on the module of "packet Packetization and Transmission " which is the key point to operate well in server, and to realize the analysis of file information and specific packetization algorithm which produces the packet adapting the internet environment. Because of standard define by IETF, we can know that different multimedia files have different RTP payload formats. The topics of this thesis mainly discuss the multimedia files’ parsing, Packetization, and transmission modules. Finally, we analysize the open source “Live555” to verify how the above three modules are implemented.. ii.

(5) 誌謝能夠順利完成此篇論文，最要感謝的人是我的指導教授張文鐘博士。老師在我二年的碩士生涯中，不管在學業或生活上都給予了相當多的幫助與指導，尤其在整理論文以及準備口試的期間中，難為老師如此辛苦與花費許多時間，不斷的為我指出研究中的盲點和問題的關鍵，使得此篇論文能更趨於完備。. 另外要感謝的，是實驗室裡的同學們，這兩年一起修課、在實驗室唸書寫報告趕論文的日子裡，感謝他們為我帶來了美好的回憶。另外，要特別感謝的是孟潔、素仙與小邱，在我研究上遭遇到問題時，經由與你們的討論才能逐一的解開我的困惑與滯礙，讓我能夠順利的往前前進。. 最後，我要感謝我的家人，父母親、姐姐們和其他好友們的支持與鼓勵，總讓我能心無旁騖地從事研究工作，並在我遇到挫折與低潮時讓我能夠重新振作。. 感謝所有幫助過我、陪伴我走過這一段時光的師長、同儕、朋友和家人。謝謝！. 誌於 2007.08 風城交大 Ying-jen. iii.

(6) 目錄中文摘要……………………………………………………………………………………… i 英文摘要…….…………………………………………………………… ………………….. ii 誌謝 ........................................................................................................... iii 目錄 ............................................................................................................iv 圖目錄 ........................................................................................................vi 表目錄 ..................................................................................................... viii 第一章緒論 ................................................................................................ 1 1.1 研究背景 .........................................................................................................1 1.2 研究動機........................................................................................................3 1.3 論文章節提要.................................................................................................5. 第二章多媒體串流系統相關背景知識概論............................................... 6 2.1 串流媒體與協定............................................................................................6 2.1.1 串流媒體文件格式說明 .....................................................................6 2.1.2 串流媒體通訊協定 .............................................................................7 2.1.3 即時傳輸協定（RTP: Real-Time Transport Protocol） ...8 2.1.3.1 RTP Packet format ...........................................................8 2.1.3.2 RTP Header Information..............................................9 2.1.4 實時流協議 (RTSP :Real Time Streaming Protocol).....11 2.1.5 SDP (Session description Protocol)...................................12 2.2 多媒體檔案編碼格式介紹 .........................................................................12 2.2.1 MPEG-2 System Introduction...............................................14 2.2.1.1MPEG-2 Program Stream ............................................15 2.2.1.2 MPEG-2 Transport Stream ........................................18 2.2.2 Mpeg-4 Introduction ...............................................................19 2.2.2.1 M4v Structure .................................................................20 2.2.2.2 M4V Syntax ......................................................................22 2.3 RTP Payload Format for MPEG-2 System and M4V ...............23 2.3.1 RTP Payload Format for MPEG-2 System .......................24 2.3.1.1 RTP Payload Format for MPEG-2 Video Stream ..............................................................................................................24 2.3.1.2 RTP Payload Format for MPEG-2 Audio Stream ..............................................................................................................28 2.3.2 RTP Payload Format for M4V ..............................................28. 第三章 RTP 封裝演算法的設計原理介紹............................................... 32 3.1 來源檔案建立與類型判斷..........................................................................33 3.2 位元解析與訊框產生 ..................................................................................34 iv.

(7) 3.2.1 M4V 檔案解析 ................................................................................35 3.4 封包傳送機制 ..............................................................................................49. 第四章多媒體串流系統與 RTP 封裝演算法 .......................................... 50 4.1 多媒體串流系統伺服端架構......................................................................50 4.2 Input / Output Buffer Architecture ...............................................53 4.2.1 Input Buffer Architecture-StreamParser ( ) ..................53 4.2.2 Output Buffer Architecture-OutPacketBuffer ( ).........54 4.3 Set up source file...................................................................................55 4.3.1 handleCmd_DESCRIBE ( ) ....................................................56 4.3.2 handleCmd_PLAY ( )...............................................................59 4.4 Build RTP packet...................................................................................59 4.4.1 continuePlay ( ) ..........................................................................60 4.4.2 buildAndSendPacket ( ) .........................................................60 4.5 Pack frame in RTP packet .................................................................62 4.5.1 packFrame ( ) ..............................................................................62 4.5.1.1 parse( )................................................................................63 4.5.2 afterGettingFrame1 ( ) ............................................................67 4.6 Send RTP packet ...................................................................................70 4.6.1 sendPacketIfNecessary ( ) .....................................................70 4.6.2 sendNext ( ) .................................................................................72 4.6.3 SingleStep ( )...............................................................................72. 第五章 Experimental Results ............................................................73 5.1 RTSP 信息溝通協調...................................................................................73 5.1.1 handleCmd_OPTION ( ) ..........................................................73 5.1.2 handleCmd_DESCRIBE ( ) ....................................................73 5.1.3 handleCmd_SETUP ( ).............................................................76 5.1.4 handleCmd_PLAY ( ) ...............................................................77 5.1.5 Packet header information....................................................77 5.2 封包包裝和傳送 ..........................................................................................78 5.2.1 Parsing Results ...........................................................................78 5.2.2 Packetizing Results...................................................................81 第六章結論........................................................................................................85 第七章參考文獻................................................................................................86 Appendix A. RTP Payload Type List Table .......................................87. v.

(8) 圖目錄 FIGURE 2.2[1] RTP HEADER FORMAT ......................................................... 9 FIGURE 2.3 MPEG-2 SYSTEM MODEL ........................................................ 15 FIGURE 2.5 RELATIONSHIP BETWEEN PES AND TRANSPORT STREAM..........19 FIGURE 2.6 MPEG4 VIDEO BITSTREAM LOGICAL STRUCTURE ...................... 21 FIGURE 2.7[8] (A) STRUCTURE OF M4V.................................................... 22 FIGURE 2.7 (B) STRUCTURE OF M4V......................................................... 22 FIGURE 2.8 MPEG-2 VIDEO STREAM EXAMPLE .........................................25 FIGURE 2.9 SLICE DISTRIBUTED IN FRAME SCHEMATIC DRAWING .............25 FIGURE 2.10 MPEG-2 VIDEO STREAM -SPECIFIC HEADER ........................ 26 FIGURE 2.11 MPEG-2 AUDIO STREAM -SPECIFIC HEADER......................... 28 FIGURE 2.12 MPEG-4 VIDEO STREAM-VIDEO PACKET .............................. 29 FIGURE 2.13[4] RTP PACKET EXAMPLE ...................................................... 31 FIGURE3.1『封包包裝和傳送』模組方塊圖............................................. 32 FIGURE3.2(B) 檔案格式判別說明圖-METHOD2 ...................................... 34 FIGURE3.3 MPEG-4 PARSE MODEL ........................................................... 36 FIGURE3.5 VISUAL OBJECT SEGMENT ........................................................ 40 FIGURE 3.7 VIDEO OBJECT PLANE SEGMENT ............................................. 44 FIGURE3.8 MPEG-2 PROGRAM STREAM PARSE MODEL ............................ 46 FIGURE4.1 RTSP SIGNALING NEGOTIATION-RTSP METHOD CHART ..........52 FIGURE4.2 PACKET PACKETIZATION AND TRANSMISSION CHART ................52 FIGURE4.3 INPUT/OUTPUT BUFFER-使用示意圖 .......................................55 FIGURE4.4 HANDLECMD_DESCRIBE ( ) FLOW CHART..............................57 FIGURE4.5 RTP HEADER 設定示意圖 ....................................................... 60 FIGURE4.6 PARSE ( ) MODEL ...................................................................... 64 FIGURE4.7 FRAGMENT FRAME ................................................................... 68 FIGURE4.8 SET UP NEXT PACKET ............................................................... 71 FIGURE5.1 OPTION - RESPONSE INFORMATION .........................................73 FIGURE5.2 CLIENT REQUEST- OPTION ......................................................74 FIGURE5.3 M4V CONFIGURATION INFORMATION 解析數據圖 ....................74 FIGURE5.4 (A) DESCRIBE - RESPONSE INFORMATION ...............................75 FIGURE5.4 (B) DESCRIBE - RESPONSE INFORMATION ...............................75 FIGURE5.4 (C) DESCRIBE - RESPONSE INFORMATION ...............................76 FIGURE5.5 CLIENT REQUEST- SETUP.........................................................76 FIGURE5.6 SETUP - RESPONSE INFORMATION ...........................................76 FIGURE5.7 CLIENT REQUEST- PLAY ...........................................................77 FIGURE5.8 PLAY - RESPONSE INFORMATION ..............................................77 vi.

(9) FIGURE5.9 RTP PACKET HEADER INFORMATION-MPEG-2........................77 FIGURE5.10 RTP PACKET HEADER INFORMATION-M4V ............................78 FIGURE5.11 SOURCE FILE ...........................................................................79 FIGURE5.12 OUTPUT BUFFER STATE .......................................................... 84. vii.

(10) 表目錄 TABLE2.1 串流媒體類型 ............................................................................ 13 TABLE2.2 MPEG-2 STANDARDS -ISO/IEC 13818 ......................................14 TABLE 2.3 [7] STREAM_ID ASSIGNMENTS ................................................... 17 TABLE 2.4 STREAM TYPE ASSIGNMENT (PROGRAM STREAM MAP) ..............18 TABLE 2.5[7] PID TABLE ............................................................................19 TABLE 2.6 [8] MPEG-4 START CODE ........................................................ 23 TABLE 2.7[12] PAYLOAD TYPE TABLE......................................................... 24 TABLE3.1 MPEG-4 位元流結構表.............................................................35 TABLE3.2[8] MEANING OF VISUAL_OBJECT_VERID AND VISUAL_OBJECT_PRIORITY ............................................................... 39 TABLE3.3[8] MEANING OF VISUAL OBJECT TYPE ........................................ 39 TABLE3.4[8] VISUAL OBJECT LAYER PARAMETERS .................................... 42 TABLE 3.5[8] MEANING OF VOP_CODING_TYPE......................................... 43 TABLE3.6 MTU LIMITED TABLE ..................................................................47 TABLE 4.1 FCURBANK 存取相關 FUNCTION ................................................54 TABLE4.2 FBUF 儲存函式...........................................................................55 TABLE4.3 RTSP METHOD ..........................................................................56 TABLE4.4 RTP HEADER 設定 ....................................................................61 TABLE4.5 FCURRENTPARSESTATE 與 PROCESS 對映表 ............................. 64 TABLE5.1 PARSING RESULTS .......................................................................79 TABLE 5.2 PACKETIZING STATE .................................................................. 82 TABLE A-1[12] PAYLOAD TYPE TABLE .........................................................87. viii.

(11) 第一章緒論 1.1 研究背景現今在即時多媒體應用上的主要課題在於即時(Real-time)的傳輸實況影音與已儲存的多媒體影音檔案，在本論文中，所要探討的主要在於已儲存的多媒體影音檔案的部份。在網際網路上，目前傳輸已儲存的多媒體影音檔案可分為兩種方式，一種為下載模式(download mode)，另一種為串流模式(streaming mode)；在下載模式中，使用者必需要將整個影音檔案完整的下載後才能夠完全播放此一影音檔案，雖然可以確保播放多媒體影音檔的輸出品質，但在網際網路上傳輸檔案所需花費的時間常常是相當冗長且讓使用者感到難以接受，尤其多媒體影音檔案容量通常都非常的大，且大多時候所下載的影片檔只是單純的用來觀賞及娛樂，並沒有保存的必要性，對於許多無法裝設大容量硬碟的裝置，像是行動電話、PDA…等，要將整個檔案下載完畢並不可能或是較為困難，且即使下載完畢也顯得浪費空間資源；同時在網路的頻寬限制下，也需要一個更好的方式來解決漫長的等待時間，因此發展出將多媒體影音檔切割成許多封包的格式，使用連續流動(Flow)的方式來傳輸，這就是串流模式。. 串流模式是一種具有即時(Real-time)特性的多媒體傳輸方式，其隨著通訊網路而蓬勃發展，它的發展目地在於如何透過通訊網路即時傳輸多媒體的音訊和視訊資料，而客戶端不需要花費大量的時間等待影音檔案下載完畢，只需要下載極小部份的資料便可以立即開始播放；其優點除了可以縮短客戶端下載所需要的時間外，更可以節省龐大的磁碟暫存空間，達到智慧財產權的保護等。 1.

(12) 現今的串流模式在通訊網路上有兩種主要的傳輸方式，第一種是以 HTTP/TCP 為基礎，使用 HTTP 協定可以讓串流媒體順利的通過防火牆的攔阻，而 TCP 是一種傳輸層協定（transport-layer protocol），主要是提供較高可靠性的資料傳輸，但缺點在於 TCP 通訊協定會導致傳輸速度的減慢，使得整個傳輸頻寬加大；第二種方式是使用 RTP/UDP， UDP（user datagram protocol）有別於 TCP，是一種不可靠協定，在傳輸上不能保證每個被丟出的封包一定會到達目的地，在接收的順序上也沒有按照傳送順序接收，而 RTP(Real Time Protocol)，是由 IETF 中的 AVT 這個 working group 所制定，並定義於 RFC-3550[1]；根據 RFC-3550，RTP 為即時資料傳輸提供點對點（end-to-end）網路發送服務，包含了 payload type identification、sequence number 和 timestamp，利用 sequence number 來進行封包的重建，而 timestamp 則帶有各影像、音訊封包所應該播放的時間資訊，如此便可以增加即時傳輸的品質。. 且在現今的商業市場裡，以串流模式傳輸多媒體影音的伺服端並沒有一個統一或是權威性的標準規格出現，也因此各家廠商所推行的伺服器大多都只能對應自己所開發的標準或是特定的通訊協定，形成百家爭鳴的狀況，也使得一套伺服器通常都只能對應某一套編碼/解碼格式；目前市場中較為主流的多媒體串流影音伺服器分別為 Microsoft 的 Media ServicesR、RealNetworks.com 的 RealSystemR 和蘋果電腦的 Quick Time ServerR。由於沒有一套統一性規格的多媒體串流伺服器及編解碼標準，且各家產品各有千秋，也因為商業上的激烈競爭要有所統合也較為困難，因此 Open Source 在整合出統一的多媒體串流伺服器上將扮演著舉足輕重的角色。. 2.

(13) 1.2 研究動機一個多媒體串流伺服器包含了三個主要的模組，這三個模組各別為: 「標準連線程序建立」、「RTSP 信息溝通協調」與「封包包裝和傳送」。「連線建立標準程序」模組主要使用 BSD Socket API 來完成一個伺服器的初始化設置，也就是依串流程式的需求來建立 TCP/UDP 模式的 socket。「RTSP 信息溝通協調」模組主要允許串流伺服器經由 RTSP 信令來完成與用戶端的連線溝通[2]。. 而「封包包裝和傳送」模組，是整個伺服器運作的重心所在，最主要在於實現特定的封裝演算法，產生適合網路環境的封包並且傳輸。在此模組中，伺服器必須要能夠分辨客戶端所要求串流傳輸的影音檔案格式，因為多媒體影音檔案格式類型眾多，像是 mpeg、m4v、avi…等，這些檔名皆是代表不同的包裝方式，表示其壓縮編碼的方法各有其獨特的地方，而在一個隨選即播的視訊系統裡，儲放在伺服器端的檔案會是各種包裝格式的其中一種，伺服器必須要有能力分辨出不同的格式，進而從檔案中抽取出視訊流與音訊流，並依據檔案格式的特性進行資料切割且包裝成特定型式的封包來進行傳送，而這樣的一個結構化的封包產生便是經由某一種特定的封裝演算法來獲得，也是「封包包裝和傳送」此一模組的功能所在。. 封裝演算法最主要的目的在於讓多媒體串流伺服器根據網路使用環境來選擇適當的封包包裝方式，藉以達到封包使用率以及封包錯誤恢復能力(error-resilience)之間的最佳化關係[2]。因此在有線、無線、不同傳輸速率或是使用不同通訊協定的網路環境下就各有適當的封裝演算法。而本篇論文中所要探討的是一個串流多媒體伺服器如何實現 RTP 3.

(14) 封裝演算法，如何解析檔案資料及將不同編碼格式的傳輸資料包裝成一個 RTP 封包可以負載的形式。. 一個 RTP 封包分成檔頭(header)和負載資料(payload)兩部份，RTP packet 的檔頭格式在 RFC3550 中有明確的定義，而負載資料的格式的切割方式會依據不同的多媒體資料而有不同的定義，像是在 RFC 2250 [3]就定義了 MPEG-2 的 RTP 封包包裝方式，而 MPEG-4 則定義在 RFC 3016[4]中。而在「封包包裝和傳送」模組中首先會遇到的問題在於伺服器端要如何辨認出它所要串流的影音檔案包裝格式為何?伺服器端是如何從這些影音檔案中抽取出視訊流和音訊流?又是如何對不同的影音檔案的資料進行切割成合適的 RTP payload ?唯有將這些問題解決，才能產生出一個個的 RTP 封包進行傳輸，而達到串流的目的。. 在 IETF 所制定的標準中可以知道 RTP 對不同影音檔案的包裝方式皆有其建議的封裝方式，本篇論文主要是針對這些封裝方式做探討，著重於影音檔案資料的解析分割也就是 parser 的運作機制，且提出一個架構在多媒體串流系統上的 RTP 封包演算法，並藉由分析 Live555 此套 open source 的架構做為輔助，用以驗證在真實的網路世界裡 RTP 封包演算法是如何被實現的，串流影音檔案格式則主要以 MPEG 家族的影片格式為實驗對象。在我們所討論的這個演算法中，所含蓋的範圍非常的廣泛，包括檔案格式的辨認、影像及聲音的資料處理、封包的組成與傳輸…等，這些每一部份都是很重要的環節，需要我們一一的去剖析並了解每個環節的因果關係，這樣才可以開發出可重覆使用的軟體模組，使其能夠擴充及包容更多不同檔案類型，達到整合的目地。. 4.

(15) 1.3 論文章節提要在深入探討一個實體多媒體串流伺服器的 RTP 封包演算法之前，我們必須要先了解網路上的即時傳輸基本概念以及多媒體影音檔的編碼格式，因此在第二章，會依序的介紹串流媒體（Streaming Media）與協定、即時傳輸協定（Real-Time Transport Protocol）、多媒體影音檔的編碼格式與 RTP 對不同多媒體檔案的包裝格式說明；而在第三章中將說明在一多媒體串流伺服器上的 RTP 封包演算法完整運作流程，包含檔案格式的辨認、RTP 封包的產生、檔案資料如何經由 parser 而分離出視訊流及音訊流…等，在此部份會描述如何包裝 MPEG-4 simple profile 及 MPEG-2 system 於 RTP payload 內作為例子。第四章主要是分析 Live555 伺服端的架構作為驗證；第五章為實驗結果；第六章則是為本篇論文作出結論。. 5.

(16) 第二章多媒體串流系統相關背景知識概論在本章節中將逐一的說明在多媒體串流系統中的「封包包裝及傳送」模組所使用到的各項背景知識，包括了串流媒體與通訊協定、多媒體檔案的編碼方式和 MPEG 家族的 RTP payload 包裝方式說明。. 2.1 串流媒體與協定 2.1.1 串流媒體文件格式說明一個多媒體串流系統可以透過網際網路存取遠端檔案，也可以從攝影機或是麥克風擷取獲得。一個串流檔案的文件格式包含了兩層涵意，一種是文件系統格式(container type)，即是定義如何將各種媒體組織在一起，可能是單獨的音訊和視訊，如 MP3、M4V，或者是結合了音訊與視訊，像是 AVI、MPEG、QuickTime…等；另一個就是媒體內容本身的編碼方式(codec type)，也就是文件中的各種媒體內容是通過什麼樣的方式來完成編碼的，比如常見的 MPEG1、MPEG2、MPEG4、AC3 等等。. 通常一個多媒體串流都是由多個通道（channel）組成，一個 channel 就是建構單獨的一層 track，每一 track 都代表著一種資料類型，例如： audio、video。而一個 mpeg 檔就是由音訊頻（audio track）和視訊頻（video track）組合而成。. 在多媒體串流系統運作上，伺服端須要知道客戶端要求傳輸的媒體檔的文件系統格式，才能依據不同的文件格式特性進行解析去分離出音訊頻和視訊頻，進而得到每一 track 的資料結構也就是編碼格式；伺服 6.

(17) 端會因應不同的編碼格式對媒體檔進行解析與包裝。 2.1.2 串流媒體通訊協定目前網路封包技術的標準有 TCP/UDP、RTP/RTCP…等，然而對於一個多媒體串流系統而言，若是使用 TCP(Transmission Control Protocol)傳輸封包，客戶端將會因為網路上的封包遺失，而時常面臨難以忍受的畫面延遲。這是因為 TCP 所提供的是一個較高可靠性的資料傳輸，TCP 會嘗試回復遺失的封包，而封包回復的作法就是要求來源端重新傳送一次封包。如果網路上的封包遺失嚴重，客戶端則會發出多次封包重送的要求。此時的客戶端必須在等待重送的封包抵達之後才能進行進一步的影音服務。等待的時間是漫長的，對於使用者而言這是讓人感到不悅的使用經驗。為了避免這樣的狀況，多數人選擇使用 UDP 傳送封包。. 有別於 TCP 的協定，UDP(User Datagram Protocol)在傳輸上不能保證每一個被送出的封包一定會到達目的地，在容易遺失封包的環境下 UDP 並不是個可靠的協定。UDP 不提供封包遺失偵測的功能，也不支援重送，但在網路擁塞的狀況下，多媒體串流系統使用 UDP 的機制能避免客戶端等待過久的時間。. 即時傳輸協定（RTP: Real-Time Transport Protocol）在 UDP 的上一層工作，它是項能彌補 UDP 不足之處的協定，且也利用了 UDP 的多工(multiplexing)及錯誤位元檢測(checksum service)兩項功能。事實上，多媒體串流系統傳輸多媒體內容封包之前，須先做適當的切割，並包裝成為 RTP 封包，接著利用 UDP 與 IP（Internet Protocol）傳輸協定依序傳送到網路上，而 RTP 的資訊即是被封裝在 UDP 的封包裡， RTP 為即時資料傳輸提供端點對端點（end-to-end）網路發送服務，也 7.

(18) 提供了下列功能：content type identification, sequence numbering, timestamping…等。下個小節中將會詳述。. 2.1.3 即時傳輸協定（RTP: Real-Time Transport Protocol） RTP[1]是為了處理具有即時特性的資料，而制訂一個屬於應用層的端對端(End-to-End)傳輸通訊協定。它主要的目的在於支援即時性的影音資料傳輸，將媒體檔案切割成數份的封包，搭配 RTP header，再交給較底層的傳輸協定如 UDP 傳送。而一個 RTP header 中包括承載格式（Payload Type）、序號（Sequence Number）和時間戳記（Timestamp）等欄位，序號和時間戳記可以讓接收端重新排列出封包的正確順序，以及資料應該被播放的正確時間點，例如：當多個封包中的時間戳記相同時，接收端就可以利用序號來偵測是否有封包遺失。. RTP 此一協定並不具有確認傳送的時間與保證傳送服務的品質（QoS）的機制，這些功能只能依賴著較低層級的網路服務來提供。RTP 不會去防止封包不按照順序傳送，也不會保證封包一定會送達；其封包裡所包含的序號，會幫助接收端依照發出的順序重建資料，決定封包適當的位置。. 2.1.3.1 RTP Packet format. Figure 2.1 RTP Packet Format 如同 figure2.1 所表示，RTP 封包是由 Header 和 Payload 兩部份所組成，RTP 封包的 Header 格式在 RFC 3550 中有明確的定義，在 8.

(19) 2.1.3.2 節中會有詳細的說明。Payload 可為視訊或是音訊的資料，而不同格式的檔案資料要如何置入 payload 部份中才能使用 RTP 傳輸影音資料則另有規範，比如 RFC 2250 中規範了 MPEG 1/2 payload，而 MPEG-4 AV payload 則定義在 RFC3016 中，此部份在之後的章節將會有更進一步的說明。. 2.1.3.2 RTP Header Information. Figure 2.2[1] RTP Header Format. 如 figure2.2 所表示，RTP header 欄位的前 12 個位元組是每一個 RTP 封包都具備的，而 CSRC 辨別碼欄位是否存在則端看封包是否有經過混合器而定。下面將依序介紹每個欄位的代表的意義： Version (V)：2 bits 指出代表 RTP 協定的版本。目前所使用的版本為 2。 padding (P)：1 bit 表示封包的尾端是否有 padding。Padding 的原因通常是為了加密，或者是為了交由較底層的協定進行傳輸。Padding 最後一個位元組代表 padding data 有多少個位元組，padding data 並不屬於承載資料的其中一部份，可用於各種加密演算法。 extension (X)：1 bit 9.

(20) 表示是否進行 RTP header extension，當此 bit 設定為 1 時，表示在 RTP header 後面還會在跟隨額外的 header。 CSRC count(CC): 4 bits 由於多媒體串流技術支援多個來源，換句話說一個 RTP 封包可能會由兩個以上的來源經由 Mixer 組合而成，CSRC(Contributing Source identifier)代表參與此次串流通訊來源的 ID，而 CC 則是表示此 RTP 封包是包含了多少個 CSRC。 Marker (M)：1 bit 這個 bit 是由規格文件（profile）所定義，用來標示重要事件的旗標，例如在此封包中的 payload data 有無 frame 的邊界。 Payload type (PT)：7 bits 這個位元組是用來辨認 RTP 承載的內容型態，相關定義會在 2.3 節中說明。 Sequence number：16 bits 每送出一個 RTP 封包，就會在序號欄位上加一，序號的起始值是在 0~65535 中亂數決定的；在串流一開始時亂數決定 sequence number 是為了避免加密的明文攻擊（known-plaintext attack）。藉由此一數字，可以幫助接收端偵測出所收到的封包是否有遺失，以及將順序錯誤的封包進行重新排列。 Timestamp：32 bits Timestamp 是表示 RTP 資料封包的第一個位元組取樣的瞬間。而這個瞬間則是由時鐘線性的時間變化量所取得，可以用來同步化並計算抖動時間偏移（jitter）的情形。時鐘的頻率是依承載所攜帶的資料格式而不同，也可能會在規格文件或是定義承載格式的規格中規定，以 MPEG-4 來說，其頻率為 90kHz。在傳輸即時擷取的影音資料時，timestamp 所反應的是 payload 10.

(21) data 第一個 byte 的取樣時間；當所要傳送的資料是已經儲存好的影音檔案時，則這個值所表示的為 payload data 的播放時間點，當連續好幾個 RTP 封包的 payload data 是屬於同一張影像時，則 timestamp 的值都會相同，且其初始值和 sequence number 相同都是經由亂數產生。 SSRC：32 bits Synchronization Source (SSRC)是用來辨識 RTP 資料來源。不同的資料流會有個別的 SSRC 值，這個辨別碼在任何一個 RTP session 中都是隨機亂數產生，且是獨一無二的。 CSRC list :0 到 15 個項目，每項需要 32 bits CSRC list，當來源資料流被合併時，存放合併過的資料流的 SSRC 值，因此這個欄位並不一定存在。辨別碼的數目是由 CC 欄位提供，由於 CC 只允許 4 個位元，故存放數目由 0~15 個 SSRC，如果有超過 15 個傳送端的話，也只能記錄 15 個。. 2.1.4 實時流協議 (RTSP :Real Time Streaming Protocol) RTSP(Real Time Streaming Protocol)[5]是由 RealNetworks 和 Netscape 共同提出的，此一協議定義了一對多應用程序如何有效地通過 IP 網絡傳送多媒體數據。RTSP 在整個傳輸體系結構上位於 RTP 和 RTCP 之上，它使用 TCP 或 RTP 完成數據傳輸。RTSP 支援客戶端和伺服端間雙向溝通，兩端都可以發出請求，使用者可以透過 RTSP 下指令給伺服器，像是“PLAY”、“PAUSE”等動作。. RTSP 可以稱為一個對多媒體服務做遠端控制的通訊協定，RTSP 在語法上與 HTTP 非常相近，都是屬於純文字的通訊協定，其請求的訊息格式為被請求者的 URL 位址以及協定版本，接著是 header 及訊息本文。訊息本文可能包含一“會議描述(session description)＂─ 描 11.

(22) 述該會議中串流媒體的訊息，此一會議描述的格式並未限定，但目前大部分皆以 SDP[6]為其訊息格式。運用 RTSP 協定中所定義的各種方法 (method)，可以達成對串流媒體的各種控制，RTSP 協定中的 method 會在第四章中說明。. 2.1.5 SDP (Session description Protocol) SDP [6]是一種以文字格式描述多媒體會議(session)的通訊協定，嚴格說 SDP 並不算是一種通訊協定，而在內涵上比較傾向於類似 HTML 的標記語言。SDP 可以被包含在 SIP、RTSP、SAP、HTTP 甚至 E-Mail 等各種協定中；SDP 可以包含各種有關於 session 的描述，像是媒體種類(Video/audio/shared application 等)、媒體傳輸協定 (RTP/UDP/IP 等)、媒體格式(H.261 video/MPEG video/G.723.1 audio 等)、還有一些有關安全方面的訊息(如該媒體會議的加密值)等資訊。整個 SDP 的內容可以歸納成三部份: 第一部份包含了 session 名稱和目的以及該會議活動的時間。第二部份則是組成該會議的媒體種類與接收這些媒體的控制信息。第三部份與控制信息相關。. 2.2 多媒體檔案編碼格式介紹現今在網際網路上常見的串流媒體編碼格式包括了有需要較高頻寬的 MPEG-1、MPEG-2 外，另外還有 Real Video、QuickTime、WMV、 MPEG4 及 H.264…等格式，如 table2.1 所示。. 在此小節中將介紹由 ISO 13818-1[7]所定義的 MPEG-2 system 包括了現今 DVD 所使用的 mpeg-2 program stream 以及用於數位廣播電 12.

(23) 視上的 transport stream；除此之外也會說明規範於 ISO 14496-2[8]中的 mpeg-4 simple profile。. Table2.1 串流媒體類型編碼格式 (Codec Type). MPEG 動態壓縮標準. Quick Time. ASF. WMV. 副檔名 (Content Type). 說明. .mpg (.mp3). 包含了 MPEG-1 和 MPEG-2。 MPEG-1 是最早定義出的影音格式，最熟知的有 MP3、Vedio CD；MPEG-2 並不是用來取代 MPEG-1 的格式，二種規格自有其不同的應用層面，最常見的的應用為數位電視、DVD Video 與 SVCD。. .m4v. MPEG-4 是目前最新的壓縮格式標準，主要針對低速頻寬的影音視訊編碼的目的，讓影音檔案更小，但品質幾乎與 DVD 無異，在網路上的傳輸更便利。. .mp4. 為音樂檔案的一種，依循著 MPEG 所制訂的 MPEG-4 影音格式編碼，以 Advanced Audio Coding（AAC）Codec 編碼技術更有效地將 CD 音樂轉檔壓縮而成的數位音樂格式檔案。. .mov. 由 Apple 公司開發出來的檔案結構格式，QuickTime 沒有定義其視訊檔案實際的壓縮技術，而只是定義了視訊的架構。. .asf. Advanced Streaming Formate 的簡稱，是微軟針對串流影音應用所提出的影音新規格。ASF 檔案可以是任何的編碼方式為基礎的影音編碼，而且仍然是 ASF 格式。然因為 ASF 檔案主要是為了提供在網路上直接觀看，所以品質較 VCD 來的差。. .wmv. 由微軟公司主導所發展出來的多媒體視訊格式，也是微軟所有視訊編碼方式的通稱，該檔案的特點是檔案小，有利於網路上的即時傳送播放，是一種網路上常見的視訊格式。 13.

(24) 續 Table2.1 編碼格式 (Codec Type). RM. 副檔名 (Content Type). 說明. .rm .rmvb. Real Networks 公司所制訂的檔案格式，是一種可以應用在網路上的多媒體串流檔案格式，也是最早在網路上流行的多媒體格式檔案。優點包括了：壓縮率高、檔案小的特性。包括了三種主要檔案類型：（1）Real Audio：主要用來傳輸接近 CD 音質的音頻資料；（2）Real Video：主要用來傳輸連續的視訊資料；（3）Real Flash：高壓縮比的動畫格式。. 2.2.1 MPEG-2 System Introduction MPEG-2 Standards 是由 Moving Picture Expert Group(MPEG)所制定，並由 International Standards Organization (ISO)所出版。目前共分成九個部份列於 table2.2；在 ISO 13818-1[7]中定訂了兩種 Multiplexing 模式: Program stream 與 Transport stream，如 figure2.3 所示。Multiplexing 是指將壓縮過後的視訊流、音訊流、使用者資訊與控制資料…等結合成一數據流，讓此數據流可以適用於傳輸或是儲存。 Table2.2 MPEG-2 Standards -ISO/IEC 13818 編號 1 2 3 4 5 6 7 9 10. 文件內容 System Video Audio Conformance testing Software simulation Extensions for DSM-CC Advanced Audio Coding (AAC) Extension for real time interface for systems decoders Conformance extensions for Digital Storage Media Command and Control (DSM-CC). 14.

(25) Figure 2.3 MPEG-2 System Model. 2.2.1.1MPEG-2 Program Stream 由 figure2.4 可以得知，一個完整的 Program Stream (PS)是由多個 pack 所組成的。一個完整的 pack packet 會包有 system header 與多個 elementary stream，但 system header 不一定會存在。而一個 elementary stream 在加上一個適當的 header 後形成 PES (Packetized Elementary Stream)。. Figure 2.4 Relationship between PES packets and Program 15.

(26) 每一個 PS 中的所有 PES 都具有共同的時間基準(time base)，且只能包含一個節目，通常是由一個視訊流搭配兩個音訊流所構成；由於這些 PES 享有共同的時間基準，也才能夠同步地對視訊流和音訊流進行解碼動作。PS 封包的大小並不固定，也因為不同長度的特性，使得 PS 並不適合用於需要錯誤校正的系統，另外也由於其低通訊負載的特性，在一些如 CD-ROM 等無錯誤或近似無錯誤的環境中是相當適合的。依據 ISO13818-1[7]中所定義，PES 組合成一個 PS 前必須要在加上 Pack header 和 System header，每一個 header 都是由一列固定的起始碼開始，起始碼是一串特殊的編碼值，其可以區分出資料流的每層架構，而 PS 可視為總共分成三個階層，最外層為 Pack header 是由 pack_start_code:0x000001BA 開始，而第二層 System header 則是由 system_header_start_code:0x000001BB 開始，且在 System header 中的 stream_id 欄位會定義此一 PS 的視訊流和音訊流的類型。最裡層的 PES header 開始於 packet_start_code_prefix:0x00000001，接在 PES 起始碼後的欄位為 stream_id 和 PES_packet_length，如 figure2.4 中的(d)所示；其中 stream_id 所裝載的為此 PES 的 payload 類型資訊，從 table2.3[7]中可以知道，當 stream_id 的值在 0xC0~0xDF 間 payload 為 audio stream，如果位於 0xE0~0xEF 間的話 payload 則是 video stream。. PES header 中的 stream_id 欄位除了告訴解碼器其 payload data 的資料流為視訊或是音訊外，它還必須要告訴解碼器此資料流的編碼格式，舉例來說:當 PES header 中的 stream_id=0xE0 時，表示此一 PES 所攜帶的 payload data 為視訊流，編碼方式為 MPEG1 或是 MPEG2；如果 PES header 的 stream_id=0xBC，表示這個 PES 為 program 16.

(27) stream map，它所挾帶 stream_type 和 elementary_stream_id 這兩個欄位的訊息可以告知解碼器這一個 PS 中的 PES 彼此之間的關係，假設 program_stream_map 的 elementary_stream_id=0xE0，stream_type 為 16，依據 Table2.4[7]可以知道 stream_type 為 16 為保留型別，定義為 mpeg-4 video codec，因此只要是 PES header 中的 stream_id 為 0xE0 的話，代表此視訊流編碼格式為 mpeg-4。. Table 2.3 [7] Stream_id assignments Stream_id 1011 1100 1011 1101 1011 1110 1011 1111 110x xxxx. 1110 xxxx 1111 0000 1111 0001 1111 0010. Stream coding Program_stream_map Private_stream_1 Paddinf_stream Private_stream_2 ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream ITU-T Rec.H.262│ISO/IEC 13818-2 or ISO/IEC. 11172-3 video stream ECM_stream EMM_stream ITU-T Rec.H.222.0│ISO/IEC 13818-1 Annex A or ISO/IEC 13818-6 DSMCC stream ISO/IEC_13522_stream ITU-T Rec.H.222│type A ITU-T Rec.H.222│type B ITU-T Rec.H.222│type C ITU-T Rec.H.222│type D ITU-T Rec.H.222│type E. 1111 0011 1111 0100 1111 0101 1111 0110 1111 0111 1111 1000 1111 1001 Ancillary_stream 1111(1010-1110) reserved data stream 1111 1111 program_stream_directory. 17.

(28) Table 2.4 Stream type assignment (program stream map) Stream_id Description ITU-T│ISO/IEC Reserved 0x00 0x01 ISO/IEC 11172 video ITU-T Rec.H.262│ISO/IEC 13818-2 or ISO/IEC 0x02 11172-2 constrained parameter video stream 0x03 ISO/IEC 11172 audio 0x04 ISO/IEC 13818-3 audio ITU-T Rec.H.222.0│ISO/IEC 13818-1private_sections 0x05 ITU-T Rec.H.222.0│ISO/IEC 13818-1PES packets 0x06 containing private data 0x07 ISO/IEC 13522 MHEG ITU-T Rec.H.222.0│ISO/IEC 13818-1 Annex A DSM 0x08 CC 0x09 ITU-T Rec.H.222.1 0x0A ISO/IEC 13818-6 type A 0x0B ISO/IEC 13818-6 type B 0x0C ISO/IEC 13818-6 type C 0x0D ISO/IEC 13818-6 type D 0x0E ISO/IEC 13818-1 auxiliary 0x0F-0x7F ITU-T Rec.H.222.0│ISO/IEC 13818-1 Reserved 0x80-0xFF User Private. 2.2.1.2 MPEG-2 Transport Stream Transport Stream 簡稱 TS，其主要是使用於數位廣播電視上，也就是 HDTV 的傳輸格式；TS 由一道或多道節目(program)組成,每道節目由一個或多個原始流和一些其他流複合在一起，包括視頻流、音頻流、節目特殊信息流（PSI）和其他數據包。不同的節目可以擁有不同的時間基準(time base)，且 TS 封包具有固定的長度，可以容易的讓解碼器得知一張照片的開始與結束，也比較容易在封包遺失後進行補救。. 參考 figure2.5 可以得知， TS 和 PS 不同，TS 是由長度固定為 184 18.

(29) bytes 的 PES 再加上 4 bytes 的 TS header 所組成，共 188 bytes。TS header 包含了 8 bits 的 sync_byte (0x47) 和 13 bits 數據包識別號 PID…等。PID 欄位的訊息可以告知解碼器 TS packet 的 payload 類型，可以參考 table2.5[7]，從 PID 可以判斷其後面負載的數據類型是視頻流、音頻流、PSI 還是其他數據包。. Figure 2.5 Relationship between PES and Transport Stream. Table 2.5[7] PID Table Value 0x0000 0x0001 0x0002-000F. Description Program Association Table Conditional Access Table Reserved May be assigned as network_PID, 0x0010-0x1FFE Program_map_PID,elementary_PID, or for other purpose 0x1FFF Null packet. 2.2.2 Mpeg-4 Introduction MPEG-4 是 MPEG-1 和 MPEG-2 這兩種視訊標準的後繼者，是目 19.

(30) 前市場上資訊產品應用裡，最為熱門的技術之一。在網際網路的應用領域裡，MPEG-4 影音串流傳輸的技術研發是一個企業激烈競爭的戰場。目前有非常多的企業組織加入開發 MPEG-4 影音串流的多媒體應用，不過每家公司都採用自訂的 Codec 或特有的檔案格式及系統架構，因此對於 MPEG-4 多媒體呈現的支援度有異，例如大部份都沒有支援互動式場景呈現的能力，而且支援的影音編碼亦不相同。在此小節中將描述一個 mpeg-4 simple profile 的 elementary stream 也就是 M4V，其 header 包含那些重要的資訊。. 2.2.2.1 M4v Structure 傳統的視訊壓縮技術是以一張畫面作為壓縮單位，而 MPEG-4 則將畫面再切割成更小的單位作為壓縮單位，稱為物件(Object)，因此本來是一張張的畫面視訊序列(video sequence)會被劃分為數個以物件為主的視訊物件序列(Visual Object Sequence)。. MPEG-4 視覺場景 (visual scene) 可能包含一個或多個視訊物件，每個視訊物件都可藉由時間和空間資訊加以描述，包括它們的形狀、移動和紋理。而 MPEG-4 video stream 會提供階層式的視覺場景描述，起始碼 (start codes) 則是特殊的編碼值，它們可以存取位元串流的每一層階層架構。參考 figure2.6，MPEG-4 階層架構中的各層包括：視覺物件序列 (Visual Object Sequence，簡稱 VS) 它是完整的 MPEG-4 場景，可能包含任何 2-D 或是 3-D 的自然或合成物件以及它們的加強層 (enhancement layer)。視訊物件 (Video Object，簡稱 VO) 視訊物件會連結至場景中的某個 2D 元素，矩形圖框就是最簡單 20.

(31) 的例子；它也能是任意形狀的物件，對應於場景中的某個物件或是背景。視訊物件層 (Video Object Layer，簡稱 VOL) 視訊物件支援可延展 (scalable) 以及不可延展 (non-scalable) 兩種編碼模式，實際編碼模式則由視訊物件層所代表的應用決定。視訊物件層能支援可延展性編碼。視訊物件平面群 (Group of Video Object Planes，簡稱 GOV) 視訊物件平面群是可選用的功能，它會提供視訊物件平面被獨立編碼的各點，讓位元串流中能夠加入多個隨機存取點。視訊物件平面 (Video Object Planes，簡稱 VOP) 視訊物件平面是在時間取樣的視訊物件，它們可以獨立取樣，也可以利用移動補償值進行取樣。矩形可以代表傳統的視訊圖框。視訊物件平面的使用方法有很多種，最常見的做法是讓它們包含某個視訊物件的時間取樣值的編碼視訊資料。每個視訊物件平面都包含多個巨集區塊 (macroblock)，每個巨集區塊則會包含四個 8x8 亮度區塊 (luminance block) 以及兩個 8x8 色度區塊 (chrominance block)。. Figure 2.6 MPEG4 video bitstream logical structure 21.

(32) 2.2.2.2 M4V Syntax 參考 Figure 2.7[8] (A)，一個完整的 M4V 是由 Visual Object Sequence Header、Visual Object Header、Video Object Layer Header 以及 Elementary Stream Visual Object 所組成;前面三個 header 會攜帶解碼器所需的一些資訊，像是照片的尺寸、量化矩陣的參數…等的資料，這些資料稱為 Elementary Stream Descriptors(ESDS data)，而每個 header 都有其固定的起始碼的位元值，可以參考 table 2.6[8]；當 ESDS data 結束後會進入 Video Object Plane，也就是每張 frame 的起始位置，藉由 Video Object Plane 的 header 可以判別此張 frame 類型為 I、P 中的那一項，而 Video Object Plane 的 start code 即為此張 frame 的起始位置。在 figure 2.7(B)明白表示出一個完整的 M4V 檔案是由 ESDS data 和 I frame 與 P frame 所組成。詳細的 header 解說可以參考 3.2.1 小節。. Figure 2.7[8] (A) Structure Of M4V. Figure 2.7 (B) Structure Of M4V. 22.

(33) Table 2.6 [8] MPEG-4 Start Code Name Video_object_start_code Video_object_layer_start_code Reserved Visual_object_sequence_start_code Visual_object_sequence_end_code User_data_start_code Group_of_vop_start_code Video_session_error_code Visual_object_start_code Vop_start_code ……. Start code value (hexadecimal) 00 through 1F 20 through 2F 30 through AF B0 B1 B2 B3 B4 B5 B6 ……. 2.3 RTP Payload Format for MPEG-2 System and M4V 從 2.1.3 節中可以知道 RTP 封包是由 RTP header 與 payload 所組成。RTP header 中的 Payload type(PT)的欄位中裝載了此一 RTP 封包所負荷的資料型態的資訊，也就是 payload 的類型資訊；PT 欄位訊息由 7 bits 來表示，表示資料的編碼格式有 128 種的可能性，而 payload data 可能為 128 種中的其中一種的型態，相關定義在 RFC 1890 中，而每一種編碼類型都有其不同的 RTP 包裝方式，這些資訊被定義在各個 RFC 的文件中，table 2.7 列出較常見編碼類型其 PT 值以及其相對應的 RFC 文件，詳細的資料請參見附錄 A。而在本節中將說明 MPEG-2 與 M4V 的 RTP payload 包裝方式。. 23.

(34) Table 2.7[12] Payload Type Table PT. Name. Type. 7 8. LPC PCMA. Audio Audio. Clock rate (Hz) 8000 8000. 14. MPA. Audio. 90000. 26 31 32. JPEG H261 MPV. 90000 90000 90000. 33. MP2T. 90000. RFC 2250. 34 72~76 96~127 dynamic dynamic. H263 reserved dynamic H263-1998 BMPEG. Video Video Video Audio/ Video Video. RFC 3551 RFC 3551 RFC 2250, RFC 3551 RFC 2435 RFC 2032 RFC 2250. Audio References channels 1 1. 90000 RFC 3550 RFC 3551. Video Video. 90000 90000. 2.3.1 RTP Payload Format for MPEG-2 System 在 RFC 2250[3]中描述了傳輸單獨的視訊流和音訊流所採用的 RTP 封裝方式。以下將分別介紹視訊流及音訊流的包裝格式。. 2.3.1.1 RTP Payload Format for MPEG-2 Video Stream MPEG-2 視訊流定義在 ISO 13818-2[9]中，其結構如 figure 2.8 所示，MPEG-2 視訊流是由 I、P 與 B frame 所組成，每個 frame 由許多的 Slice 組成，Slice 可以切割成許多的 Macroblock，Macroblock 是組成 frame 的最小單位，且同一個 Slice 的所有 Macroblock 都會位於 frame 的同一個水平位置上，可以參考 figure 2.9。而在每張 I frame 前都會有 ESDS data，包含了 sequence_header、group of picture header…等，這些 header 將攜帶描述此視訊流的相關資訊如:frame 24.

(35) rate、frame size…等。. Figure 2.8 MPEG-2 Video Stream Example. Figure 2.9 Slice Distributed In Frame Schematic Drawing. 而 RTP 對 MPEG-2 視訊流的封裝遵循著以下四點的原則: MPEG-2 的 Video_Sequence_Header 出現的時候，將總是在一個 RTP payload 的開始處。 25.

(36) MPEG-2 的 GOP_header 出現的時候，將總是在一個 RTP payload 的開始處，或跟隨在一個 Video_Sequence_Header 的後面。 MPEG-2 的 Picture_header 出現的時候，將總是在一個 RTP payload 的開始處，或跟隨在一個 GOP_header 的後面。每一個封包還必須包含一個整數數目的視頻片斷(Video slices)。. 從上述四點可以得知所有的 ESDS data 都必須要被放入在同一個封包中，因此 RTP payload 的部分最小的長度約為 261 bytes，包含了所有的 ESDS data，而另外一點須要注意的是不管 payload 的部份為視訊流或是音訊流，在 RTP 固定的 header 之後都會跟隨著 4 bytes 長的 specific header，可以參考 figure 2.10 的說明。. Figure 2.10 MPEG-2 Video Stream -Specific Header MBZ (5 bits) Unused. 必須為 0。保留作為將來使用。 T (1 bits) MPEG-2 視訊流的延伸 header，位元值為 1 時，表示 Specific Header 後會跟隨另一 header。 TR (10 bits) Temporal Reference. 當前圖片的 GOP 暫存，這個值的範圍從 0-1023，而且對所有給定圖片之 RTP 而言為常數。. 26.

(37) AN(1 bit) 標示錯誤回復狀態的位元(大小為 1bit)，當 MPEG-2 下的圖片 header 資訊改變時設定為 1；而在 MPEG-1 下或者該位元未被使用時設定為 0。 N(1 bit) 當 AN 被設為 1 且在 MPEG-2 下被使用，除此之外，必須為 0。當先前傳送圖片的 header 不能重建當前圖片的 header 時設為 1，這種情況會發生在當前的圖片與先前圖片是用不同設定的編碼。這個 N 位元對所有相同圖片的 RTP 而言必須為常數,如此從一個圖片接收的任何封包，才能偵測圖片資訊是否有必要重建(N=1),或是之前的圖片(N=0)。 S (1 bit) Sequence header present.當 payload 中有 MPEG sequence header 出現時此欄位會設成 1。 B (1 bit) Beginning of slice (BS).如果 payload 內有 slice start code 、 Video_Sequence_Header、GOP_header 或者是 Picture_Header 的話，此欄位會設置成 1。 E (1 bits) End of slice (ES). 如果 payload 內有 MPEG slice 最後區段資料則設為 1。 P (3 bits) Picture Type. I (1), P (2), B (3) or D (4). FBV (1 bit) 全部 pel 的順向導引。 BFC (3 bits) 逆向框架的代碼。 FFV (1 bit) 27.

(38) 全部 pel 的逆向導引。 FFC (3 bits) 順向框架的代碼。. 2.3.1.2 RTP Payload Format for MPEG-2 Audio Stream MPEG-2 音訊流通常都是以 frame by frame 的方式儲存，且通常每個 frame 的大小都不會超過 LAN/Ethernet 的 MTU，所以在 RTP payload 的部份通常都是包含了一個單獨音訊流的 header 及 bit-stream 的部份。而音訊流的 specific header 定義如 figure 2.11。. Figure 2.11 MPEG-2 Audio Stream -Specific Header MBZ (14 bits) Unused. 必須為 0。保留作為將來使用。 Frag_offset (18 bits) 數據封包造成音訊框架位元組的偏移量。. 2.3.2 RTP Payload Format for M4V 在 RFC3016 中定義了如何切割 MPEG-4 視訊流於 RTP payload 當中，但在此要先說明 MPEG-4 視訊流中 video packet 的觀念，在 MPEG-4 video 的壓縮中，使用 video packet 的目的是為了幫助解碼器進行錯誤的恢復，一個 VOP 中可能會含有多個 video packet，可以參考 figure 2.12；在網際網路的傳輸過程中常常會有封包遺失的情況發 28.

(39) 生，如果遺失的封包中含有 VOP header 的資料時，將會使得屬於這個 VOP 所有的 Macroblock 都無法進行解碼，而 video packet 可以解決此一問題，依據 ISO14496-2[8]，一個具有 video packet 的 MPEG-4 simple profile 會如 figure 2.12 所示，video packet 是由許多 Macroblock 所組成，當解碼端讀取到 video packet 時，會開始讀入 Macroblock，每讀取完一個 Macroblock 時解碼端會判別接下來是否會出現 video packet header 或是 VOP header，若是這兩者都沒有出現的話則解碼端就會判斷接下來仍是 Macroblock。. Figure 2.12 MPEG-4 Video Stream-Video Packet. 在 RFC3016 中基本是建議再一個 RTP 封包裡面只放入一個 VOP，這是因為在 RTP header 中的 Timestamp 欄位值會隨著不同的 VOP 而變動，但是在實際的應用上此種作法會造成頻寬的浪費，因為有時候 VOP 會只有 VOP header 但卻沒有 video packet，有時候某種形狀的 VOP 其 video packet 會很小，在這樣的情形之下，若是仍舊讓一個 RTP 封包只包有一個 VOP 的話將會產生 overhead 的效應，因此 RFC3016 中允許多個 VOP 串聯再同一個封包中，因此在 RFC3016 中也對 Timestamp 有額外的定義產生如下: 若封包中含有多個 VOP，則 Timestamp 的值定義為這些 VOP 中最早出現的一個，而其他的 Timestamp 則可由 VOP header 中的資訊進行推算。假如此一封包中只包含了 configuration information，則 29.

(40) Timestamp 定義為下一個出現的 VOP。若此封包中只含有 visual object sequence end code，則 Timestamp 定義為上一個出現的 VOP。. 而在 RFC3016 中定義了對 MPEG-4 視訊流的封裝遵循著以下的原則： Configuration information 與 Group_of_Video_Object_Plane ( ) 應該要放在 RTP payload 的最前面。若有多個 header 放在 RTP payload 中，則要依據 syntax 的順序排放，而 visual_sequence_end_code 是排在最末。同一個 header 不能拆解存放到兩個封包中。除非一個 VOP 的資料量太小，否則盡量一個 VOP 存放在同一個封包中。盡量讓同一個 video packet 放在同一個封包中。. 綜合以上五點規則，在 RFC3016 中列舉了幾個 RTP 封包的例子，可以參考 figure 2.13[4]所示。以下分別簡述其優缺點: Figure 2.13(d) 一個封包中裝載了一個 video packet。優:適用於易遺失封包的網路環境，因為即使其中一個封包遺失，但是其後封包中的 video packet header 中包含的 HEC(Header Extension Code)機制仍然可以使得解碼器找到目前 RTP 封包中的 Macroblock 位於 VOP 的何處，並且解碼器亦可由 VOP 表頭中得知解碼的方式。缺: 因為一個 RTP 封包中只裝有一個 video packet，故 UDP/IP/RTP header 的 overhead 將會使得網路傳輸量變大。. 30.

(41) Figure 2.13(e) 多個 video packet 放入同一個封包中。優:適用於網路頻寬較差的情形下，因為可以減少因 UDP/IP/RTP header 所產生的 overhead 的問題。缺:會減弱因封包遺失後解碼端進行錯誤恢復的能力。 Figure 2.13(f) 優:沒有 video packet header 的 overhead，也就是不採用 video packet 的作法，目的是希望藉此提高封包使用率。缺：僅限用於無錯(error-free)的網路環境下，因為此種裝載方法每當封包遺失後便幾乎沒有錯誤恢復的能力。. Figure 2.13[4] RTP Packet Example. 31.

(42) 第三章 RTP 封裝演算法的設計原理介紹在一個隨選即播的串流系統裡，伺服器會提供本地端的檔案列表給予客戶端選擇，當伺服器端收到客戶端的播放請求時，並不知道其所請求播放檔案類型為何，因此伺服器需要有一個機制可以去辨別客戶端所選擇要傳送的檔案格式類型，進一步的將檔案中的視訊流和音訊流分離成獨立的媒體以及辨認出各自的編碼類型，再來依據各媒體的編碼特性對資料進行解析及切割，並將其包裝成一個個的封包透過網際網路傳輸到客戶端。而這樣的一個流程在多媒體串流系統中，是由「封包包裝和傳送」此一模組負責做統籌處理，此模組是整個系統內部運作的重心所在，最主要在於實現特定的封裝演算法，產生適合網路環境的封包並且傳輸。. Figure3.1『封包包裝和傳送』模組方塊圖參考 figure3.1，一個『封包包裝和傳送』模組可以視作成四個區塊，分別是來源檔案建立與類型判斷、位元解析與訊框產生、封包切割與包 32.

(43) 裝以及封包傳送，在本章中將個別解說每一個區塊所進行的工作內容與方式，並在第四章以 Live 555 Stream Server 說明『封包包裝和傳送』模組的實現方式。. 3.1 來源檔案建立與類型判斷當伺服端收到客戶端請求播放某一個影音檔案的要求後，伺服端會找到此一檔案並開啟，在此階段必須要知道檔案的類型，要先知道檔案的 container type 後，再進一步拆解出檔案中所包含的音訊流及視訊流的 codec type，才能在進行「位元解析與訊框產生」階段時選用適當的解析器與訊框產生器。. Figure3.2(A) 檔案格式判別說明圖-Method1 通常判斷檔案的類型所採取的方式有兩種，第一種是先讀入檔案開頭的一段位元流到暫存器內，進行 container type search，因為不同類型的檔案，都有其固定的語法及編碼值，以 MPEG2 的檔案為例，其檔案開頭的編碼值為「000000BA…」，因此只要識別此段位元流到對應的編碼值相似度最大的格式類型，便可以得知此影音檔案的 container type 為何，尋找到 container type 後會再進一步辨識檔案中 elementary stream 中的 codect type，進而可以選用相應的解析器與訊框產生器， 33.

(44) 如 figure3.2 所示。而如果檔案本身為 codec type，因在 container type search 中找不到對應的 container type，就會直接辨識 codec type，再選用相應的解析器與訊框產生器。. Figure3.2(B) 檔案格式判別說明圖-Method2 另一種作法是直接讀取副檔名，由 2.2 節的說明中，可以知道每一種 container type 及 codec type 在作業系統上都有其相對應的副檔名，如副檔名為.mpeg 檔案對應的即是 MPEG-2 的 container type，而.m4v 檔案對應的則是 MPEG-4 的 codec type，因此伺服器可以以讀取副檔名的方式來判斷要選擇何種解析器與訊框產生器，如果讀入的副檔名為 container type 的話，則要先解析出檔案中的 elementary stream 的 codec type 才能進行解析器與訊框產生器選擇。此種方式的優點在於不必先讀入檔案內容便可立即知曉檔案的編碼格式並直接進入下一階段，也可以節省判斷的時間與暫存器的使用，但其缺點是在面臨偽檔名或是錯誤的副檔名時，便會產生無法正確解析檔案內容的問題，因此在精確度上並不如第一種方法來的好。. 3.2 位元解析與訊框產生當檔案開啟並找到對應系統格式後，便須要選擇相應的位元流解析 34.

(45) 器(parser)來分析 elementary stream 中 header 所攜帶的資訊，進而抽取出音訊流及視訊流，並設置訊框產生器(framer)來分離出音訊流或是視訊流中的 header 和訊框資料；一般而言會將解析器與訊框產生器視為一體也就是 parser，因為都是對檔案的位元流進行分析並找出所需要的資料，且其可以視作一個模組但其中一些細節部份須要依據每種編碼規格而有所變動，下面將解說整個解析器與訊框產生器的設計及運作方式，並以下面兩個例子說明: 1.M4V: 解析 elementary stream 中 header 所攜帶的訊息並產生 frame。 2.MPEG-2 Program Stream:從 container type 辨認 elementary stream 的 codec type。. 3.2.1 M4V 檔案解析從 2.2.2 小節中可以知道，M4V 是單純的視訊檔，其整個檔案位元流架構共可以分成六個階層，每一階層都有其起始碼(start code)，利用起始碼這個特殊編碼值可以劃分出六個區塊如 table3.1 所示，其中前面三個區段(VS+VO+VOL)為組態資訊，是重要的解碼資訊，可以視作一體，而 frame 則是存在 VOP 這個區段中。 Table3.1 MPEG-4 位元流結構表 Start code MPEG-4 configuration information(組態資訊) Visual Object Sequence (VS) Visual Object (VO) Video Object Layer (VOL) Elementary stream data(基本流資料). 000001B0 000001B5 00000120~2F. Group Of Video Object Plane (GOV). 000001B3. Video Object Plane (VOP) 場景結束. 000001B6. Visual Object Sequence End Code. 000001B1. 35.

(46) Figure3.3 MPEG-4 parse model. 參考 figure3.3 所示，每一個區塊可以視作一個獨立的處理程序，但彼此之間具有層次關係，因此每一個處理程序進行完畢後便會視其之後的 start code 的值而將 parser 狀態設至相對應的處理程序，箭頭所指的方向是下個會執行的程序，如果是多重路徑(像是青綠色箭頭線段)，則表示下個要執行的程序是其中的一條路徑；在每一個程序中除了會進行分析 header 所攜帶的訊息外，同時也會將檔案的位元流切割成一塊塊的區塊存放在輸出緩衝區中，每一個區塊資料都是由起頭的 start code 到下一階層的 start code 之間的位元流，而這些區塊資料即是 frame，在下一階段封包包裝中便是將這些 frame 包入 packet 中。的以下分別說明六個處理程序的內容。 36.

(47) 1. Visual Object Sequence (000001B0) 開始從來源檔案的輸入緩衝區中讀入 MPEG-4 視訊位元流，此時會不斷的搜尋視訊位元流，直到找到 Visual Object Sequence start code:“000001B0”後才會真正的進入解析的處理程序中；參考 figure3.4，Visual Object Sequence 這層資料區段的總長是由 header information 的 5 個 bytes 再加上長度不定的“User data” 資料流所組成。Header information 包括 4 bytes 的 Visual Object Sequence start code 和 1 byte 的“profile_and_level_indication”； “profile_and_level_indication”是用來告訴解碼器其所用的解碼工具類型為何及其支援程度。. 另外在 Visual Object Sequence 這層中還會包含“User data”的部份，這部份是編碼此檔案的使用者自行定義的資訊，是給解碼器的訊息，在 MPEG-4 編碼系統裡是選用的功能，所以不一定會存在，也因此“User data”會被解析器視為普通的資料位元流，其 start code 的編碼值也不在解析器識別範圍內。. Figure3.4 Visual Object Sequence segment 解析器會將 Visual Object Sequence header information 及之後的 37.

(48) “User data”位元流儲存起來直到在視訊位元流中看見 Visual Object start code 後才會停止且結束這個階段的工作，並將解析器狀態設為下個處理程序: Visual Object。. 2. Visual Object (000001B5) Visual Object 整個區段結構如 figure3.5 中的(a)部份所示，整個區段的資料大小為固定的 header information 在 9~10 bytes 間，有時會另外再加上“User data”部份而使區塊資料長度增加。Visual Object 區塊資料長度會有所變異的原因主要是“is_visual_object_identifier”此一欄位所攜帶的資訊不同所致；在 Visual Object 區段中的第五個 byte 中的第一個 bit 即是“is_visual_object_identifier”，參考 figure3.5 的(b)，當此位元為 1 時，須進一步的找出在跟隨在後 4 bits 的 “visual_object_verid”和 3 bits 的“visual_object_priority”的資訊，兩者相關訊息意義請參考 table3.2[8]。. “is_visual_object_identifier”與“visual_object_verid”再加上 “visual_object_priority”共為 1 byte 也就是 Visual Object 區段中的第五個 byte。接下來第六個 byte 中的前 4 bits 為“visual_object_type”，其所表示的訊息意義請參考 table3.3[8]，而第七至十這 4 bytes 的編碼值是一組 start code，代表著“visual_object_type”所選用的型態訊息區段開端，一般情況中 visual object type 所選用的型態通常為 video ID，從 ISO/IEC 14496-2[8]中可以查閱到: Code value if (visual_object_type==“video ID”){ video_object_start_code VideoObjectLayer() } 38. 00000100~1F.

(49) 也因此第七至十這 4 bytes 通常為 video_object_start_code。. Table3.2[8] Meaning of visual_object_verid and visual_object_priority visual_object_verid: This is a 4-bit code which identifies the version number of the visual object. When this field does not exist, the value of visual_object_verid is ‘0001’. visual_object_priority: This is a 3-bit code which specifies the priority of the visual object. It takes valuesbetween 1 and 7, with 1 representing the highest priority and 7, the lowest priority. The value of zero is reserved. visual_object_verid. Meaning. 0000. reserved. 0001. Object type listed in ISO/IEC 14496-2 Table 9-1. 0010. Object type listed in ISO/IEC 14496-2 Table V2-39. 0011-1111. reserved. Table3.3[8] Meaning of visual object type visual_object_type: The visual_object_type is a 4-bit code given in table which identifies the type of thevisual object. visual_object_verid. Meaning. 0000. reserved. 0001. Video ID. 0010. Still texture ID. 0011. mesh ID. 0100. FBA ID. 0101. 3S mesh ID. 01101. reserved. … 1111. … reserved. 如果“is_visual_object_identifier”位元值為 0 時，則表示沒有做任何特別的設定，因此緊跟在後的 4 bits 會是“visual_object_type”，而不會存在“visual_object_verid”和“visual_object_priority”兩個欄 39.

(50) 位，如 figure3.5(c)所示，“is_visual_object_identifier”與 “visual_object_type”會組合成為一個 byte，所以 Visual Object 區段資料大小會變成 9 bytes。. Figure3.5 Visual Object Segment. 而 Visual Object 區段資料儲存動作會在存入 video object start code(或是其它型態的 start code，請參考[8])至輸出緩衝區後結束，且解析器也會將狀態設為下個處理程序: Visual Object Layer 並停止且結束這個階段的工作。 3. Video Object Layer (00000120~2F) Video Object Layer 此一區段的資料量並不固定，基本的 header information 佔有 16~20 bytes，而隨著 header 中每一個參數的意義不 40.

(51) 同會再增加更多的資訊位元，有時也會再加入額外的“User data”的資訊位元流，因此整個 Video Object Layer 區段資料是由 header information 再加上“User data”所組成。當解析器進入 Video Object Layer 這個處理程序中時，首先會進行 VOL 的 header 分析，header 的各個欄位的參數請參考 figure3.6 和 table3.4，在 figure3.6 中所示的是固定的參數欄位，在 table3.4 中則是因參數設定而額外增加的相關參數。在這階段中最主要是找 vop_time_increment_resolution、 fixed_vop_rate 和 fixed_vop_time_increment 三個參數並從中分析相鄰兩張 VOP 之間的時間間隔資訊。. Figure3.6 Visual Object Layer Segment 當解析器分析 header information 後，會將 header 與之後的位元流儲存至輸出緩衝區直到看見下一個 start code 才停止，並結束這個階段的工作，解析器會依據所看到的 start code 的碼值將狀態設定為 Group Of Video Object Plane 或是 Video Object Plane 兩者其中之一的處理程序。. 41.

(52) Table3.4[8] Visual Object Layer parameters Parameter. Extra Parameter No. of bits video_object_layer_verid 4 is_object_layer_identifier=1 video_object_layer_priority 3 aspect_ratio_info par_width 8 ==“extended_PAR” par_height 8 chroma_format 2 vol_control_parameters=1 Low_delay 1 vbv_parameters 1 first_hafe_bit_rate 15 marker_bit 1 latter_half_bit_rate 15 marker_bit 1 first_half_vbv_buffer_size 15 vbv_parameters=1 marker_bit 1 latter_half_vbv_buffer_size 3 first_half_vbv_occupancy 11 marker_bit 1 latter_half_vbv_occupancy 15 marker_bit 1 fixed_vop_rate = 1 fixed_vop_time_increment 1-16 video_object_layer_shap … …. 4. Group Of Video Object Plane (000000B3) 由於 GOV 在 MPEG-4 編碼系統中是選用的功能，並非每一個視訊位元流中都具有此區塊，因此這個階段的處理程序並不會常態性的執行。此程序最主要是分析一群 VOP 中每張 VOP 被獨立編碼的各個時間點，讓位元串流中能夠加入多個隨機存取點。整個區塊的資料長度由 7 bytes 的 header information 與不定長度的“User data ”所組成。解析器會將這 7 bytes 的 header information 與之後的“User data ”存入輸出緩衝區直到看見 Video Object Plane start code 為止。此階段結束後會將解析器的狀態設成下個處理程序:Video Object Plane。 42.

(53) 5. Video Object Plane (000000B6) 在 Video Object Plane 的區塊資料可以視為 7 bytes 的 header information 與之後的 VOP 資料位元流所組成。參考 figure3.7 所示，這 7 bytes 由“Video Object Plane start code”、“vop_coding_type”、 “modulo_time_base”和“vop_time_increment”所組成；如 table3.5[8] 所示，“vop_coding_type＂位元值決定該 VOP 的編碼種類為 I、P、B frame 其中一種。而“modulo_time_base”和“vop_time_increment”則代表此一 VOP 播放的時間資訊；當位於 Video Object Layer header 中的“fixed_vop_time_increment”的值不存在時，則 VOP 的播放時間相關參數會採用“modulo_time_base”和“vop_time_increment”的值， “modulo_time_base”表示本地端的基底時間，以秒為單位，而 “vop_time_increment”則是播放的時間間隔，以毫秒固定的增加。若 “fixed_vop_time_increment”有值存在則會以它為主，而忽略 “modulo_time_base”和“vop_time_increment”這兩個參數的值。. 解析器會不斷的將 Video Object Plane 區塊中的 header information 和其後的 VOP 資料位元流存入輸出緩衝區直至看見下個狀態的 start code 時才會停止，此時會設置一個旗標，這個旗標的狀態是用來表示在緩衝區中的這段位元流是一張完整的 VOP，此一旗標在『封包切割與包裝』中扮演著重要的角色。. Table 3.5[8] Meaning of vop_coding_type vop_coding_type 00 01 10 11. coding method intra-coded(I) presictive-coded(P) bidirectionally- presictive-coded(B) sprite(S) 43.

(54) Figure 3.7 Video Object Plane Segment 當這個階段結束會依之後的 start code 的值將 parser 狀態設成下面處理程序其中一種: (1.). Visual Object Sequence End Code. 表示一個場景完整的結束。但此編碼值並非一定會存在。. (2.). Visual Object Sequence. 代表又進入一個新的場景，回到起始的處理程序重新開始。 (3.). Group Of Video Object Plane. 表示一群 VOP 的開端，再次分析每張 VOP 被獨立編碼的時間點。. (4.). Video Object Plane. 代表又是一張新的 VOP 的開始。. 6. Visual Object Sequence End Code (000001B1) 代表一個場景的結束，整個區段的資料只有 Visual Object Sequence End Code:000000B1 4 個 Bytes 而已，所以此區塊資料會和上個階層 VOP 的資料區塊合併為一，同樣的也會設置一個旗標，表示在緩衝區中的資料是完整的 frame。此時會再將解析器的狀態設成起始處理程序:Visual Object Sequence。. 44.