Philips HDR 白皮書小註解

根據 WIKI 的記載, HDMI 2.1 的規格來自於 Philips HDR 白皮書 [1]. 雖然這句話簡直不能說是中文: “HDMI 2.0A涵蓋HDR EOTF信令和靜態後設資料後設資料的動態是HDMI 2.1所涵蓋。" 那麼, 我們來看一下白皮書吧!

白皮書認為: 電視或影片大致分為 HDR 和 SDR 兩大類. 我們只需要壓出一種品質的片子, 然後帶一些參數, 就可以在 HDR 或 SDR 的電視上播放!  (白皮書的圖如下)

Philips-White-Paper-768x372

如果一開始就製作出 HDR 品質的片子, 那麼以 HDR 播出一定不會是問題. 至於怎麼產生出 SDR 的版本, 白皮書說這是 colorist 或 artist 要做的工作. 他們根據 frame 或是 scene 的場景轉換, 分別調整出對應的 content-dependent 的 tone mapping 參數. 然後把調好的參數, 根據定價 120 USD 的 SMPTE standard ST 2094-20 [2], 放進 video bit stream 的 SEI ( supplemental enhancement information) [3].  

class SEIToneMappingInfo : public SEI
{
Public:
 PayloadType payloadType() const { return TONE_MAPPING_INFO; }
 SEIToneMappingInfo() {}
 virtual ~SEIToneMappingInfo() {}
 Int m_toneMapId;
 Bool m_toneMapCancelFlag;
 Bool m_toneMapPersistenceFlag;
 Int m_codedDataBitDepth;
 Int m_targetBitDepth;
 Int m_modelId;
 Int m_minValue;
 Int m_maxValue;
 Int m_sigmoidMidpoint;
 Int m_sigmoidWidth;
 std::vector<Int> m_startOfCodedInterval;
 Int m_numPivots;
 std::vector<Int> m_codedPivotValue;
 std::vector<Int> m_targetPivotValue;
 Int m_cameraIsoSpeedIdc;
 Int m_cameraIsoSpeedValue;
 Int m_exposureIndexIdc;
 Int m_exposureIndexValue;
 Bool m_exposureCompensationValueSignFlag;
 Int m_exposureCompensationValueNumerator;
 Int m_exposureCompensationValueDenomIdc;
 Int m_refScreenLuminanceWhite;
 Int m_extendedRangeWhiteLevel;
 Int m_nominalBlackLevelLumaCodeValue;
 Int m_nominalWhiteLevelLumaCodeValue;
 Int m_extendedWhiteLevelLumaCodeValue;
};

至於調整參數時用的電視的 st 2086 規範中的參數, 當然也要放進去. ( The characteristics of the display used for grading or monitoring, such as peak luminance and black level, are added as SMPTE ST 2086 metadata to the video stream. )

另外一個變形是, 傳出 SDR 的 video bit stream, 並且帶上一些參數, decoder 端原則可以解出 SDR 版本, 並且透過計算產生 inverse dynamic range conversion 的 HDR 版本. 這些轉換原理不管壓成  SDR 或是 HDR bit stream 時都是一樣的. 但是為了確保在 decoder 端 (通常是 OTT 或是 STB) 可以把 SDR 再還原出 HDR, 在 encoder 端做 HDR 轉 SDR 的時候, 不能夠用到硬砍的方式 (hard clipping is not allowed).

上述的討論只限於 decoder 和 encoder 之間, 還沒有考慮到 HDMI. 畢竟 HDMI 只傳 raw data, 可想而知那些相關的係數都要透過額外的 HDMI 封包來傳. 在 HDMI 2.0 的時代, 我們通常是傳靜態的 ST 2086 metadata. 至ˊ於動態的部分, 目前 HDMI 的網站 [4] 還沒看到 2.1 的規格, 只看到 2.0b 而已.

[REF]

  1. http://www.flatpanelshd.com/downloads/philips_hdr_white_paper.pdf
  2. http://www.techstreet.com/standards/smpte-st-2094-20-2016?product_id=1922111
  3. https://hevc.hhi.fraunhofer.de/HM-doc/_s_e_i_8h_source.html
  4. http://www.hdmi.org/manufacturer/

MHL 小註解

話說前幾天, 義大2:3輸兄弟的時候寫了 “DVFS 小註解", 這次是義大 6:7 輸統一, 只好來寫個 “CBUS" 轉移心情. 什麼是 CBUS (Communication BUS)呢? 它是 MHL (Mobile High-Definition Link) 裡面的新規格.MHL 的架構如下 [1].因為講到 CBUS 不可能不提 MHL, 所以標題也就順便改了.

