Linux PDA:Video/Audio Streaming With RTP/Multicast

Over Wireless Network

指導老師:吳曉光教授

 

張中原

目錄

1. Introduction

1.1 Video/Audio Streaming

1.2 Wireless Network

2. Multicasting

2.1 Multicasting技術

2.2 Multicast Group Address

2.3 Multicast & MBone

3. Video/Audio Streaming

3.1 Video & Audio

3.1.1 AVI

3.2 Video - DiVX(MPEG4)

3.3 Audio - DiVX(MP3)

3.3.1 MPEG Audio Layer III

3.3.2 MPEG Audio Layer III - Frame Format

4. RTP/RTCP

4.1 Preview

4.2 RTP

4.2.1 RTP專有名詞介紹

4.2.2 RTP Header

4.2.2.1 RTP Header中的固定欄位

4.2.2.2 RTP Header中的欄位說明

4.2.3 RTP Payload Format for MPEG4 Visual Streams

4.3 RTCP

4.3.1 RTCP 簡介

4.3.2 RTCP 三大功能

4.3.3 RTCP Packet 種類

4.3.4 RTCP 注意事項

5. Implmentation

5.1 整體架構

5.1.1 Framework

5.1.2 Server

5.1.3 Client

5.2 RTP 實作

5.2.1 RTP Sender

5.2.2 RTP Receiver

5.3 Screenshots

6. Todo

Appendix參考資料

1.Introduction

 

1.1 Video/Audio Streaming

 

　　網際網路的蓬勃發展，網路頻寬迅速擴增的情況下，已經
開始有很多網路服務的供應商開始提供線上即時影音傳輸的服
務，雖然這樣的服務帶給使用者更多的聲光享受，但是也相對
的增加了網路傳輸的負荷，而RTP的出現再搭配Multicast的應用
，將能有效的提 供即時影音傳輸，不浪費網路頻寬。

 

 

1.2 Wireless Network

 

　　Wireless LAN在大環境一片低迷當中，迅速竄起，相當引
人注目，無線區域網路主要可分為高速無線傳輸技術及低速無
線傳輸技術(包含HomeRF、Bluetooth)，尤其以高速無線傳輸技
術中的IEEE 802.11的發展狀況更是吸引人去了解。IEEE
802.11是針對無線區域網路制定的一個國際的標準。而最近歐
洲的電信業界中開始有人討論用Wireless LAN(802.11)來作為高
速無線上網的替代方案，因為第三代行動電話(3G)雖然有無區
域限制的好處，但是建置的成本過高，且技術不成熟。因此可
以考慮在人口密集的城市建置Wireless LAN形成MAN
(Metropolitan Area Network)，更能讓PDA的使用者隨時隨
地都能夠利用PDA做Conference。

 

 

2.Multicasting

 

2.1 Multicasting技術

 

　　傳統的技術，要將封包送達目的地，有兩種方式，一種是
Unicast，這個方式很直覺，也就是封包可以遞送給指定的單一
台電腦 (或主機、路由器等任何具有IP位址的東西)，另外一種
則是Broadcast，可以將封包遞送給LAN上所有的主機。
　　也就是說，如果您要將一個封包送給十台主機，如果這十
台主機不是LAN上的所有電腦，那麼您必須將這個封包送十次，
分別遞送給十台主機；而Multicast就是為了解決這個窘狀，他
可以將一個封包送給多台主機－但不是全部的主機，而這些主
機也不用在LAN上，可以在Internet的任何一個地方，不過又有
一個前提，這些主機必須存在於具備Multicast功能的LAN上。
　　搭配Multicast的IGMP(Internet Group Management (IP
Protocol)，使得個別主機可以加入Multicast群組，並且接收到
Multicast的封包。而當Multicast開始運作時，就會有群組位址
Class D Addresses)的產生，等到Multicast結束運作後，這個群
組就會解散。

 

 

2.2 Multicast Group Address

 

　　在網際網路裡頭，每一個Node多半會有位址(IP
Address)，而此IP Address可以當成此Node的ID，我們可以方
便準確的傳送資料給對方。在IPv4的網路定址中，我們將Class
A、ClassB、Class C給一般用途使用，而Class D的位址便專門留
給Multicast使用，因此我們常將Class D的網路位址稱為
Multicast Addresses。
 
