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/

我讀 «證券分析» 第六版 – 損益表 4

第 35 章特別著重於公用事業的折舊; 當然, 免不了又要舉例有多少公司都沒做到好好折舊這件事! 但公用事業為什麼特別值得一題呢? 主要是這個行業 (電力、燃氣、照明…等等) 需要一直更新設備, 折舊下來的金額也都會拿去買新的設備, 所以方便於從除舊、佈新兩個角度來思考.

本書也將折舊的方法分為兩大類裡面的七小類. A 類著眼於除舊, B 類著眼於佈新.

A.  常規折舊法

  1. 直線法: 即每年減記相等的折舊費用, 直到剩下殘值.
  2. 償債基金法: 未折舊完的費用, 理論上應該產生利息. 因此前幾年扣減金額較少, 隱含現在的錢比未來的錢 “大", 後面要依一定的利率增大折舊數字.
  3. 整體法: 並不針對特定的財產折舊, 而是對整個資產做一定比例的折舊.

B. 資產清理專項儲備方法

     這類方式不在於考慮資產的損耗、毀壞或是廢棄. 而是考慮重置. 若公司需要買更多的資產, 提列的費用就會變多. 反之, 雖然先前買了很多設備, 未來有一段時間不會再買了, 就不必提列未來的重置費用.

  1. 依毛利率的某個百分比提列.
  2. 依產出產的數量提列固定比率.
  3. 為維修以及折舊整體提列毛利率的百分比. 和 B-1不同的地方在於, 損壞愈多提列愈多.
  4. 酌情扣減.  這就是以公司經營階層的自由心證來提列.

有個有趣的地方在於, 公司會採取兩套不同的會計策略. 在計算所得稅的時候, 幾乎每家公司都是採用直線法, 讓公司少繳一點稅. 但是到了計算盈餘的時候, 卻會從採用另外一套策略, 讓公司顯得賺錢. P.551 說到: “對於這種差異的存在, 投資者普遍不知情."

作者觀察了數十家公用事業類公司的折舊提列帳戶 (p. 552~p. 557), 並得出折舊數字和毛利率、所得稅率有大概的關係. 例如: 1938 年, 底特律愛迪生公司提列毛利率的 13.5% 當作折舊, 而所得稅是毛利率的 18.2%. 北美公司的數字分別是 12.8% 和 14.8%. 所以, 本書推出一個比較嚴格的標準, 一家公用事業公司繳多少所得稅, 就大致每年就應該折舊多少錢!

當然, 這樣的觀察在財報更加公開透明之後已經不適用了. 但我們仍然可以用同業的折舊比列互相比較, 畢竟同業的稅率總是比較接近.

 

我讀 «證券分析» 第六版 – 損益表 3

在本書的 34, 35 章主要討論折舊, 34 章著重於折舊對獲利的影響, 35 章討論公用事業的折舊政策.

固定資產減少的原因不只是折舊、更新、報廢, 物品的耗損、耗盡, 租賃物、許可權的攤銷, 以及專利權的攤銷等等都可以列在折舊這個項目之下, 統稱為折舊.

表面上看似簡單的折舊, 其實有更深一層的面貌: 1. 允許以價值而非成本來攤銷. 2. 公司可以利用各種會計準則規避折舊. 3. 某些折舊的計算方式完全不符合現實狀況. 以下分段說明之.

有一種理論認為, 折舊不是將已經買進來的物品分好幾個年份來記帳, 而是為了下一次的購買儲備金錢, 也就是把折舊當作 “重置成本". 因此重置成本不會受到當初購買的價格、或是現在市場上中古貨的價格變動. 這樣思考似乎也沒有錯, 但老是重估資產, 將會直接影響到損益表. 而以當初的成本來折舊, 就不會變來變去.

畢竟買資產的錢早就花出去了. 把現有資產估得愈便宜, 則每年折舊的費用就會愈低, 公司看起來的獲利就會愈好.  1931 年 Hall Printing Company 的做法是把資產重估後, 多出的 6.222 M USD 列入資本公積的貸方 (賺錢), 但是它應有的折舊卻不是從損益表中扣除, 而是減少資本公積. 換言之, 公司的資產大增小減後還是變多, 獲利不受影響. 但重置成本的增加卻視而不見了.

因此本書主張資產重估要以事實為基礎、並且從損益表中扣除額外的獲利 (Proper depreciation against these new values is charged in the income account.)

p.525~p.529 舉了一些例子, 讓我們可以比較兩家煉糖公司、兩家鑄造公司的折舊/資產百分比, 折舊多的一方提列 4.79% 和 3.66%; 較少的一方卻只有 1.73% 和 1.65%. 作者認為提列少的那兩家折舊和同業相比並不充足. 如果上述的兩家煉糖公司或是鑄造公司要同業合併, 不同的折舊策略勢必影響公司真正的價值與換股的比例.

除了惡意製造虛假獲利, 也有提列折舊費用過高的例子 (p. 531). 如果能買到這樣的公司的股票, 就等於挖到寶了.

P.532 講石油公司和礦業公司的推銷費用…等等, 為何是推銷? 剛剛不是正在講折舊嗎? 查了原文是 “AMORTIZATION CHARGES OF OIL AND MINING COMPANIES" , 喔, 原來是攤銷, 本書難得出現錯字. 這倉頡輸入嗎? 哈!

對挖礦公司來說, 挖挖挖…挖到礦山逐漸枯竭了, 這就是一種資產的折舊. 對石油公司來說, 鑽井的過程並沒有半點產出, 而突然挖到油的那一年, 如果不攤提先前的耗損 (depletion), 財報將會過於漂亮而失真. 因此先前的所有隱藏成本都應該要資本化, 然後每年攤銷. 包括還沒攤提完就報廢的機具, 不應該只是從折舊中抹除, 而是要列入損益表.

