=專題=

Multicast & RTP 即時影音傳輸

 

目錄:

-前言

-Framework

-Microsoft Direct Show 

-FilterFilter Graph

-使用DirectShow

-DS整體架構

-DS的彈性

-COM (Component Object Model)

-Multicast

-RTP/RTCP

-多媒體檔案格式

-系統初步架構

-系統最後架構

-系統架構圖-- DirectShow Filter

-傳送端Screen Shot

-接收端Screen Shot

-後記

-參考資料

-投影片和程式碼下載

 

 

前言

        此專題的目的是將遠端CCD與MIC取得的影像與聲音,壓縮成MPEG4 (Divx)格式,以RTP透過Multicast的方式,即時傳給多台電腦,實作平台都是WIN32 PC,最終目標是讓接收端不限於WIN32 PC,比如是WinCE PDA、Linux PDA等等,目前的平台著重於WIN32 PC。

 

      整個專題的成員總共有五人,工作分成三大部分,分別是RTP小組、多媒體檔案格式小組、Microsoft DirectShow小組,而我們小組主要負責的部分是Microsoft DirectShow部分,雖說工作是如此分的,在許多方面仍須去研究並了解,否則實作出的程式模組是無法結合的。

 

 

 

 

 

 

 

 

Framework

 

 

 

Microsoft Direct Show

   撥放端與傳送端影音擷取技術主要是採Microsoft Direct Show達成, Microsoft Direct Show包含在Microsoft DirectX之中,要開發程式之前首先要去微軟官方網站下載DirectX SDK (目前是採8.0a),整個SDK中包含許多說明文件與程式範例,大部分的技術支援都是從此取得的。

      Direct Show(後簡稱DS)整個是以Microsoft COM原件完成,DS可以說是數個COM原件組成,使用DS就是於程式中產生所需的COM原件,並對元件呼叫所需的開放介面,以下開始介紹DS的細節部分。

 

 

 

 

Filter與Filter Graph

Preview

DS中最基礎的單位稱為Filter,每一個Filter代表對多媒體資料進行一個處理步驟,在DS中有三種型態的Filter,分別為Source Filter、Transform Filter、Render Filter。

 

 

Filters

 

Source Filter主要的工作是讀取Raw Data ; Transform Filter主要工作是取得Source Filter的Raw Data並加工處理(通常扮演Decoder角色),Render Filter主要工作是取得Transform Filter處理的Raw Data並輸出到適當的裝置(比如寫入檔案、輸出影音設備等等),其關係圖如下圖所示:

 

 

 

 

 

 


Filter Graph & Filter Graph Manager

   由此三種Filter間組成的圖稱為Filter Graph,就如上流程圖一樣,而在DS中主要掌管控制Filter Graph的COM Component為Filter Graph Manager。

 

 

Filter component

 

   各個Filter在DS中是以COM實作,因此我們使用DS就相當於在程式產生符合需要的Filter Component,其後將Filter組成一個Filter Graph,最後控制Media Stream的流向就算大公告成,比方如下的範例(撥放AVI的Filter Graph):

 

 

 

 

 

 

 

 


Summary

透過Filter Graph我們可以清楚了解到多媒體資料是如何被處理的。­Filter的架構讓應用程式對多媒體處理能力很有彈性,程式設計師像是在拼裝Graph,拼出一個符合我們多媒體需求的Filter Graph。

 

 

 

 

 

◆ 使用DirectShow

使用DS的步驟在此更詳細的說明一遍:

STEP1

由於我們會使用到COM,因此一開始我們必須先呼叫Windows初始化COM Library的API,然後產生一個Filter Graph Manager Component。

STEP2

再來我們就要產生完整Filter Graph,而產生的方法分為兩種,一種是自動產生符合多媒體的Filter Graph(由Filter Graph Manager來做這項工作),另一種是我們手動產生個個需要的Filter Component並將圖給建立起來給Filter Graph Manager管理。

STEP3

最後的步驟就是控制Media Stream的動作,此時需要一個Media Control Component來作管理,其中控制了Media Stream的Stop、Pause、Start動作。還有Media Stream可能會產生些事件(如撥放完畢),這時我們可以產生一個Media Event Component來作管理事件的動作。

 

 

 

 

DS整體架構

   下圖是來自DS SDK Document,在此我們可以更了解DS的內部架構。虛線方塊部分就是我們程式所能控制的部分,也是上上幾篇介紹的部分。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


