Pre-arbitration 小辭典

Bus 的 arbitration 通常是指把 bus 的控制權交給哪一個發出需求的 device, 沒拿到控制權的 request 就要排隊.

而 arbitration 就像高速公路的匝道管制, pre-arbitration 就像是匝道的燈號. 當燈號在紅燈的時候, 任何車輛都不准再上高速公路了. 反之, 綠燈的時候, 就依照優先權 (載客量) 或是先到先行 (按排隊順序) 來決定誰先通行.

當一次綠燈過後 (arbitration), 燈號會出現一個特定數字 (pre-arbitration count). 比方說停在 3, 那麼載客 3 人以下的車輛就可以上高速公路. 若是出現了 60, 那麼載客 60 人大客車和 9 人以下小客車都有機會開上來. 至於匝道裡 (command buffer) 的那麼多輛車 (request), 誰可以開上高速公路呢? 就是還是由 arbitratior 決定. 

為何要對高速高路做這樣的管制呢? 因為在系統裡面, 有些 request 可能是 real-time 的, 不管它載客量大還是小, priority 都很高. 因此我們會希望只要看見這些車開上匝道, 就給他們先上路的機會. 因此何時開綠燈就很有學問了.

Pre-arbitration 管制了綠燈開起的時間. 當 pre-arbitration count 的值設到最大, 服務就會最好, 民怨最低. 不過即使救護車可能都一時上不了路. 當這個值設到最小, 就是等於直接綠燈跳紅燈. 每次重新篩選誰可以上路之後, 才把綠燈開給它.

24P 與 pull down

由於 HDMI 的 video 需要設定輸出格式, 在考慮畫質最佳化的時候, 就必須要處理 24P 的問題.

24P 的影片來自電影, 每秒播放 24 張 progressive 的畫面. 而傳統的隔行掃瞄電視的畫質不如電影, 多是 NTSC 或是 PAL 的 interleave 輸出, 因此需要使用 pull down 技術將 24P 塞進 29.997 frame/sec (約 60 field/sec) 或是 25 frame / sec (50 field/sec).

對於 NTSC 來說, 24P –> 60I (I = interleave) 相當於 2 frames 變成 5 個 fields. 也就是第一個 frame 變成 2 個 fields, 第二個 frame 變成 3 個 fields 即可. 此為 3:2 pull down (telecine pull down, 或是更能反映真實狀況的 2:3 pull down).

(24 / 2) * 2 + (24 / 2) * 3 = 60

對於 NTSC 來說, 24P –> 50I (I = interlaev) 相當於 2 frames 變成 4.167 個的 fields. 取其近似值, 可以將第一個 frame 變成 2 個 fields, 第二個 frame 變成 2 個 fields 即可. 此為 2:2 pull down.

(24 / 2) * 2 + (24 / 2) * 2 = 48

因為是採用近似值的關係, 平均播放速度增加為 50/48 = 104.167%, 速度會變快. 若是聲音的輸出頻率與 video 連動, 則聲音 pitch 也會變高一點點. 若聲音的輸出頻率沒有與 video 連動, 則 video 播完了, audio 還沒有播完. 因此, 另外一種可行方式就是 video 每 50 張 frame 再多補 2 張進去. 這樣就可以讓 audio、video 脫鉤.

對於新的逐行掃瞄電視而言, 畢竟 24P 和 60P/50P 也不是整數倍的關係. 所以 pull down 的過程仍然存在.

總結來說, 早期的電視技術並不發達, 所以制定的 interleave 規格以現在的眼光來看, 是比較落後的. 隨著電視進入 120 Hz 的境界, 電影的 24P 技術又顯得不夠看. 從藍光 DVD 播出的訊號, 仍然要經過 pull down 轉換到逐行掃描電視是一種額外損失. 因此, 透過 HDMI 介面的告知, 電視也直接支援 24P 的輸入, 的確是比較明智的做法.

當然電影拍攝技術也會往 48P 邁進, 大家都在進步. 身為 display 關鍵角色的 TV, 理當去支援各種 native (未經再處理的) 輸入才是王道.

RTSP MMS HTTP RTMP 小檔案

RTSP = real time streaming protocol: 當初是由 RealNetworks 和 Netscape 共同提出, 主要是支援 streaming 功能. Streaming 讓 Realplayer 可以播出媒體, 但是沒辦法存起來.

MMS = Microsoft Media Server: 顯然這是微軟所提出的, 用於取代 RTSP. Windows Media Player 可以透過這個協議, 播出某個 URL 上面的媒體. 2008 年就會廢棄這個協議.

HTTP = hyper text transfer protocol: 其實這不是一個 real time protocol. 當 client 向 server 發出需求, server 就一股腦地向 client 送出整個媒體. 一旦中間受到某些因素而中斷, 整個傳輸就要重來一次. 

RTMP = Real Time Messaging Protocol: 這是 Adobe 專用的格式, 主要用於 flash media server 將 flash 的媒體送到 client 上.

參考 WIKI 的  OSI Protocol
5-7. 應用層 (包括應用層, 表示層, 會話層)
DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTSP · TLS · SDP · SOAP · GTP · STUN · NTP · MMS · RTMP
4. 傳輸層
TCP · UDP · DCCP · SCTP · RTP · RSVP · PPTP
3. 網路層
IP (IPv4 · IPv6) · ARP · RARP · ICMP · ICMPv6 · IGMP · RIP · OSPF · BGP · IS-IS · IPsec
2. 資料鏈結層
802.11 · 802.16 · Wi-Fi · WiMAX ·ATM · DTM · Token Ring · Ethernet · FDDI · Frame Relay · GPRS · EVDO · HSPA · HDLC · PPP · L2TP · ISDN 
1. 實體層
乙太網路實體層 · PLC · SONET/SDH · G.709 · 光纖 · 同軸電纜 · 雙絞線
 