實際上, MHL 若不是借了 HDMI 介面的平台, 恐怕也很難攻下一席之地.一個 MHL 的 source 端, 比方說: 手機, 有機會用 micro USB 裡面的 5 根 pin, 接到 HDMI sink 端的 7 根 pin (含 3 根 ground pin)來完成 MHL 的工作.由於 micro USB 和 HDMI 都是常用的介面, 因此 MHL 推廣起來應該省了不少力.它不但能夠把手機小螢幕送上電視這個大螢幕, 還順便解決了手機充電的問題, 真是一個聰明的設計. 

 TMDS (Transition-minimized differential signaling – 最小化傳輸差分訊號)主要用來傳送音視頻的資料. 在 HDMI 的規範中, 我們有 4 個 channel (通道) 可以用. 而在 MHL 裡面, [ref 2,3] 說它只有 3 個邏輯上的通道, 和一個實際上是 3 倍快的通道. 這樣一來, 高速公路比 HDMI 少了一個車道, 怎麼還是能支援到 1080@60P 和 8 聲道的 LPCM 音訊資料呢? 原來在 [1] 當中稱為 MHL 24 bits Mutiplexing, 但是在 MHL Packetpixel Multuplexing 裡面, 它還是 mux 4 個通道.

接下來看一下 VBUS. VBUS (Voltage Bus)負責供電, 在 MHL 2.0 的規格中, 它已經可以用 5V 供應 900mV 的電流. 如果只是純粹供電, 好像學問不大? 看了 Agilent 的資料 [4],需要測試的項目也包括了 VBUS 究竟是否會干擾到 CBUS (Coupling, crosstalk),以及另一端 – 遠端 (Far End)的 MHL 是否會干擾 CBUS 和 VBUS.

至於 CBUS , 顧名思義它是做通訊用的. 當 MHL 的接頭插上 sink 端的 HDMI 端, CBUS 的 1.8V 訊號下拉, 讓 sink 可以偵測到熱插拔 (hot plug). 由於 CBUS 對接到 HDMI 的 pin 19, 這根訊號本來就是做 hot plug detection 用的, 因此和 HDMI 完全相容.

除此之外, CBUS 也兼著從 sink 端讀出 EDID (Extended display identification data – 延伸顯示能力識別). 原本的 EDID 可以從額外的 I2C 介面或是 HDMI 的 DDC 通道 (Display Data Channe – HDMI pin15/DDC clock 和 pin 16/DDC data) 讀取的. 但 MHL 已經把這個訊號線精簡掉, 所以 MHL 只能從 CBUS 上獲取這些資料.同理, CEC (Consumer Electronics Control)也被歸併到 CBUS 上.

總結來說, MHL 做的事和 HDMI 幾乎差不多. 在 VBUS 和 TMDS 的部份, 軟體的人幾乎沒有什麼事情可以做,因此負責 MHL driver 等於負責 CBUS driver.

[ref]

1. New Multimedia Interface MHL: Market Status and Technology

2. Silicon Image提供可攜式產品高清連結(MHL™)技術

3. MHL简介及信号测试方法

4. MHL Test Solution Overview

HDMI / SPDIF 支援頻率與格式

我們的客戶天平公司發了一個 bug 給我們, 大概是說 UI 設成 SPDIF, 同時 HDMI 會沒聲音. 當然裡面原因眾多, system 沒有關掉 SPDIF_HDMI_EXCLUSIVE 是一個, 但是真正的豬頭, ….終於知道就是天平公司自己!

天平公司買了一台ONKYO TX-SR803 的擴大機. 它會把 22.05 KHz 的訊號認成是 32KHz. 以至於 source (我們板子), sink (後面電視) 都在雞同鴨講. 我想會出這個 bug 的原因就是 HDMI 不支援 SPDIF 才有的 22.05 KHz.

這個冷門資訊其實算是有用. 我曾經整理過相關資訊, 發信向美國老闆說明. "HDMI 並沒有通包 SPDIF" . 另外一次是用來發 bug, 表示 SPDIF 少做了幾組 register. 雖然我也可以把 bug 發給美國老闆, 我還是很惡質地把 bug 發給較弱勢的 designer… 久而久之, 那封信被 Outlook 給封存了, 從此以後, 我也再沒有見著它.