DS的彈性

        DS本身附上許多Filter,但也有可能會發生找不到合適的Filter來完成我們的專案,要是發生這種情況我們就得去寫出一個Filter出來,而寫出一個Filter所涉及的背景知識蠻多的,在此次專題就碰到這個頭痛的問題。基本上DS本身已經附上一些Base Class,繼承這些Base Class並Over Ride一些方法就會使的這個開發過程容易些。

 

 

 

 

 

COM(Component Object Model)

        使用DS只需知如何使用COM(Filter全為COM原件),但如果需要開發Filter就必須去了解COM,並知道如何實作COM原件,否則就不能繼續下去,在此簡略說明一下Microsoft COM。

COM

        COM並不是一種程式語言,也不是特定的函式庫,COM是一種規格定義,COM規定了製作具有動態替換能力元件的方法,也定義了用戶端程式與元件之間共同合作的標準。使用COM讓程式變成是像由原件組成,程式設計師設計可以重複的使用原件,日後要是軟體更新只要將須汰換的原件更新,不用大幅修改程式,讓日後軟體維護的工作更容易,減少軟體成本。

就如下圖所示:

Application

 
 

 

 

 

 

 

 


        原本單一獨立的程式變成由許多原件組成,而原件也能在執行階段動態更換,或許有些人會想這不就是把程式分成幾個模組,但是在COM中A、B、C、D、E是一個可執行二進碼(完整的程式,通常是DLL),而不是structure paradigm的程式寫作風格,而各元件都是透過介面來溝通,程式可以在執行階段更換原件。

 

COM Component

 

        COM Component是Win32動態連結程式庫或可執行檔存在的可執行程式碼,以COM規格標準所寫出來的元件,我們就稱為COM Component。

 

Summary

 

     DS中所有的Filter都是以COM存在,在此我們已經可以看到COM的一些好處,就是庸有高度的彈性。微軟的許多技術都是以COM完成,如OLE、ActiveX都是建構在COM上面,COM的目的是達成軟體IC理想。

 

 

 

 

 

Multicast

Preview

     在網路中的傳送模式可以分為三種,Unicast、Broadcast、Multicast ,Unicast屬於一對一的傳送方式 ,Broadcast是對整體網路做傳送,Multicast是對整體網路的特定幾台(Multicast Group)做傳送,Multicast的實作也可以靠Unicast或Broadcast實作出來,但是這種模擬方式會非常浪費網路資源。

Multicast常應用於多媒體方面(如VOD),而此次的多媒體傳送是以Multicast來傳送,讓加入同Multicast Group的電腦可以接收遠端多媒體。

 

Mbone(Multicast Backbone)

     若要各網域能收送全球性的multicast封包,就需要其router或其它硬體也要能支援multicast封包的轉送動作,但若其網域只支援unicast方式的傳送,這時候若使用多址傳輸骨幹網路(Multicast Backbone, MBone),則我們可以藉此達到網路多址傳輸的目的。現在世界上已經許許多多的MBone網路。因此Mbone引入了通道(Tunnel)的概念。事實上,Mbone是一個虛擬的網路骨幹,Mbone藉由通道將一個個的多址傳輸的網路(Multicast Island)連起來

 

 

Multicast Group Address

   Multicast Group Address定在Class D IP,如下圖:

 

 


   Ipv6的格式,如下圖:

 

 

 

 

 

 

 

 

RTP/RTCP

Preview

RTP針對需要傳送即時資料的application,像是影像,聲音,模擬資料等,提供了在multicastunicast上,點對點的傳輸功能。

RTP沒有保留資源的能力,亦不保證即時服務的OoS。但RTP可與另一控制協定(RTCP)結合,來監測資料傳輸的狀況,以及增加一些控制與識別的功能。

Application一般都在UDP之上跑RTP,這兩者都提供了部分的傳輸功能﹔然而,RTP也可以與其他適合的下層protocol一起運作。

在傳統的protocol中,若要增加新的功能,只有將protocol改得更一般化,或是加入一個需要分析的選項機制。不同於此的是,RTP只要修改或者增加header就可以達到目的。

現今的Internet環境,並無法完全滿足即時服務的要求。使用RTP的寬頻服務,像是影像,可能會影響其它網路服務的QoS。因此,程式設計者必須採取一些措施,限制次要的服務利用頻寬。

