單一用戶的訊框處理

下圖 4.6 是 parsing /display/sending order 的示意圖，經過壓縮後的影音多媒 體便稱為 Elementary Stream，串流工作的開始首先便是去 parsing Elementary

Stream，也就是把 Elementary Stream 中的 frame(如 I/P/B frames)給解析出來，其 後便得到圖 4.6 中的 parsing order，由於 elementary stream 是以 DTS 的順序存 放在硬碟裡，所以 parsing order 也是以 DTS 的順序排列。

圖 4.6 parsing / display/sending order diagram

得到 parsing order 後，雖然我們可以直接對 frame 進行切割、封裝以及傳送

的 header，而其中的 Timestamp 欄位需要用到每一個 frame display order (PTS)的 值，因此我們必須將 parsing order 轉成 display order。而這個轉換機制便是圖 4.6 中的 t(i)，運算式如圖 4.7 中所示(詳細請參考 4.5.1.1 t(i) 函式計算)。

接下來我們又要再次將 display order 轉成 sending order(DTS)，主要原 因為 frame 必須要以 sending order(DTS)的排列順序來傳送，如此用戶端的播 放器接收到 frame 時才能依序解出 P 與 B frame(請參考4.2.2 PTS/DTS )。而 display order(PTS) 轉成 sending order (DTS)的機制是由上圖 4.8 中的 T(i) 函式所算出來的(4.5.1.2 T(i) 函式計算) 。

4.5.1.1 t(i) 函式計算

圖 4.7 t(i)函式運算

圖 4.7 中，由於在計算時間時需要以一個初始值做為基準來進行 frame 順序 的排列，所以我們選取系統上的時間(System Clock，亦稱為 Wall clock)來當作 frame 順序比對及排列的時間基準點(Time Base)。

系統時間經過 t(i)函式的運算後便可得到各個 VOP 的 PTS，其中每一個

I-VOP PTS 的初始值都是 system clock + option(2T) ，而 P-VOP 的 PTS 則是上 一個 frame 的 PTS 加上 133468 uSec = (4*T)，至於 B-VOP 的 PTS 則為上一個 frame 的 PTS 減去 33367 uSec=(1*T) ，其中 T = 1/29.97 Sec 。

4.5.1.2 T(i) 函式計算

圖 4.8 T(i) 函式計算

由上圖 4.7 中我們運算出各個 frame 的 PTS 的值後，由於 PTS 只是為了計算

TimeStamp ， TimeStamp 是一種 Display order，以 Server 來講我們要的是傳送 order。 接下來我們要把 Display order 轉換成 Sending order，至於轉換的機制便 是由圖 4.8 T(i) 函式運算後所得到的。如果是 I/B frame 時我們會將相對應 I/B frame 的 PTS 的值加上 1.6T，如果是 P frame 必須將相對應 P frame 的 PTS 減 去 1.6T，進而得到 DTS 的值 。

4.5.1.3 TimeStamp 用途

TimeStamp 是一個在 RTP 表頭檔中的其中一個欄位的值，如下圖 4.7 所示

，其主要的用途是為了要給用戶端的播放器在接收到 RTP 封包後，可以讓 Client 的播放器知道在哪個時間點可將此封包中的內容播放出來。由於 TimeStamp 是 由 PTS 運算而來，但是封包傳遞的順序卻是按照 DTS，因此會發生 sequence number 比較大的封包，卻會有一個比較小的 TimeStamp。

如果此時某封包因為網路的關係，未能依 Sequence number 的先後順序抵達 用戶端，再加上抵達時間已經超過該封包的播放時間，播放器在讀完 RTP 表頭 的 TimeStamp 欄位後，確定這是一個『過時』的影音封包，便將此封包略過不 做處理。

圖 4.9 RTP header structure

4.5.1.4 TimeStamp 計算方式

瞭解 TimeStamp 的重要性之後，接下來要說明的是 TimeStamp 是怎樣得來 的。TimeStamp 是由 frame Display order (PTS)的值乘上 90kHz(90kHz frequency

rate for Mpeg2)再加上一個亂數值得到的(計算公式如下所示)，因此 TimeStamp 必須透過 frame display order (PTS)的值來設定(PTS 的計算方式敘述於 4.5.1.3 小 節)。

＊

一個亂數起始值

正因為 PTS 的時間順序便是影片播放的順序(IBPBP…，參考圖 4.2)，因此 在經過這一轉換機制後，程式便可以『循序』設定 frame 的播放時間，也就是設 定每個 frame 所屬封包的 TimeStamp；同時搭配 Sequence Number 後，串流用戶 端的播放器便可以先由 Sequence Number 來排定封包播放的順序，其後再依

TimeStamp 於預計的播放時間點將封包內容解碼後播放之。

4.5.1.4 TimeStamp 後續處理

設定完每個 RTP 封包的 TimeStamp 後，我們可以說已經完成了 RTP 封包的

『封裝』過程，也就是我們已經把 payload 加上 RTP header 而成為一個 RTP

packet。但是我們如果直接將這樣的 PTS-frame(IBPBP…)順序經由切割封裝送出 去，用戶端的播放器將無法解碼。

無法解碼的原因是伺服器傳給播放器的 frame 順序必須是 DTS-frame 的順 序，因為解碼需要的順序是 IPBPB…(P-frame 需要 I-frame 的資訊，B-frame 需要 前/後一個 I/P-frame 的資訊才得以解碼)，因此我們有必要將 PTS-frame 的順序再 還原為原來 DTS-frame 的順序，細部的時間 Reverse 過程便不再續述。