為了避免我的人生如吳剛伐桂、薛西佛斯 (Sisyphus) 推石頭 — 老是在做同樣的東西. 我就把它不 confidential 的部分貼出來好了. 至少我知道哪裡有這個資訊.

KHz SPDIF HDMI
22.05 X  
24 X  
32 X X
44.1 X X
48 X X
88.2 X X
96 X X
176.4 X X
192 X X

紅色字的部分, 表示 SPDIF 最初只支援這 3 個頻率, 但現在它早已經不是吳下阿 S 了.

SPDIF burst info HDMI CEA 861 type
X AC-3 2
X MPEG 3
X MP3 4
X MPEG2 Mutli-CH 5
X AAC 6
X DTS 7
X ATRAC 1/2/3 8
X DDP a
  Dolby MAT (TrueHD) c
X WMA Pro e
X MPEG4 – ALS  
X MPEG4 AAC in LATM/LOAS  
X DRA  
  DTS-HD MA b
X MPEG (low sampling rate)  
X MP3 (low sampling rate)  
X MPEG2 Mutli-CH (low sampling rate)  
  One bit Audio 9
  DST d

[note]

2003 年版的 IEC 61937-2, AAC 只包括 MPEG2-AAC

2007 年版的 IEC 61937-2, AAC 只包括 MPEG2-AAC and MPEG4-AAC

[reference]

SPDIF: http://webstore.iec.ch/preview/info_iec61937-2%7Bed2.0%7Den.pdf

HDMI: http://msdn.microsoft.com/en-us/library/dd316761(VS.85).aspx

IEC 61937 Overview

SPDIF 界面的規格, 可以看 IEC 60958-3 的描述. 它是由 Sony 和 Philips 所共同制定的規格, 又稱作 S/PDIF. 主要是用來傳送壓縮後的音訊資料或是解壓縮後的立體聲資料.

如果 SPDIF 上面承載的是壓縮後的音訊資料, 那麼就要參考 IEC 61937. SPDIF 也傳不動的東西, 就要靠新的規格 HDMI 了. HDMI 可以傳送 4 倍 SPDIF 的速度, 相當於每個 sample 16 bits. 以 24 bits 的 LPCM 來說, 16 bits 相當於壓縮 66.7%. TrueHD 和 DTS-HD MA 差不多就是這種壓縮率.

61937 內容
part-1 general
part-2 burst info
part-3 AC-3
part-4 MPEG
part-5 DTS
part-6 AAC
part-7 ATRAC 1/2/3
part-8 WMA
part-9 Dolby MAT (Metadata-enhanced Audio Transimission)
part-10 MPEG4 – ALS
part-11 MPEG4 AAC in LATM/LOAS (streaming)
part-12 DRA

SPDIF 的介紹可以看這個網站: http://www.hardwarebook.info/S/PDIF

HDMI auto lips sync

 

HDMI 的規格裡面有一個 auto lips sync, 以便 HDMI 的 source 或是 repeater 送出符合 repeater 或是 sink 的 AV 訊號. 當這台 sink 的 HDMI device 處理 audio 比 video 快的時候 (通常如此), 希望上游可以晚一點送出 audio 的資料 (raw data 或 PCM), 使得最終在 HDMI sink 上面可以做到視訊、音訊的同步輸出.

至於怎麼做到 auto 呢? 其實對 sink device 是 auto, 但是對 source device 卻不然. 根本就是 source 要做苦工去迎合 sink. Sink 只要大剌剌地把它處理 audio 和 video 的絕對延遲時間, 用 EDID回送給 source 端就好了.

由於 sink 端可能對於解不同的 video/audio format 的速度不同, 因此就算不插拔訊號線, 它還是會穿插地送出不同的 audio latency 與 video latency. 特別是 video 在 progressive mode 和 interlace mode 的速度差了不少, 因此 sink 有時會送出第二組 latency: Interleave audio/vide latency 給 source. 在 source 的 HDMI driver 裡面, 就要依據 max 和 min 的 latency, 去計算 audio 與 video 的 avearge latency.

 

audio 的絕對 delay = (max_latency + 2*min_latency)/3

video 的絕對 delay = (2 * max_latency + min_latency)/3

Audio 的相對 delay = video 的絕對 delay – audio 的絕對 delay 值.

這是因為人類對於 “audio 比 video 快" 比較難容忍, 所以 audio 多 delay 一些比較安全.