群播聲音會議

一家公司的成員們想藉由multicast傳達聲音的方式,進行一場線上會議。會議的主席透過某種配置的機制,獲得了一個multicast address,以及一對port,其中一個port是為了RTP(傳送聲音),另一個則是為了RTCP(傳送控制packet)。這些位置與port的資訊會分布給所有想加入會議的公司成員。

使用聲音會議程式的公司成員,可送出一小塊的聲音資料,每一小塊資料前會被加上RTPheaderRTP header會指出每一個packet所包含的資料是用什麼壓縮方式,像是PCM, ADPCM, LPC…等。在會議的過程之中,傳送聲音資料的公司成員,可以改變聲音的壓縮方式,以配合經由窄頻連接到Internet的的新加入者,或是對網路壅塞做出反應。

如同其它packet網路一般,Internet偶而也會遺失packet,或是將packet的順序用亂。為了處理這些損害,RTP header會包含時間的資訊,以及一個sequence number。如此一來,所有加入會議的成員就可以依此來重組收到的packet,甚至估計有多少packet遺失。

因為在會議的過程之中,公司成員們可能會加入或離開會議,所以知道某人在何時加入,還有他接收資料的狀況,會是很有用的。為了達到這個目的,每一個會議上的application,都會在RTCPport上,定期群播包含使用者名稱的reception reportReception report會指出傳送聲音資料的成員,被接收的程度如何,也可以用來控制適合的聲音壓縮方式。當然,除了使用者名稱,其它辨識資訊可視控制頻寬的限制,被加入reception report。當某人想離開此一會議,application將送出RTP BYE packet

聲音與影像會議

如果聲音與影像都被使用在會議中,application將使用兩個UDP port pair,以及(或著)兩個multicast address,分別來傳送聲音與影像的RTPRTCP。然而RTP並沒有方法直接將聲音與影像的session做結合,除非participant在聲音與影像的RTCP packet中,都使用相同的CNAME

將聲音與影像以不同的session來傳送,其中一個原因是,允許加入會議的人,只選擇接收其中一種媒體。

雖然聲音與影像的session是分開的,但是同步化仍然可以藉著RTCP packet中的時間資訊來達到。

Mixer

在之前的兩個情況中,我們假設所有的participant都能接收相同format的媒體資料。然而,這卻不是完全正確的。

想像某一區域的人是透過低速線路連接到Internet,而其它區域的人則是透過高速線路連接到Internet。與其強迫所有人都使用較少的頻寬,RTP寧可在靠近第速網路之處,放置一個名為mixer的機制。

Mixer會先將收到的packet作同步化以重組packet,然後將這些重組過的packet混和到單一的資料流,最後再將壓縮方式改為適合低速網路的format,並透過低速線路將新formatpacket傳送給低速網路中的participant

RTPheader中,會有一種方法可以讓mixer辨識每一個混和過的packet的傳送者,如此一來,receiver就可以知道packet是由誰發出來的。

 

Translators

如果有些participant是透過高速線路連接到Internet,可是不支援IP Multicast,像是被FirewallInternet隔絕,因為Firewall外的packet都無法進入Firewall內部。在這種情況下,RTP將使用一個名為Translator的機制。

Translator的機制是安置兩個Translator,一個在Firewall外部,一個在Firewall內部。外部的Translator傳送multicast packet,內部的Translator則透過安全的管道收到這些multicast,之後內部的Translator再將這些multicast packet轉送給Firewall內的participant

其它用途

在一個影像會議中,mixer可以把每個人的影像分成若干等份,然後將它們合成放到單一個資料流,來模擬群體的景象。

如果在一個遠距會議中,有兩群人分別使用不同的底層protocol,例如一群人使用IP/UDP,另一群人使用ST-II。或是影像的壓縮方式是一個packet接著一個packet,而不需重組或混和。此時,Translator也可派上用場。   

RTP專有名詞說明

RTP packet: 一個開頭有RTP headerpacket,即為RTP packet。通常在底層protocol中,一個packet只包含一個RTP packet,但透過一些特別的encapsulation方法,底層packet也可以包含一個以上的RTP packet

 

RTP payload: RTP packet中,真正要傳送的資料,即為RTP payload。例如在影像會議中,影像資料就是RTP payload

