JMF 是一種應用程式介面，整合了 time-based media 到 Java applications 和 Applet。如果程式設計者，對 JMF 的格式興趣也可以自行 延伸JMF，以 plug-in 的方式加入新的 media-supported type，並可自行實 作設計transport-layer 層的傳輸方式。
以下是JMF 的設計目標
• 容易去設計。
• 對於Capture device media 的存取。
• 使Java 能傳輸多媒體串流和網路電話的程式
• 提供進階程式師和技術去實作和延伸。
• 提供對raw media data 存取能力。
• 提供發展downloadable demultiplexers, codecs, effects processors, multiplexers, and renderers 的能力。
3.3.1 High-Level Architecture
像 tape decks 和 VCRs 這此裝置，提供了常見的 recording model，
processing、和呈現 time-based media。當我們用 VCR 播放 movie，
我們藉由放入video tape 來提供 media stream，而 VCR 讀取和解釋在 tape 中會資料，然後傳送適合的訊號到 TV 和 Speaker.
JMF 使用和這一種相同的 basic model，Data source 結合入 media stream 如同 tape，Player 就如同 VCR 控制和處理的機器，而 Playing 和 Capturing audio 和 video 的輸入裝置和輸出裝置就是如同 microphones, cameras, speakers, and monitors。
Data sources 和 players 是 JMF's high-level API 中不可或缺 的部份，來處理Caputre Device,及呈現和運作以時間為基礎的多媒 豐。JMF 也提供了低階的 API，使設計者可以進而延伸和作細部的設 計。
High-level JMF achitecture.
3.3.2 Players
Player 處理 media data 的 input stream 和以精確的時間呈現它。
DataSource 被用來來傳送 input media-stream 到 Player，而 render 則依靠多媒體的形態來呈現。
JMF player model.
Player 沒有提供任何在控制和如何處理呈現 media data。而 Player 提供了一個標準化的User Control 和藉由 Clock 和 Controller 來簡作 上層的控制。
3.3.2.1 Player States
一個Player 可以有 6 個 state. Clock介面定義了 2 個主要 state:
Stopped and Started.為了要使資源的管理容易，所以 Controller 分開了Stopped state 到 5 個 tates: Unrealized, Realizing, Realized, Prefetching, and Prefetched.
Player states.
在正常的運作過程，一個Player 可以到達每一個 state 直到 Started State:
l Player 在 Unrealized state 被起始化，但對 media 的資 訊還不了解，當Player 被建立後，它就在 Unrealized State.
l 常realize 被呼叫，Player 開始由 Unrealized state 移到 Realizing state，Realizing Player 是處理決定資源的需 求，在realization 階段，Player 得到它只需得到一次的 資源，可能包含呈現資源，一個Realizing Player 常由網 路得到這些資訊。
l 當Player 完成 Realizing，它移動到 Realized state，
Realized Player 了解那些資源需要和資訊，由於 Realized Player 了解如何去呈現，所以可以得到 visual
components and controls 的資訊。
l 當prefetch 被呼叫，Player 由 Realized state 到
Prefetching state，Player 正準備去呈現 media ，在這一 階段，Player 會先 load 它的 media 資料，和惟一使用的 資料，Prefetching 如果 Player 回到先前的狀態，會再發 生，因此Player 需要額外的 buffer，來交換狀態。
Unrealized Realizing Realized Prefectching prefetched Started
l 當Player 完成 Prefetching，它移到 Prefetched state，
Prefetched Player 就進去等待開始的狀態。
l 呼叫start 使 Player 進入 Started state.，Started Player 的time-base time 和 media time 作 mapping 的動作，且 clock 也開始 running，即使 Player 可能還在等待一個特 定的時間去呈現。
3.3.3 Processors
Processors 也可以用來呈現 media data.Processor 只是一種 Player 的特別形態，提供了處理 input media stream。Processor 提供 了所有和Player 一樣的 controls。
JMF processor model.
除了呈現media data 到輸出裝置，Processor 可以輸出 media data 以DataSource 的方式，將 DataSource 指定到下一個 Player or Processor，更進一步 Processor 可以傳送另一目的地，如傳送到 File 中。
3.3.3.1 Processing
Processor 是一種 Player 以 DatatSource 為輸入，執行一些使 用者定的程序在media data，然後輸出和處理 media data
JMF processors.
Processor 可以送輸出資料到資料呈現的裝置或輸出到
DataSource，如果資料是輸出到 DataSource，DataSource 可以被 使用如同另一個Player 或 Processor 的輸入，也可以輸出到 DataSink。
當由Player 處理執行之前所定義的工作，Processor 允許應用 程式發展者去定義處理的形態，對應到相對的media data，它使 得應用程式的effects、mixing、compositing 以即時的方式來處 理。
處理media data 分為下列幾個 stages
Processor stages.
² Demultiplexing 是 parsing input stream 的過程，如果 stream 包含了多個tracks，它們分出和輸出個別地。
² Pre-Processing 是處理 effect algorithms 到 tracks 抽出到 input stream.
² Transcoding 是處理轉換每一 media data 的 track 的過程，
當data stream 從 compressed type 到 uncompressed type。
² Post-Processing 處理加入有效率的演算以去 decoded tracks.
² Multiplexing 是處理內部轉碼 media tracks 到單獨的 output stream
² Rendering 處理資料給 the user.
3.3.3.2 Processor States
Processor 有二個額外的等待 state, Configuring and Configured，它們發生在 Procssor 進入 Realizing state 之前。
Processor states.
Ø 當 configure 被叫 Processor 進入 Configuring state，.
它連接到DataSource, demultiplexes 的 input Stream，
且存取關於輸入資料的格式資料。
Ø 當已連接到DataSource，Processor 移到 Configured state，且資料的格式已經決定，當 Pocessor 到達 Configured state，會發生 ConfigureCompleteEvent。
Ø 當Realize 被呼叫，Processor 轉到 Realized state，
Processor 只會有一次建構完整的Realized State.
Realized
Unrealized Configing Configed Realizing Prefecth Prefetch Started
3.3.4 Real-Time Transport Protocol
在JMF 中也提供了 RTP(Realtime Transport Protocol)的運作控 制，RTP 提供了點對點的及時性資料傳輸 Service。RTP 是和網路和 transport-protocol 獨立的協定，即使它一般是以 UDP 來傳輸。
:RTP architecture.
RTP 可以被使用在 unicast and multicast 的網路 Service.藉由 unicast network 的 Service 環境，可以分別資料複製由來源到每一個 目的端。藉由unicast network 的 Service 環境，可以傳送 Stable 的多 個目的地。Multicasting 對於許多多媒體應用程式是相當有效率的，如 在多人的視訊會議。在標準的Internet Protocol (IP)對於 multicasting 的提供。
3.3.4.1 RTP Services
RTP 可以給使用者定義要被傳送的資料型態，決定每一資料 封包要以何種順序來傳送，和如何同步來自於不同的多媒體來源。
RTP 資料封包並不保證到達的順序和它們的送出的順序相 同，事實上，它們一點也不保證是否到達目的地。再來就是在接收 端必需藉由加在封包header 的資訊去重新建構傳送端的封包順 序，並偵測遺失的封包
由於RTP 沒有提供任何機智去保證即時性的傳輸或提供其它 Service 的品質，因此它加入了 control protocol (RTCP)，使用者 可以monitor 資料傳輸的品質，RTCP 也提供了對於 RTP 傳輸的 控制和定義機智。
如果Service 的品質對於特別的應用程式是必需的，RTP 可以使用 resource reservation protocol 來提供 connection-oriented 的 Service。
3.3.4.2 RTP Architecture
一個RTP session 是以 RTP 應用程式的傳輸關聯性集合，
session 是以網路位置和一組 ports 組成。一個 port 是使用在多媒 體資料，另一個是用來傳輸control (RTCP)資料。
Participant 是一個單獨的運作個體，或是使用者
participating 在這一個 session 中，Participant 在 session 中可以 由被動的接受資料，主動的傳送資料組成。
每一種多媒體形態以不定的session 來傳輸。所以如果在網路 電話會議中如果包含了audio 和 video ，一個 session 用來傳輸 audio 資料，另外一個 session 用來傳輸 video 資料。因此它使得 participants 可以去選擇他們想接收那一種多媒體形態，如果某人 只有一個low-bandwidth 的網路連線環境，他可能只要接收網路 電話會議得audio 部份。
3.3.5 Data Packets
一個session 的多媒體資料傳輸如同一連串的封包。一連串的封包 資料是以RTP stream 來自某一特定的來源。每一個 RTP 在 Stream 中 資料封包含二個部份，一個是結構化的header，和另一個真正的資料 (packet's payload)。
RTP data-packet header format.
RTP 資料的 header 包含了以下容: header 會隨著另一 header extension。Extension 的機智使得加 入資訊在 header 得以完成 的timestamp，像是全部相同部的 video frame。
•
SSRC: 32 bits. 同義了同時性的來源，如果 CSRC count 是 0，
payload source 就是同時性的 source，如果 CSRC count 是非 0，SSRC 則定義為 mixer。
•
CSRC: 32 bits each. 定義了貢獻給 payload 的來源，
contributing sources 的數目在 CSRC count 欄位中指出，可以達 到26 個 contributing sources，如果有許多部份所組成的
contributing sources， 則 payload 就是那些 sources 的 mixed 資 料。
3.3.6 Control Packets
除了在session 多媒體資料之外，control data (RTCP)也是週期性傳給 所有在session 的 participants，RTCP packets 可以包含給 session
participants 的 Service 品質資訊，來源資訊在 data port 傳輸，統計目前已 傳的的資料。
• Application-specific
RTCP packets 是可以堆疊的，它傳送了混合的封包，包含了至少二個 封包，一個是report packet，另一個是 source description packet。
所有在session 的 participants 傳送 RTCP packets，一個最近有傳送 的資料封包的的participant，會產生 sender report。Sender report (SR) 的內容包括了全部數的封包和byte 數目，如同資訊會被使用來自不同 session 的同步多媒體串流
Session participants 會週期性地產生 receiver reports 給所有接收資料 封包的來源，Receiver report (RR)的內容包括了關於封包遺失的數目，最 大已接收的sequence number，和一個 timestamp，可以用來減少在 Sender 和Receiver 之間來回的 delay。
在混點的第一個RTCP packet 必需是 report packet，即使沒有資料被 傳送or 接收，在這一種情況，一個空的 receiver report 被傳送了。
所有混合的RTCP packets 必需包含了有定義來源的 canonical name (CNAME) 的 source description (SDES) 元素。除此之外，資訊可能包含 在source description，像是 source 的名稱,電子郵件的位址，電話號碼，來 源的位址,應用程式名稱, or 訊息內容，來描述目前的來源狀態。
當來源不再運作時，它傳送一個RTCP BYE packet。在 BYE 說明它離 開session 的原因。
RTCP APP packets 提供了給應用程式定義了資訊經由 RTP control port 傳送的機智。
3.3.6.1 Receiving Media Streams From the Network
一些形態的應用程式必需能夠接收RTP streams，如:
l 網路電話會議必需能夠接收來自RTP session 的 media stream，並且在使用者的控制環境下呈現。
l 電話答錄機應用程必需能多接收來自RTP session 的 media stream，並儲存成檔案。
l 一個紀錄交談內容或網路電話會議必需能夠接收來自RTP session 的 media stream，可以在使用者的控制環境下呈現，
且能儲存到檔案。
3.3.6.2 Transmitting Media Streams Across the Network
RTP Server 應用程式傳送由 capture device 所得到的資料或 由已儲存的media streams 到網路。
例如:
在網路電話會議應用程式中，其中一個media stream 可能擷 取來自video camera，然後傳送出一個或多個 RTP session。且 media streams 可能被碥碼成複合的多媒體格式，然再以送出幾個 RTP session 到網路電話會議不同形式的接收者，多人網路電話會 議以許多的unicast RTP session 來實作 multicat。
3.3.8 H.263 與 H.261 的差異
事實上，H.263 只是 H.261 的進一步延伸，而延伸方式則採 用了類似MPEG 的方法，其間差異主要在於兩者目標的不同：
l 兩者鎖定的目標位元率(Target Bit-rate)不同，H.261 是px64Kbps，H.263 則希望在 64Kbps 以下，這是因 為前者係利用ISDN，而後者則希望透過現有的電話線
² 位移估計(Motion Estimation)的精確度可以到達半個像 點(Half-pixelaccuracy)；這種方式和 MPEG 所使用的方 式類似，主要是因為人眼視覺的特性，使得我們可以利用 這種方法將位移估計的準確度提高。也就是說，利用影像 在時間上的相關性將影像作更多壓縮。
² 可重疊式的區塊位移補償(Overlapped Block Motion Compensation;OBMC)；當我們利用位移估計找出最相似 中一個新的增強模式中(AdvancedPrediction Mode;AP)。
² 算術編碼方式；以往的壓縮方式在對付統計上的多餘性，
通常是利用霍夫曼編碼(Huffman Coding)來達成可變長
通常是利用霍夫曼編碼(Huffman Coding)來達成可變長