再探 Youtube 技術

現在已經有 Panasonic 的電視可以支援 Youtube 了! 雖然美國朋友說比較紅的已經變成 Hulu, 不過美國境外的人暫時還看不到 Hulu 網站, 所以我們還是先搞懂 Youtube.

Youtube 的網站有幾個地方值得探討:

Q1. Video/Audio 壓縮格式

Q2. 可否下載?

Q3. 未來發展

A1. 關於第一個問題:

Youtube 支援的格式為:

Platform Container Video Audio
PC SWF/FLV FLV1=Sorenson MP3
覆蓋式廣告(480×70)
影片內廣告(320×250)
SWF (Shockwave Flash) + FLA    
手機  3GP  H263 AMR 

手機 Youtube 資料來源: http://www.thinknext.net/archives/tag/youtube#

 

A2. Youtube 使用 streaming 串流技術, 基本上不希望大家下載.

然而, 還是有網站和工具協助大家下載這些影片:

http://blog.roodo.com/jojos/archives/3434155.html

下載之後, 還有很多轉檔工具.

http://download.longtermly.com/category/internet-tools/youtube-tools/

如果 user 端可以支援 streaming 的話 (也就是採用 RTP、RTSP 網路協議), 當然可以藉著 Youtube 的網址, 播出正確的內容. 當然, 若實際上不支援 SWF, 就要 hack 到檔案正確的位置, 透過 HTTP 網路協議, 將整個檔案 (FLV) 拿來解.

Youtube 為了防範大家找到 FLV 真正的位置, 會在 streaming URL 與 file storage URL 之間改變對應關係. 也就是說, 如果大家乖乖 streaming, 那個 URL 是不會變的. 但是如果想要 download 的話, 就要找出兩者對應的規則.

通常這個規則也很簡單. 引用啾啾的部落格的文字:

舉例來說如果我想下載此影片:
原網址:
http://www.youtube.com/watch?v=IncztAzMsck

將「watch?v=」換成「v/」後貼到瀏覽器上
http://www.youtube.com/v/IncztAzMsck
網址將會變成
http://www.youtube.com/p.swf?video_id=IncztAzMsck&eurl=&iurl=http…

再把「p.swf?」改成「get_video.php?」變成
http://www.youtube.com/get_video.php?video_id=IncztAzMsck&eurl=&i…

之後就可以直接下載影片了,記得要加上 .flv 副檔名,這就是直接下載的方法.

A3. 關於第三個問題, 因為 SWF 已經是 Adobe 的資產. 在 Adobe 的藍圖之中, 未來會用 H.264 和 AAC 來當作 Adobe SWF/FLV decoder 的音視頻格式.

也有一種說法是, Youtube 其實已經悄悄地在提供 SWF 9 的輸出. 使用 popcorn hour 這台機器連上 Youtube 就會看到畫質較佳的 streaming quality.這一點未經證實.

如果連結到其他 Youtube like 的網站, 它的 video 可能是 VP6. 主要是 flash player 的版本不同. 詳見下表:

version container video 格式
6 SWF/FLV TrueMotion VP6 (H.263-like)(audio = NellyMoser)
7 SWF/FLV Screen video bitstream
format = lossless
 8 SWF/FLV TrueMotion VP6 (H.263-like)
9 SWF/FLV H.264
10 SWF/FLV 多了 3D effect, audio mixing 等功能

RAID 小檔案

因為日本的可錄影電視 (Toshiba) 已經支援 RAID 5 了, 所以逼得我再複習一下 RAID (磁碟陣列). 台灣的喬鼎資訊 (promise) 就是做 RAID 的佼佼者, 有興趣的人也可以去 wiki 了解 RAID. 我只將 RAID 0~10 的摘要整理如下, 隨時複習.

RAID 描述 補充
0 將多顆硬碟模擬成一顆 (stripping) 無冗餘, 2~N 顆硬碟適用 
1 將資料複製一份鏡像 (mirror), 放在兩顆磁碟當中 2~N 顆硬碟適用.
2 將資料做 ECC (error correction code) 編碼後 , 放在 N 顆磁碟裡 改良 Raid 0 的安全性, 3~N 顆硬碟適用
3 將資料分散放在 N 顆磁碟 (bit interleave), 單獨拿一顆做 parity check 3~N 顆硬碟適用
4 將資料分散放在 N 顆磁碟 (block interleave), 單獨拿一顆做 parity check 3~N 顆硬碟適用
5 把 parity check 的功能分散到各顆磁碟, 當然除了自己本身之外. 兼具 Raid 0 和 Raid 1 的優點, 3~N 顆硬碟適用, 一次只能壞掉一顆硬碟.
6 把 parity check 的功能分散到各顆磁碟, 當然除了自己之外. 理論上有兩套 parity 可做到這個能力. 4~N 顆硬碟適用, 可以允許同時壞掉兩顆硬碟. 這兩顆是指: 當一顆壞掉, 正在修復它的時候, 另外一顆又壞了.
10 Raid 1 + Raid 0, 又分散又有鏡像 4~N 顆硬碟適用, 必須為偶數顆硬碟.

網路上的說明, 以http://en.wikipedia.org/wiki/RAID 較好, 也有圖示. 可惜是英文的.