RTCP packet: 一個開頭是RTCP header,後面接著控制資料的packet,即為RTCP packet。通常許多RTCP packet會被結合,再加上底層的header,而結合後的RTCP packet長度會被紀錄在RTCP header中的length欄位。

Port: RTP想傳送RTP packetRTCP packet到同一個IP Address時,port就可以用來區分目的地的不同。

Transport address: 一般都是IP Address加上UDP portpacket都是從一個source transport address傳到一個destination transport address

 

RTP        session: 對於每一個RTP使用者而言,RTP session是由一對destination transport address定義而成(一個為了RTP,另一個為了RTCP)。要注意的是,一個多媒體會議中,不同的媒體資料最好在不同的RTP session中傳送。

Synchronization source (SSRC): SSRC是一個隨機選取的識別值,用意是使一個RTP session中的participant都有獨一無二的識別資訊。但是同一個使用者在不同的RTP session中,並不一定要用同一個SSRC

Contributing source (CSRC): 之前提過mixer可以將不同來源的RTP packet混和放到同一個RTP packet中。此時,RTP也會在RTP header中紀錄與這個packet有關的SSRC,而這些SSRC合起來就叫做CSRC

End system: 如果一個application可以產生內容被包在RTP packet中被傳送,或是可以讀取RTP packet中的內容,就可以被稱為End system

Monitor: 如果一個application可以接收在一個RTP session中所有participant送來的RTCP packet,就可以被稱為MonitorMonitor可以被內建在End system中﹔也可以不直接參與RTP session,這種Monitor被稱為Third Party Monitor

RTP header中的固定欄位

0

1

2

3

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

 

V=2

P

X

CC

M

PT

Sequence number

Timestamp

Synchronization source (SSRC) identifier

Contributing source (CSRC) identifier

……

 

RTP header欄位說明

Version (V): 說明RTP的版本。

Padding (P): 如果這個欄位被設定,RTP packet尾端將會包含一個以上的padding octets,但它們並不是RTP payload的一部份,而在padding的最後一個octet會記錄在這個RTP packet中有多少個octet。在某些壓縮演算法,或是底層的通訊協定,padding有可能會被用到。

Extension (X): 如果這個欄位被設定,在固定的RTP header後還要加上一個 header extension

CSRC count (CC): 紀錄CSRC的個數。

Marker (M): 用作重要事件,像是影像中frame的界限識別值。這個值的解釋是留給application去處理。

Payload type (PT): 用來定義RTP payloadformat,而format的解釋則是留給application去處理。

Sequence number: 每送出一個RTP packet之後,sequence number就會增加一。Sequence number也可以被receiver用來偵測packet loss,以及恢復packet的順序。

Timestamp: 用來記錄RTP packet第一個octet被讀取的取樣時間。

SSRC: 如同前面的定義。要注意的是,如果一個source改變它的source transport address,它必須選擇一個新的SSRC

CSRC list: 如同前面的定義。要注意的是,如果一個RTP packet包含15個以上的CSRC,只有15CSRC可以被識別。

RTP header注意事項

前十二個octet一定會出現在每個RTP packet﹔但CSRC list只有packet經過mixer才會被填入。

Multiplexing注意事項

要先說明的是,如果一個protocol想有效率的運作,multiplexing的點應該盡量減少。

RTP中,multiplexing是藉由destination transport address來完成。例如一個包含影像與聲音的遠距會議,聲音與影像將在不同的RTP session中被傳送。基本上,RTP並不希望影像與聲音等不同的資料在同一個RTP session中被傳送,然後再根據payload typeSSRCdemultiplex

Multiplexing可能遇到的問題

在同一個RTP session中使用同一個SSRC會造成以下五個問題﹔至於在同一個RTP session中使用不同的SSRC,將可避免前三個問題,但仍會遇到後兩個問題:

如果在session運作的過程中,有payload type的改變,將沒有方法知道是哪一個舊的payload type被取代。

可能需要不同的計時方式,以及sequence number空間。

不論是RTCP sender report或是RTCP receive report,當針對同一個SSRC,都只能描述一個計時方式,以及一個sequence number空間。而且,沒有payload type欄位。

RTP mixer沒有辦法結合不相容的media

如果receiver只想接收RTP session其中一種media,將是不可能的。此外,receiver application想用不同的process去接收不同的media,也是難以達成的。

RTP header extension格式

0

1

2