Class A : 1.0.0.0 - 127.255.255.255
Class B : 128.0.0.0 - 191.255.255.255
Class C : 192.0.0.0 - 223.255.255.255
Class D : 224.0.0.0 - 239.255.255.255
Class E : 240.0.0.0 - 247.255.255.255
 
　　雖然Class D為Multicast Addresses，但是224.0.0.1-
224.0.0.255為保留範圍，以供特殊用途使用，而且Multicast
Addresses不會受到TTL(Time to Live)的限制。

 

 

2.3 Multicast & MBone

 

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

 

 

3.Video/Audio Streaming

 

3.1 Video & Audio

 

　　一般來說，做視訊會議在應用上大多是將聲音與影像分兩個
RTP Session(見4.RTP/RTCP)在傳送，其中一個Session負責聲音的
部份，另外一個 Session 則負責影像的部份，這樣做的方式，可以
允許加入會議的使用者，選擇只接收 Video 或者 Audio，但影音同
步的問題，則必須依賴 RTCP (見4.RTP/RTCP)來達到同步化。而這
次是傳送一個已經內含有聲音影像的 Raw Data 過去(AVI file),這樣
就不需要去考慮到影音同步的問題,讓 Raw Data 中的同步協定自己
去做,我們聲音壓縮的格式主要是採 MPEG Layer III ,影像壓縮主要
是採MPEG4,最後合成一個RIFF-AVI傳送過去。

 

 

3.1.1 AVI

 

　　AVI(Audio Video Interleave)為一種檔案格式就像JPG或者
MP3，但是不同的地方在於，AVI內Video和Audio的格式並非固

定，也就是說，你可以用任何不同的壓縮格式(不同的Codec)來
將組合Video 和 Audio，所以對MP3或者JPG來說，這些檔案裡
面只包含了部份的壓縮格式(例如MPEG Audio Layer III和JPG)
但是AVI卻可以包含各種不同的許多種的壓縮格式組合(例如
DiVX的Video + WMA的Audio或者Indeo的Video + PCM的Audio
)

 

 

3.2 Video - DiVX(MPEG4)

 

　　DiVX是一個新的Video格式，就像MP3為新的Audio格式一
樣。DiVX CODEC(COmpression - DECompression)以MPEG4
壓縮標準為基礎。說到MPEG4，ISO/IEC JTC1/SC29/WG11組
織已經為其制定標準化，其目標：
•在10Kbps-2Mbps程度的低速率下，依然可以確立播放
•編碼後的資料（即壓縮後），也可以用軟體的方式來解碼（
解壓縮）
•維持與急遽變化的網際網路環境的對應擴張性
•對於各種傳送率，品質與性能接能維持著彈性
•增加互動能力
 
　　MPEG4規格至今內容已經膨脹甚多，要詳細的描述
MPEG4有點困難。以MPEG4的特徵來說，MPEG2是MPEG1的擴
張規格，並維持向下的相容性。而MPEG4卻採用完全不同的壓
縮方式，而最大最大的特點是他並不像MPEG1/2硬性規定DCT
及MC的壓縮演算方式。MPEG4並無特定的壓縮演算方式標
準化，他可以因應用途來自由組合，這是認識MPEG4的第一個
觀念。MPEG4本身就是物件指向符號化的觀念，理念上的應用
近似C++、Java的程式領域中的物件指向。以一個具體的實例
來解說，就立刻明瞭了。比如說一個影像，他可以是由背景、
人物 、建物等物體來構成。那麼每一個物體都可以獨立分解開
來，以最適用的方式來分別壓縮各個被獨立開來的物體。而且
，MPEG4所針對的對象並不限定於現實的風景、人物，或聲音
等自然素材。

 

 

3.3 Audio - DiVX(MP3)

 

3.3.1 MPEG Audio Layer III

 

　　MP3是MPEG Layer 3的簡稱，也就是MPEG第三層的意思
。MPEG是種聲音壓縮的標準，目前已發展到第三層次的壓縮標
準，因此才有所謂的MP3。每一層的壓縮法不同，層階數愈高
，壓縮複雜度就愈高。第一層標準壓縮效率為1：4，第二層則
為1：6 - 1：8，第三層的壓縮效率則高達1：10 - 1：12，也就
因為如此的高壓縮比才使得MP3壓縮成的音樂檔的流通性及實
用性大增。
　　MP3使用了強大的失真性壓縮，此演算法是透過過濾掉超
高音波來達成壓縮聲音的目的，因此壓縮後的MP3檔其實音質
已是選擇性的變差，就像JPG圖檔壓縮一樣，利用小小的失真效
果來達成高壓縮的目標，不過MP3高明的一點就是它所過濾掉
的超高音波我們是不容易查覺出來的，這也是為什麼MP3目前
雖然經過高比例的壓縮，但一般人聽起來卻會感覺與原來的音
檔無太大的不同。

 

 

