分類: 技術

杜比的反擊 – DDCO

話說 DTS 出了號稱 backward-compatible 的 DTS-HD 之後, 就避掉了與老舊擴大機之間相容性的問題. 在次世代音效爭霸戰中, 佔有一定的優勢. 不過, Dolby 也不是省油的燈, 它推出一個優惠方案 DMA (digital media adapter) 來彌補相容性的不足.

Audio format 與擴大機不相容, 改誰好呢? 當然是改播放機好. 播放機前面收到 TrueHD, DDP, 解完之後壓成 Dolby Digital (AC3) 再送給擴大機解碼, 這樣不就可以滿足客戶 SPDIF raw out 的虛榮心了嗎?  這種疊床架屋的架構就叫做 DDCO (Dolby Digital Compatible Output).

當然, 如果客戶的眼睛是雪亮的, 他們應該要要求高清播放機和擴大機整合成一台, 而不是讓播放機和擴大機互相遷就對方. 所以 Dolby 這個方案也只是過渡性質的.等到擴大機漸漸都進步到 HD audio 之後, 它就可以真正地輸出無損的訊號給擴大機.

其中, TrueHD (或者它的前身 MLP) 因為是 VBR (variable bit rate), 所以還需要 encode 成 MAT (Metadata-Enhanced Audio Transmission) 格式, 才是符合 HDMI (high definition multimedia interface) 輸出的 CBR (constant bit rate) 碼流.

 

 

HEAC in HDMI 1.4

搞 IT 業最大的不好就是名詞超多, 為了避免問了又忘, 查了還忘, 這篇用來解釋 HEAC 是什麼?

HEAC 全名 HDMI Ethernet & Audio return Channel, 本來每個都知道, 但合起來就變成新名詞了. 簡單地說 HEAC = HEC (HDMI Ethernet Channel) + ARC (Audio Return Channel).

大家可以去查厘科 (Litek) 的介紹, 裡面講得很好.

本來比較廉價的 category 1 HDMI cable (74.25 MHz) 和比較高級的 category 2 cable (340 MHz) 又多了支援與不支援 HEAC  的差別, 故日後買 HDMI cable 時若看到價差很大, 應該不用覺得驚訝. 雖然 pin 腳同樣維持 19 pin, 不過 pin 14 和 pin 19 的定義已經有所不同了, 分別變成 HEAC+ 和 HEAC-.

SVG vs. Canvas

眾所周知地, Flash 是一個 loading 很重的繪圖插件, 那麼在瀏覽器裡面內建的繪圖方式又是什麼呢? 大概就是 SVG 或是 Canvas 這樣的東西吧!

SVG (Scalable Vector Graphics), 顧名思義, 它是與影像解析度無關的向量繪圖. 它嚴格遵循 XML 的語法, 所以可以放在 XML 裡面. ".SVG" 是一個可操控的文字檔, 功能有點像是 Flash 的 ".swf'". 在 SVG 檔之中, 可以用 ECMAScript  (Javascript 的一種) 或是 SMIL (Synchronized Multimedia Integration Language) 指令來控制 SVG 的物件, 讓它產生動畫的效果. 而它的又支援文字索引 (index), 方便於根據內容來搜尋所需要的圖檔.

相對於 W3C 所推廣的 SVG 開放標準, Apple 有另外一套 Canvas 相容於 HTML5, 並使用 Javascript 來控制動畫. 包括較早期的 Mozilla, FireFox, 後來的 Opera, Chrome. 甚至於即將出台的 IE9, 也在 2010/6/23 把 HTML5 和 Canvas 加進測試版, 取代(?) 過去所支持的 VML. 在打手眾多的情況下, 看來 Canvas 會比起 SVG 更有明星架勢.


[ref]

1.  SVG 摘要與範例

2.  Canvas 簡單範例

SAMBA vs. CIFS

SAMBA (SMB – Server Message Block) 是一個讓 Windows 系統存取 Linux 檔案系統的 protocol, 鳥哥對此有很好的介紹. 他也提到, CIFS (Common Internet File System) 和 NFS (Network File System) 只在 Windows 或 Unix 裡面互通. 原文說:

不過，NFS 僅能讓 Unix 機器溝通， CIFS 只能讓 Windows 機器溝通。傷腦筋，那麼有沒有讓 Windows 與 Unix-Like 這兩個不同的平台相互分享檔案資料的檔案系統呢？

果真這樣的話, 那麼來推銷 CIFS IP 的廠商不就是來亂的嗎?也不是, 中間有個演變的過程.