3

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

 

Defined by profile

length

header extension

……

 

RTP header extension欄位說明

defined by profile: 用來接收一些identifierparameter。以允許要交互作用的implementation可以用不同的header extension去試驗﹔或允許一個特殊的implementation可以用一種以上的header extension去試驗。

Length: 用來記錄在extension32-bit word的個數。

RTP header extension注意事項

Extension機制是為了試驗新的payload-format-independent功能,讓那些功能可以在RTP header中加入需要的資訊﹔但是,若只是某些payload format所需要的而外資訊,則不宜使用header extension,而是應該包含在RTP packet中的payload section

RTCP (RTP Control Protocol)

RTCP簡介

RTCP的原理就是,使用與RTP傳送packet一樣的傳送機制,每隔一段時間就傳送control packet

RTCP三大功能

n         RTCP主要的功能是了解資料distributionquality。再配合distribution機制,像是IP Multicast,就可以讓network service provider這類實際上沒有加入RTP session的單位,去診斷網路上的問題。

n         RTCP包含一個不變的RTP sourcetransport-level identifier,叫做canonical name或是CNAMEReceiver依靠CNAME來追蹤每一個participantRTP也使用CNAME在一組相關的RTP sessions中,將來自同一個participant的多的data stream作聯繫。

n         前面兩個功能都需要所有的participant傳送RTCP packet,所以為適應大量的participant,傳送的速率就要控制。透過每一個participant傳送RTCP packet給其他participant,所有的participant可以觀察現在participant總數目,而這個數目就用來計算傳送RTCP packet的速率。

RTCP packet種類

RTCP packet可以包含以下五種資訊﹔

n         SR: 紀錄senderreception statistics

n         RR: 紀錄receiverreception statistics

n         SDES: 有關source的資訊,像是CNAME

n         BYE: 指出某一participant的離開。

n        APP: 指出某一application特有的functions

RTCP注意事項

n         每一個RTCP packet最前面都會有固定的部分,然後根據packet種類的不同,接著長度不同的資料,但總bit數都是32的倍數。

n         多個RTCP packet可以結合,而不需要任何的separator

每一個RTCP packet一定要包含SR/RR與有CNAMESDES,而且SR/RR一定是在最前面。

 

 

 

 

 

◆ 多媒體檔案格式

        一般利用RTP來做視訊應用通常會分兩個Session來做,一個Session負責聲音傳送,另一個則為影像,這樣的狀況之下必須考慮影音同步的問題。而這次是傳送一個已經內含有聲音影像的Raw Data過去(AVI file),這樣就不需要去考慮到影音同步的問題,讓Raw Data中的同步協定自己去做,我們聲音壓縮的格式主要是採MPEG Layer III,影像壓縮主要是採MPEG4,最後合成一個RIFF-AVI傳送過去。

Mpeg Audio

        Mpeg Audio是採Frame by Frame的儲存方式,一個Frame就是一個最基本的撥放單位,Mpeg Audio的檔案結構如下:

FRAME1
 
FRAME2
 
 

 

 

 

 

 

 

 


31                                                                                          0(bits)

     

      Header的概述如下(詳細欄位資訊可於最後列出的參考資料尋找,因為整個篇幅太大了,不方便列出)

Sign

Length(bit)

Position(bit)

Description

A

11

(31-21)

Frame sync (all bits must be set)

B

2

(20-19)

MPEG Audio version ID

C

2

(18-17)

Layer description

D

1

(16)

Protection bit

E

4

(15-12)

Bitrate index

F

2

(11-10)

Sampling rate frequency index

G

1

(9)

Padding bit

H

1

(8)

Private bit. This one is only informative

I

2

(7-6)

Channel Mode

J

2

(5-4)

Mode extension

K

1

(3)

Copyright

L

1

(2)

Original

M

2

(1-0)

Emphasis

 

 

Mpeg Audio Frame Length

               標頭的資訊我們已經詳細知道了,至於Raw Data的長度可以由以下公式計算出來。

      Read the BitRate, SampleRate , Padding bit and protection bit(CRC) from header.

 

      For Layer I files us this formula:

FrameLengthInBytes = (12 * BitRate / SampleRate + Padding) * 4 + CRC

 

      For Layer II & III files use this formula:

FrameLengthInBytes = 144 * BitRate / SampleRate + Padding + CRC

 

 