3.3.2 MPEG Audio Layer III - Frame Format

 

　　MPEG Audio是採用frame-based的壓縮方式，也就是說
Audio Data以frame by frame的儲存方式。而每一個frame的
format如下：
Header
CRC
Main Data
Header總共為4個bytes(總共32bits)，而這些bit構成一些information如下
AAAAAAAA AAABBCCD EEEEFFGH IIJJKLMM
Sign Length
(bits) 		Position
(bits) 		Description
A 11 (31-21) Frame Sync (all bits should be set)
B 2 (20-19) MPEG Audio version ID:
00 - MPEG Version 2.5 (unofficial)
01 - reserved (=something is wrong)
10 - MPEG Version 2 (ISO/IEC 13818-3)
11 - MPEG Version 1 (ISO/IEC 11172-3)

Note: MPEG Version 2.5 is not official standard. It is an extension of the standard used for very low bitrate files.
C 2 (18-17) Layer description:
00 - reserved (=something is wrong)
01 - Layer III
10 - Layer II
11 - Layer I
D 1 (16) Protection bit:
0 - Protected by CRC (16bit crc follows header)
1 - (surprisingly enough) Not protected
E 4 (15-12) Bitrate index:
bits MPEG1 layer I MPEG1 layer II MPEG1 layer III MPEG2 layer I MPEG2 lay II & III
0000 free free free free free
0001 32 32 32 32 8
0010 64 48 40 48 16
0011 96 56 48 56 24
0100 128 64 56 64 32
0101 160 80 64 80 40
0110 192 96 80 96 48
0111 224 112 96 112 56
1000 256 128 112 128 64
1001 288 160 128 144 80
1010 320 192 160 160 96
1011 352 224 192 176 112
1100 384 256 224 192 128
1101 416 320 256 224 144
1110 448 384 320 256 160
1111 bad bad bad bad bad

Notes:
all values are kbps (kilobit/second)
MPEG2 also includes MPEG2.5

"free" means free format. If the correct fixed bitrate is different than those presented in upper table it must be determined by the application. It will be (almost) impossible to find out what bitrate it is, and really impossible for any common player to decode.
"bad" means that this is not an allowed value (=something is wrong).

F 2 (11-10) Sampling rate frequency index:
bits MPEG1 MPEG2 MPEG2.5
00 44100 22050 11025
01 48000 24000 12000
10 32000 16000 8000
11 reserv. reserv. reserv.

Notes:
all values are in Hz.
"reserv." (=something is wrong)
G 1 (9) Padding bit
0 - frame is not padded
1 - frame is padded with one extra slot

Padding is used to fit the bit rates exactly. Some of the frames in .mp3-file will have padding and some not. For an example: 128k 44.1kHz layer II uses a lot of 418 bytes and some of 417 bytes long frames to get the exact 128k bitrate.
For Layer I padding is 32 bits (4 bytes) long,
for Layer II and Layer III padding is 8 bits (1 byte) long.
H 1 (8) Private bit, I don't think it has any standardised purpose
I 2 (7-6) Channel Mode:
00 - Stereo
01 - Joint stereo (Stereo)
10 - Dual channel (Stereo)
11 - Single channel (Mono)

Note: Dual channel files are made of two independant mono channel. Each one uses exactly half the bitrate of the file. Most decoders output them as stereo, but it might not always be the case.
J 2 (5-4) Mode extension (Only if Joint stereo)

Mode extension is used to join informations that are of no use for stereo effect, thus reducing needed resources. These bits are dynamically determined by an encoder in Joint stereo mode.

Complete frequency range of MPEG file is divided in subbands There are 32 subbands. For Layer I & II these two bits determine frequency range (bands) where intensity stereo is applied. For Layer III these two bits determine which type of joint stereo is used (intensity stereo or m/s stereo). Frequency range is determined within decompression algorythm.

Layer I and II Layer III
value Layer I & II
00 bands 4 to 31
01 bands 8 to 31
10 bands 12 to 31
11 bands 16 to 31
Intensity stereo MS stereo
off off
on off
off on
on on

K 1 (3)