根據歷史, 1991 年先有 SMB 之後, Microsoft 到 1996 年才仿效 SMB 發展出 CIFS 與之匹敵, 放在 Windows NT 裡面. 到了 2006 年推出 Vista 的時候, Microsoft 乾脆就把新的 CIFS 命名為 SMB 2, 頗有雀巢鳩佔的味道. 到了 Windows 7 的時代, 微軟繼續地推出了 SMB 2.1 版, 老實不客氣地搶坐了正統的大位. (Java、Java script 的故事也差不多).

所以今天的 SAMBA 已經是 SMB + CIFS 的綜合體, 這裡有一篇說明. CIFS 代表比較新, 相容性比較好, 解決了 unicode, access control lists, aggressive cacheing, 2/4GB transfer bug 等問題 . 不過若是舊電腦連不上去的話, 請回到老 SAMBA 吧! 

此外, 原始的 SMB 要從 GPL 2.0 升級到 3.0 了. 如果要避免 open source, 可以考慮搬家到 CIFS.CIFS 由 SNIA (Storage Networking Industry Association) 所維護, 理論上可以看著 CIFS 的 technology Reference 自己 implement. 但是其中用到的技術, 要向原始的 owner, reasonable and non-discriminatory (合理而無差別) 地取得授權. 此外, 真正握有技術的 Microsoft 把 CIFS 的規格弄得含糊不清, 因此產生了賣 CIFS IP 的軟體生意出來.

看來看去, 網路上這篇介紹得最好: SMB: The Server Message Block Protocol

其中的這句話寫得更是傳神: Like NetBIOS, the Server Message Block protocol originated a long time ago at IBM. Microsoft embraced it, extended it, and in 1996 gave it a marketing upgrade by renaming it "CIFS".希望有一天我的文章也可以寫得這麼精煉.

UDP/TCP/IP/MTU 小註解

我們部門本來是做多媒體的, 可是多媒體不是從網路上拿來, 就是有可能再傳到網路上, 所以我們也愈來愈像是在做網路了.

在網路上傳送多媒體, 如果是即時的應用, 就會使用 UDP (user datagram protocol). 一個 UDP 封包最小是 8 bytes (只有 8 bytes header), 最大是 65535 bytes (64KB, 包括 8 byte header). 它的長相如下:

bits 0-15 16-31
0 Source Port Number Destination Port Number
32 Length Checksum
64 data

 

Checksum 的部分相當神奇, 根據 IP v4 或是 IP v6 的不同, 它還要想像它前面還有 IP header, 一起做 checksum. 因為想像中的 IP header 並不在 UDP 的協議中, 所以那個想像中的 header 就叫做偽頭 (pseudo header). 顯然地, IP v6 的偽頭比 IP v4 要來得大! 如果不要那麼麻煩去算 checksum, 填 0 也可以, 那就表示 "我沒算 checksum".

如果加上 IP 層的頭, overhead 又多了 20 bytes. 所以原來號稱最大可以傳 65535 bytes, 減去 UDP header 8 bytes 和 IP header 20 bytes, 就剩下 65507 bytes.

bit offset 0-3 4-7 8-15 16-18 19-31
0 Version Header length Differentiated Services Total Length
32 Identification Flags Fragment Offset
64 Time to Live Protocol Header Checksum
96 Source Address
128 Destination Address
160 Options ( if Header Length > 5 )
160 or 192+ UDP, TCP (for example)

 

如果是 TCP 的話, 用來取代 UDP 那個位置. 不過 TCP 光是 header 就有 20 bytes 以上, 幾乎和 IP v4 header 等量齊觀.

MTU (Maximum transmission unit) 又是啥呢? 無論我們選了 UDP 或是 TCP, 對傳輸系統來說, 都是 IP 的封包. MTU 就是能夠傳送最大封包的 size. 比方說 IPv4 建議值是 576 bytes, IPv6 建議值是 1280 bytes.  最大的狀況大概是 Ethernet Jumbo frame 的 9000 bytes, 基本上都不會太大, 連 10 KBytes 都不到.

當然, MTU 設得愈大, 系統就要等更多的 data 才能發送, 造成資料的延遲. 如果 MTU 設得很大, 對 TCP 或許是有意義的, 但是對於 UDP 就有點不知所云了. 畢竟即時和延遲是對立的關係.

[ref]

1. http://en.wikipedia.org/wiki/User_Datagram_Protocol

2. http://en.wikipedia.org/wiki/Maximum_transmission_unit

3. http://en.wikipedia.org/wiki/IPv4

4. http://www.docin.com/p-47138983.html