Mpeg4

 

      Mpeg4內的壓縮法並不是很清楚,可以參考其SPEC,我們是採DivX MPEG4 Video Codec(filter)來達成我們的目的。

 

RIFF(defined by Microsoft)

 

              因為AVI算是RIFF格式的檔案,因此先簡介RIFF。RIFF(Resource Interchange File Format)是一個二進位的巢狀結構檔案,它並不代表任何多媒體檔案,而它是把多媒體檔案包裝在其定義的結構之中,包裝在RIFF中的多媒體資料主要是以檔案的副檔名來判別,如下所列:

 

·         Audio/visual interleaved data (.AVI)

·         Waveform data (.WAV)

·         Bitmapped data (.RDI)

·         MIDI information (.RMI)

·         Color palette (.PAL)

·         Multimedia movie (.RMN)

·         Animated cursor (.ANI)

·         A bundle of other RIFF files (.BND)

               如上都是RIFF格式的檔案,只是其內含的多媒體資料不一樣。再來要說明的是RIFF結構,在RIFF中的基本單位就是Chunk,如下所列:

 

 

typedef struct _Chunk
{
    DWORD ChunkId;              /* Chunk ID marker */
    DWORD ChunkSize;            /* Size of the chunk data in bytes */
    BYTE ChunkData[ChunkSize];  /* The chunk data */
} CHUNK;
 
 

      ChunkData中又可包含別的Chunck(Sub Chunk),這樣的關係一直下去就如上所稱的巢狀結構

 

 

 

 

AVI

 

               AVI屬於如上述的RIFF格式,AVI內擺的檔案資料包括了聲音與影像,它的Chunk分布如下:

 

struct _RIFF   /* "RIFF" */
{


RIFF CHUNK
 
    struct _AVICHUNK   /* "AVI " */
    {
        struct _LISTHEADERCHUNK   /* "hdrl" */


AVI CHUNK
 
        {
            AVIHEADER AviHeader;     /* "avih" */
            struct _LISTHEADERCHUNK  /* "strl" */


LIST-HDR CHUNK
 
            {
                AVISTREAMHEADER               StreamHeader; /* "strh" */
                AVISTREAMFORMAT              StreamFormat; /* "strf" */
                AVISTREAMDATA    StreamData;   /* "strd" */
            }
        }
        struct _LISTMOVIECHUNK  /* "movi" */
        {


LIST-MOVI CHUNK
 
            struct _LISTRECORDCHUNK  /* "rec " */
            {
                /* Subchunk 1 */
                /* Subchunk 2 */
                /* Subchunk N */
            }
        }
        struct _AVIINDEXCHUNK  /* "idx1" */


INDEX CHUNK
 
        {
            /* Index data */
        }
    }
}

              

               如上所列,這是一個AVI的結構檔案,主要RIFF chunk包裝一個AVI chunk,AVI chunk之中又包含了,LIST-HDR、LIST-MOVI、INDEX三個chunk,LIST-HDR chunk之中主要是紀錄影音資料的資訊,LIST-MOVI chunk是擺影音資料,INDEX chunk是擺影音長度的索引,主要是提供快轉或迴轉影音的資訊,裡面更細部的內容可以參考後面列出的參考資料,因為篇幅長度實在太大了。

 

 

Summary

               並不是所有的格式都是適合在網路上做傳送,許多做多媒體傳送的公司都有另外自訂的檔案格式,如Real Player RA或是Microsoft ASF,此次採AVI格式將影像傳送出去也不是很清楚是否真的合適,這需要更仔細的研究才對。

 

 

 

 

 

◆ 系統初步架構

文字方塊: RTP文字方塊: RTP
 

 

 

 

 

 


        如上圖是我們初步實作出的架構,首先撥放端從DISK取出要撥放AVI File做切割並套上RTP做Multicast傳送給撥放端。撥放端包含Receiver與Player兩部分,但其實是在同一程式於兩個不同的Thread執行。

      撥放端接收到資料後就將AVI片段寫入DISK,最後Player將寫入的AVI片段給撥放出來。

      這邊就出現了一些蠻有趣的現象,就是我們傳送端與撥放端的速度要如何協調,還有之間的頻寬問題呢?!基本上傳送端是根據AVI片段長度來調整速度的。或許可能又會問為什麼撥放端要透過DISK存取這道手續,接收到的AVI片段的RTP Packet一開始不就是在記憶體中,為什麼不直接撥放出來?!主要的原因是因為Player是用DS來實作,而DS此時提供的Source Filter只能從URL或FILE讀取Raw Data,因而我們採FILE的方式,所以要透過DISK而不是從Memory過去,但一透過DISK的方式,我們發覺在撥放AVI片段之間會有些許Delay。

      關於剛剛提到的主要缺失我們也討論初一些解決方案,但是最好的就是直接透過Memory給DS處理,不用這樣拐個彎縮減效能,這就表示說我們需要去開發一個能從自訂記憶體Buffer讀取Raw Data的Source Filter,至於這個部分由於時間不允許,因此尚未實作。

 

 

 

 

 