Copyright:
0 - Audio is not copyrighted
1 - Audio is copyrighted
L 1 (2) Original:
0 - Copy of original media
1 - Original media
M 2 (1-0) Emphasis:
00 - none
01 - 50/15 ms
10 - reserved
11 - CCIT J.17

 

 

4.RTP/RTCP

 

4.1 Preview

 

　　一家公司的成員們想藉由multicast傳達聲音的方式，進行
一場線上會議。會議的主席透過某種配置的機制，獲得了一個
multicast address，以及一對port，其中一個port是為了RTP(傳
送聲音)，另一個則是為了RTCP(傳送控制packet)。這些位置與
port的資訊會分布給所有想加入會議的公司成員。
　　
　　使用聲音會議程式的公司成員，可送出一小塊的聲音資料
，每一小塊資料前會被加上RTP的header。RTP header會指出
每一個packet所包含的資料是用什麼壓縮方式，像是PCM,
ADPCM, LPC…等。在會議的過程之中，傳送聲音資料的公司成
員，可以改變聲音的壓縮方式，以配合經由窄頻連接到
Internet的的新加入者，或是對網路壅塞做出反應。
 
　　如同其它packet網路一般，Internet偶而也會遺失 一來，
packet，或是將packet的順序用亂。為了處理這些損害，RTP
header會包含時間的資訊，以及一個sequence number。如此
所有加入會議的成員就可以依此來重組收到的packet，甚至估
計有多少packet遺失。
　　
　　因為在會議的過程之中，公司成員們可能會加入或離開會
議，所以知道某人在何時加入，還有他接收資料的狀況，會是
很有用的。為了達到這個目的，每一個會議上的application，都
會在RTCP的port上，定期群播包含使用者名稱的reception
report。Reception report會指出傳送聲音資料的成員，被接收
的程度如何，也可以用來控制適合的聲音壓縮方式。當然，除
了使用者名稱，其它辨識資訊可視控制頻寬的限制，被加入
reception report。當某人想離開此一會議，application將送出
RTP BYE packet。

　

　　

4.2 RTP

 

　　即使在壅塞的線路上，TCP還是可以保證資料的正確性；
但是對於即時性的封包和多址傳遞，TCP就無能為力，因此，就
有了RTP這個東西。
 
　　RTP (Real-Time Transport Protocol, 即時傳輸協定) 在，
IETF RFC 1889中定義，而透過RTP載送語音和影像資料的方法
則在RFC 1980，這兩項標準早在1996年一月就提出，不過在
1997年底才定案。
 
　　RTP是在網路層 (Network Layer) 和傳輸層 (Transport 用
Layer) 中，因此除了TCP以外，RTP還可以在ATM、IPX環境使
；事實上，雖然RTP設計的時候是和TCP一起運作，但大多數的
實作中，RTP並不是和TCP一起運作，而是和UDP。
 
　　在RTP的標題中，提供了必要的時間資訊 (timing
information)，如此接收端才知道傳輸的過程中，是否有封包遺
失了，以及接收到封包之順序，此外，RTP標題還包含了資料的
形式判別，如此允許各種資料和各種壓縮格式，均經由RTP資料
傳遞。

 

　　　

4.2.1 RTP專有名詞介紹

 

RTP packet: 一個開頭有RTP header的packet，即為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 packet與RTCP packet到同一個IP

Address時，port就可以用來區分目的地的不同。
Transport address: 一般都是IP Address加上UDP port。
packet都是從一個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，就可以被稱為Monitor。
Monitor可以被內建在End system中﹔也可以不直接參與RTP
session，這種Monitor被稱為Third Party Monitor。

 


4.2.2 RTP Header

 

4.2.2.1RTP 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

……

 

 

4.2.2.2RTP 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 payload的format，而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，只有15個CSRC可以被識別。

 

 

4.2.3 RTP Payload format for MPEG4 Visual Streams

 

　　在RFC(Request for Comments)3016中，提到RTP的
Payload format for MPEG4 Audio/Visual Streams，其中討論到
該如何對MPEG4的visual bitstream做切割來防止一些突發狀況
，例如RTP封包遺失後，造成的影像無法decode的問題等等。
底下為其提供的幾個切割的範例：
(a)
RTP Header VS Header VO Header VOL Header
(b)
RTP Header VS Header VO Header VOL Header Video Packet
(c)
RTP Header GOV Video Object Plane
(d)
RTP Header VOP Header Video Packet(1) RTP Header VOP Header Video Packet(2)
(e)
RTP Header VP Header Video Packet(1) VP Header Video Packet(2) VP Header Video Packet(3)
(f)
RTP Header VOP Header VOP fragment(1) RTP Header VOP fragment(2)
其中以(c)適合於Packet-Loss rate較高的網路，我選擇使用這
個方式在Wireless LAN上應用。

 

 