講完了一般人部會接觸到的損耗, 接下來講其他類型的資本資產攤銷 (又印錯一次). 比方說 7-11 今天租了個三角間開店, 花錢做了標準小七應有的改裝. 但房子租約到期後, 什麼都帶不走, 這種裝潢開支 – 建築物改良就要列入折舊. 像是專利權這種會到期的資產, 也應該比照辦理. 商譽的攤提, 作者說相對不重要, 很少人這樣做.

因為篇幅有點長, 35 章留待下次再寫.

foreign-architecture 小註解

今天想要用 apt-get, 結果冒出 Unable to locate package git-fame

cashchou@server: ~ $ sudo apt-get install git-fame
Reading package lists… Done
Building dependency tree
Reading state information… Done
E: Unable to locate package git-fame

為了消除  Unable to locate package, 據說要清理 source list, 很多人是因為網路的關係連不上 ubuntu, 但我確定都連得上, 所以不用改 source list. 而是可以試著 update. 結果在 apt-get update 的時候, 看到一堆類似的 warning. 像是:

W: Failed to fetch http://tw.archive.ubuntu.com/ubuntu/dists/precise-updates/InRelease Unable to find expected entry ‘ main/binary-foreign-architecture/Packages’ in Release file (Wrong sources.list entry or malformed file)

之類的東西. 話說 main 和 Packages 中間應該是出現 architecture 沒錯, 但應該是 amd64, i386 這種 architecture, 而不是直接來個 foreign architecture 吧! 

cashchou@server: /etc/apt $ dpkg –print-architecture
amd64
cashchou@server: /etc/apt $ dpkg –print-foreign-architectures
foreign-architecture

這表示我們 server 的架構是 amd64, 如果曾不小心打成 and64, 或是 i586 打成 1586…這些都會被認為是不相容的外國建築 (foreign-architectures) . 但…這 server 上的外國建築竟然就叫做外國建築吶! 我試著把它刪除, 結果…得到一句繞口令…不能移除不是外國建築的外國建築.

cashchou@server: /etc/apt $ dpkg –remove-architecture foreign-architectures
dpkg: warning: cannot remove non-foreign architecture ‘foreign-architectures’

原來是我忘了 sudo, 加 sudo 硬是把它幹掉之後, apt-get update 就正常了.

sudo dpkg –remove-architecture foreign-architecture

但還是不能 upgrade.

cashchou@server: /etc/apt $ sudo apt-get upgrade
Reading package lists… Done
Building dependency tree
Reading state information… Done
You might want to run ‘apt-get -f install’ to correct these.
The following packages have unmet dependencies: …一大堆錯誤

據說, 此時可以試著 apt-get -f install, 但我試過這招沒用. 因為 unmet 太多了.

…一大堆錯誤
E: Unmet dependencies. Try using -f.

啊 force 也沒用啊!! 根據網路資訊 [1], 接下來的 SOP 就是先自動修復, 依序執行下面幾步. 當然 // 後面不是指令, 只是註解.

sudo apt-get update      // update your package list
sudo apt-get autoclean   // clean up any partial packages
sudo apt-get clean       // clean up the apt cache
sudo apt-get autoremove  // will clean up any unneeded dependencies.

還不行的話, 只好逐個修復. 

sudo dpkg --remove -force --force-remove-reinstreq package name

弟兄們裝了太多 package, 彼此互相影響, 我沒時間一個一個重裝, 只好留待比較急的人有緣人來處理了~~~

[REF]

  1. http://www.linuxquestions.org/questions/linux-general-1/resolve-generated-breaks-held-packages-896449/

NSAID 小註解

如果直接 Google “NSAID", 將會得到一大串 nonsteroidal anti-inflammatory drug (非類固醇抗發炎藥物) [1] 的搜尋結果, 不過我想要整理的是 Non-Secure Access ID.

根據 [2], 在 ARM 的 trusted media protection platform 當中, 有個 TZASC (Trusted Zone Address Space Controller) 400 把 SOC 的本體和 DDR 隔開來, DDR memory controller (DMC) 接在它和 DDR memory 之間. 因此, 那些 IP 可以存取哪一塊記憶體就會受到管制.

TEEnNSAID

至於圖中那些不同顏色的 IP, 代表處在不同等級的保護. 在 TEE 的字典裡, 最不安全的是 rich domain 例如 APP 們; 再來是 protected domain, 例如 virtual machine. 比較安全的是 trusted domain, 像是 TEE 的 TA (trusted Application); 最安全的是 secure domain, 例如獨立的硬體. 

那些黃色的 IP, 屬於 protected world. 例如 audio, video, HDMI (稱為 master) 有時候可能不需要嚴格保護, 所以他們有個 non-secure 的 access ID, 告訴 TZC 說我要合法存取我自己的那塊記憶體. 至於不合法的存取, 在 TZC 會被過濾掉 – 針對 ID 過濾, 或是只能讀或寫.

另外, 圖中的 GPU 是白色, 這只是舉例. GPU 也可以支援 protected world. ARM 有部分 GPU 可以從外部電路將它切到 protect mode, 另外有一些新型號 GPU 的 protect mode 是內建的.

[REF]

  1. 非類固醇消炎止痛藥- 維基百科，自由的百科全書 – Wikipedia
  2. http://www.iaik.tugraz.at/content/about_iaik/events/ETISS_INTRUST_2013/ETISS/slides/GPTEE_Public.pdf