◆ 系統最後架構

文字方塊: RTP文字方塊: RTP
 

 

 

 

 

 


       

        最後的系統架構如上圖所示,撥放端全部沒有變,而在傳送端改為先由Capture (CCD & MIC Device)取得多媒體,將取得的多媒體先寫入DISK,最後Sender再將寫入DISK的影像傳送出去,而Send與Capture實際上是同一程式,但Run在不同的Thread。

基本上傳送端也是有剛剛所提的毛病,其實是不必透過DISK的,這樣又浪費掉一些系統效能,而且效果又不是很好。

 

 

 

 

 

 

◆ 系統架構圖-- DirectShow Filter

Audio Capture

Filter

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


        如上圖將Capture與Sender部分展成內部DS Filter連結狀況。Optional部分是指可以選擇壓縮方式或不壓縮,影像支援DivX MPEG4 Video Compressor、Microsoft AVI Compressor,聲音方面有MPEG Layer3 Compressor,其實這方面可以根據系統擁有的Compressor來選擇。

 

 

 

◆ 傳送端Screen Shot

        如圖左下,主要的所有功能都在那下拉的Menu之中,包括是否要擷取影像或聲音、是否支援即時壓縮。選擇Start Writing就會開始作傳送捕捉的影音,Stop會暫時停止傳送動作,空白部分是Preview視窗(如下圖畫面)。

 

圖一:開啟Video Capture時,自動出現Capture property視窗

 

 

圖二:操作選單,可以選擇影像、聲音擷取,以及壓縮格式

 

 

 

 

◆ 接收端Screen Shot

圖三:節目選單視窗

 

圖四:撥放CCD和MIC即時擷取的影像、聲音

 

 

 

 

 

 

◆ 後記

        這個專題有些地方是值得繼續研究、改善的,例如RTP/RTCP的控制使用、DS部分改寫Filter來控制Raw data的data flow或試著使用 DS內附的RTP Filter。

      總而言之,這次的專題讓我們接觸到許多以往沒接觸的領域, 括實驗室的一些學長姐們也是,因此許多東西都要花費蠻多的時間去研究和搜尋資料,其中完成的測試程式也很多,包括了Multicast檔案傳輸、MPEG Audio檔案切割器、DirectShow撥放影像、聲音的測試範例、RTP傳送、接收測試程式,領略到Microsoft Direct Show的架構和技術、也學會COM原件設計等等,有了這些概念與實作的基礎,想再深入下去也不會如此艱深。

 

 

 

 

◆ 參考資料

l          Online MSDN (http://msdn.microsoft.com/library/)

l          Microsoft DirectShow 8.0a SDK Document (see DX SDK)

l          JRTP Library Document (http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html)

l          RTP Official Site (http://www.cs.columbia.edu/~hgs/rtp/)

l          RFC 1889 RTP

l          完全剖析COM Dale Rogerson Microsoft Press

l          AVI RIFF FORMAT (http://www.oreilly.com/centers/gff/formats/micriff/index.htm)

l          DirectX, RDX, RSX, and MMX technology : Rohan Coelho and Maher Hawash Addison-Wesley Development Press

l           李英瑞,“IP Multicast 群播網路簡介”,1998.3

 

 

 

 

 

 

◆ 投影片和程式碼下載

        --RTP & RTCP 投影片1

        --RTP & RTCP 投影片2

        --DirectShow 投影片

        =======================   

        --CCD Capture & Sender 程式碼 (CCD_sender)

        --接收端 & 撥放 程式碼 (StreamPlayer)

        --傳送檔案 程式碼 (RTP_Sender)

        --Register Server 程式碼 (Tcptest)