4.3 RTCP

 

4.3.1 RTCP簡介

 

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

 

 

4.3.2 RTCP三大功能

 

(1)RTCP主要的功能是了解資料distribution的quality。再配合
distribution機制，像是IP Multicast，就可以讓network service
provider這類實際上沒有加入RTP session的單位，去診斷網路上
的問題。
(2)RTCP包含一個不變的RTP source的transport-level CNAME來
identifier，叫做canonical name或是CNAME。Receiver依靠
追蹤每一個participant。RTP也使用CNAME在一組相關的RTP
sessions中，將來自同一個participant的多的data stream作聯繫
。
(3)前面兩個功能都需要所有的participant傳送RTCP packet，所
以為適應大量的participant，傳送的速率就要控制。透過每一個
participant傳送RTCP packet給其他participant，所有的
participant可以觀察現在participant總數目，而這個數目就用來
計算傳送RTCP packet的速率。

 

 

4.3.3 RTCP Packet種類

 

RTCP packet可以包含以下五種資訊：
SR: 紀錄sender的reception statistics。
RR: 紀錄receiver的reception statistics。
SDES: 有關source的資訊，像是CNAME。
BYE: 指出某一participant的離開。
APP: 指出某一application特有的functions。

 

 

4.3.4 RTCP 注意事項

 

(1)每一個RTCP packet最前面都會有固定的部分，然後根據倍
packet種類的不同，接著長度不同的資料，但總bit數都是32的
數。
(2)多個RTCP packet可以結合，而不需要任何的separator。
(3)每一個RTCP packet一定要包含SR/RR與有CNAME的SDES，
而且SR/RR一定是在最前面。

 

 

5.Implementation

 

5.1 整體架構

 

　　整個project是實作Linux PDA平台的streaming，負責接
收另外一組Windows平台Streaming所送出的video/audio
streams，並送給decoder並做display。

 

 

5.1.1 Framework

 

 

 

5.1.2 Server

 

　　Server端採用Windows平台的Server，將已經壓縮好的
影像及聲音，以Multicast的方式傳送。也可以透過Server上安裝
CCD擷取壓縮影像並傳送至網路上

 

 

5.1.3 Client

 

　　Client端加入Multicast群組後，便可開始接收Server端
的資料，不論Server端送出的是Video Clip或者是CCD擷取的影
像，皆可順利接收。

 

 

5.2 RTP實作

 

5.2.1 RTP Sender

 

 

　　RTP Sender是採用另外一組專題同學所設計的Sender，
而這邊有經過修改，RTP Payload中都是frame based的video和
audio的data，由於尚無法實作4.2.3中所談到的切割方式，所以
先利用這樣的方式，還是可以達到所預期的效果-封包掉了以後
Receiver端仍然可以正常播放。

 

 

5.2.2 RTP Receiver

 

 

　　RTP Receiver端，先判別是否收到Header，收到Header
後，便開始接收接下來的封包，否則的話都先drop。收到封包
後，先將data送到cache layer做一段buffer，再送給decoder，
最後再做輸出。

 

5.3 Screenshots

 

Screenshot 1 Screenshot 2
Screenshot 3 Screenshot 4

 

 

6.ToDo

 

☉加強MP3 Decoder在decode mp3 stream的能力。
☉加強RTP和RTCP功能
在RTP和RTCP有許多機制可以讓我們去作反應和調整，若能好
好研究，就能善用現有的功能。

 

Appendix參考資料

☉RFC 3016 - RTP Payload Format for MPEG-4 Audio/Visual Streams

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

☉FFMpeg (http://ffmpeg.sourceforge.net)

☉MAD: MPEG Audio Decoder (http://www.mars.org/home/rob/proj/mpeg/)

☉Online MSDN (http://msdn.microsoft.com)

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

☉MPlayer (http://www.mplayerhq.hu/homepage/)

☉RTP Library in dvbstream(http://www.linuxtv.org/news/martin/dvbstream03.xml)

☉DearHoney (http://www.dearhoney.idv.tw)