分類: 技術

本網站修繕小註解

因為 WordPress 一直抱怨 PHP v5.6 太老舊又不安全, 我只好破釜沉舟把網站進版. 原本只想換 PHP 就好, 但是看著一些網路教學去做, Apache 還是開不起來, 我又沒有本事 debug. 只好重新裝一個 Xampp. 這樣是能開得起來, 毛病還能一個一個修就是了.

以下紀錄比較重要的步驟, 絕對不是 copy paste 就可以搞定的. 尤其是新的 Xampp 還是用 PHP V8, 本身就跟 V7 有點小衝突.

  1. 將原來的 htdocs 底下的檔案 copy 出來. 這是為了 plugin 和 gallery 的需要. 當然 plugin 都可以重裝, 我要保存的是圖檔.
  2. 以 WordPress 控制台 –> 工具 –> 匯出程式, 將網站備份. 等效做法是從 phpmyadmin 裡面匯出 WordPress 的 sql. 要注意的是 php.ini 預設的 值很小, 我的網站已經很肥了. 所以要改成:
    post_max_size=128M
    upload_max_filesize= 256M
  3. 重新找一個 Xampp 架站, 以 phpmyadmin 開一個 WordPress 資料庫. 當然別忘了幫自己開帳號和權限. 
  4. 安裝 wordpress import 的 plugin (系統在 import 時也會提示). 
  5. 把舊的網站的 ssl key copy 到新的網站 (假設網站 URL 沒變).
  6. 把舊 plugin 和 ngg 目錄都 copy 到新網站.
  7. 安裝 ngg (gallery) 的 plugin in, 不然匯入時會報太多錯誤,
  8. 匯入舊網站的 xml.
  9. 因為新 xampp 的 PHP 是 v8.0, 要去 php.ini 把 extension=gd2 改為 gd. [1] 
  10. 到 ngg 的 plugin 去 scan gallery 目錄下的影像檔.
  11. ngg 已經不支援 shortcode 了, 也就是 slideshow=1 這種, 用新的 UI 插入 ngg 媒體. 到處冒出的 warning 就會消失.
  12. 有些文章剩下一半, 我以為是 php.ini 給的 post size 或是 upload size 太小, 或是 time out 太短? 不過更重要的是 import 文章進來後, 被主動加了一些註解. “<!–[CDATA[" 和 “]]>" 之類的. 這些要到 phpmyadmin 選 wordpress, 然後選搜尋 –> 取代. 把這些東西用空白代換掉, 隱藏的文章就會出來. 但我還沒有辦法處理消失的表格和段落間距. my_sql-620x200
  13. Zbench 這個主題有相容性問題, isHome 這個變數沒有初值, 在 functions.php 裡面, 大約 126 行的地方, 我直接 $isHome = ‘ class="current_page_item"‘;
  14. 預設字體很小, 這個要選外觀 –> 佈景主題檔案編輯器, 然後選 “系統內建的 CSS 編輯器", 把一些設定加到 “自訂項目".my-css
  15. 在 pHpMyadmin 中企圖刪除不需要的 root 帳號, 不知為何突然發生 #1034 的故障, 看了 Youtube 影片才修好. 有好幾片都是類似的. 可參考[2].
  16. 解決 #1034 後, 不再想刪 root, 而是把 phpMyadmin 裡面不需要密碼的 root 帳號都改成需要密碼, 然後我就被踢出去了. 看了[3] 才回想起進去的方法.
  17. 把phpMyAdmin 目錄底下加個 .htaccess 也可以卡住讓人無法使用 phpMyAdmin.

[note]

  1. https://lindevs.com/gd-extension-has-been-renamed-on-windows-in-php-8-0/

[2] How to Resolve error “1034 – index for Db is Corrupt in MYSQL" | Repaire MYSQL tables with xampp – YouTube

[3] 如何設定XAMPP修改phpMyAdmin的MySQL密碼 – ucamc

QMS, VRR, NFR 小整理

Netflix 花了一些功夫在影片播放的品質上, 力抗有片源但是 UI 和翻譯還不到位的 Disney+. 以 … 繼續閱讀「QMS, VRR, NFR 小整理」

Netflix 花了一些功夫在影片播放的品質上, 力抗有片源但是 UI 和翻譯還不到位的 Disney+. 以前我聽到的都是 “content 為王", 不知道有獨門 content 但介面比較陽春的那家未來會不會勝出? 先說到 Netflix 在 NRDP  先後推出 NFR (Native Frame Rate), VRR (Variable Refresh Rate), QMS (Quick Media Switching). 在此整理一下它們的差異.

NFR 要求先固定選擇 50 or 60Hz, 這個依據電視的規格是 PAL 或 NTSC 制而定. 實際上的值也可能是有頻篇的 49.95 或 59.94Hz, 然後以這個值做為上限. 以下假設輸出就是預設 60Hz.
Netflix 開 NFR 目的是切換片源時 frame rate 不要重設 (免得 reset HDMI 畫面會閃黑), 所以即使 NFR = flase, 會以軟體外插 source 的頻率到 60 Hz 播出. 假設 NFR = true 呢? 此時就會以最接近 60 Hz 但不超過 60 Hz 的倍數播放, 以 24Hz 為例, 就是 mapping 到 48Hz. 當然若 HDMI RX 不支援 48Hz, 就不在 frame rate map 裡面, 還是得輸出 60 Hz.

但 VRR 就不一樣了 (一開始我會跟 RISC-V 的 RVV 搞混), VRR 會讓 HDMI 的輸出與輸入完全同步. 這個功能對玩遊戲最有幫助, 因為遊戲的 frame rate 本來就是忽快忽慢, 明明很靜態的時候, 每秒外插個 120、144 張有點浪費電. 只要 HDMI 輸入端 (如電視) 知道遊戲機的幀率, 那麼快慢變化就不是問題了, 當然也不需要黑屏重置.

這招對播電影來說是大材小用, 不過 Netflix 也要做遊戲了, 所以 NRDP 要求未來要有 VRR 也是剛好而已.

至於 QMS, 也是避免切換幀率中的黑屏. 或曰, 都有 VRR 了, 何必有 QMS. QMS 的重點不在於單一 HDMI 的內容如何改變幀率, 而在於電視切不同 HDMI 輸入, 在遇到不同幀率變化時也不黑屏. 對 HDMI TX 來說, 這件事很單純. 比較要花功夫的應該是 HDMI RX 吧.
HDMI-feature-2022-01-03-105317-768x446
上圖擷取自 [1]
[REF]

  1. HDMI 2.1 規格發表

DAC 小註解

講到 DAC, 最先浮現腦海的一定是 digital analog converter. 然而, 偏偏就是有人 … 繼續閱讀「DAC 小註解」

講到 DAC, 最先浮現腦海的一定是 digital analog converter. 然而, 偏偏就是有人喜歡把自己的東西命名為更慣用的名詞, 藉以拉抬知名度. 此處的 DAC 是指 downloadable application container. 也就是可下載的 container.
關鍵字 container 的宗旨在於把應用程式封裝在一個容器中, 於是它幾乎不受外在環境設定的影響. 比方說 docker [2]. 當然徒 container 不足以自行, 先要 porting 好一個內應, 也就是 docker engine. 接著才能承上啟下.
docker-768x662
至於 DAC 則是 Comcast, Sky, Liberty Global, Metrological (已併入 Comcast) and Consult Red 所開發的一套 container 系統. 除了 Consult Red 是僅存的軟體服務公司, 其他都變成運營商了 – 也就是對應台灣的凱擘, 中華電信. 下圖右上角這塊 app store 的雲端, 左上角是 APP SDK, 下方是接受 APP 的 device, 像是 STB, 或者電信業名詞叫 CPE.
dac-768x842
下載的 APP 為何能動? 在這裡的共通介面就是 OCI (Open Container Initiative ) [3]. 一套 OCI Image 被下載時, 會在雲端被打包為 OCI bundle. 通常只是壓縮, 但也可以被加密. Pull 到 CPE 後由 DAC installer (packager) 打包成 OCIContainer.
OCI 中除了 OCI Image 外, 另外一個角色是 OCI runtime. 它的用途在於安裝 container 到特定 file system 上, 它也放在 OCI bundle 的裡面. 實做方式有 Crun 和 Runc 兩種. 看官您覺得這命名鬧不鬧? 兩種方式各有支持者, Runc 是 RDK 聯盟採用的版本, 優點是體積小.
OCI-768x239
OCI define both a runtime specification and an image specification. The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. The OCI image is used for packaging containers in a platform-agnostic way that can be easily distributed. At a high-level, an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.
當然在 RDK 環境, APP 還是會由 RDK shell 控管. RDK shell 也管第一章流程圖左邊的 thunder container, 但這不在主題中先跳過. 其他還沒解釋到的剩下 Dobby [4].
Dobby 是哈利波特裡面的家庭小精靈. Well,.. RDK 聯盟的人有一票是冰與火之歌的劇迷, 所以新技術的名字都取自劇中的大陸, 例如 Westeros, ESSOS, …etc. 幸好 Dobby 是 Sky 的技術, 英國人當然要支援國貨.
Dobby 不是 container, 而是 container management 的 daemon. 它用來管理 container 的 lifecycle (start, stop, …etc.), 它的附加功能 (plugins) 還包括這些:

  • Advanced container networking support with NAT and both IPv4 and IPv6 support. Allows for easily adding iptables rules to allow/prevent traffic flow in and out of container
  • GPU memory limiting (providing the kernel has the appropriate support)
  • Container log management to either files or directly to journald
  • Loopback storage mounts to add persistent, isolated storage to containers
  • IPC support between containers/host by allowing access to the host dbus inside containers

[Note]

  1. https://wiki.rdkcentral.com/pages/viewpage.action?pageId=113967683
  2. https://www.docker.com/resources/what-container
  3. Open Container Initiative 
  4. https://wiki.rdkcentral.com/display/ASP/Dobby

ATSC A/85 中的 DialNorm 和 DRC

客戶又有新的 audio 專家來開會了, 只好考前猜題準備一下相關背景知識.

首先是整體音量的方面, 這裡有一篇中文的介紹非常棒 [3]. 看了以後對 audio normalization 會有基本的了解. 計算音量的方式有 A-weight (acoustic) 和 K-weight (單純對頻域 weighting), 把整片每個聲道掃完就會得到平均音量 [6]. ITU-R BS.1770 的公式 (2) 給了一個測量 loudness 方法 [6], 它的另外一個主題是測 True Peak.

接下來專注討論人聲的部分, 在 objective audio 的時代, 據說聲音該大聲就大聲, 該小聲就小聲, 但人聲必須是正常而且受到規範的 (CALM) [7]. CALM 言明要規範的是 perceived loudness, 然後又說 “Perceived loudness compliance is based on Dialog
Normalization – dialnorm. Dialnorm is defined in ATSC A/85″, 所以 DialNorm = Perceived loudness. 

DialNorm 是一個 metadata. 它的值介於 0~31, 也就是 -30~0dB 的音量 [1], 其中 0 是 reserved. DialNorm = 1 => 0dB, DialNorm = 31 => -30dB.  DialNorm = 12 表示很大聲, DialNom = 27 表示溫和 (soft). [2]

ATSC A/85 對 DialNorm 的規範是 -24 LKFS (想成 dB 就好) [4], 並且允許大約 ± 2dB 的量測誤差. 在 AC3 的碼流中會帶著這個 metadata, 而這裡的 0dB 是片源允許的最大音量. 我們可以透過調整電視音量, 讓電視的輸出的人聲落在 DialNorm 的上下區間 (comfort zone) [5].

根據 A/85.  電視節目製作人應該要保證他們的輸出都有適當的 DialNorm 控制, 包括所有片源都固定一個 DialNorm (fixed), 或者對每部片子預設一個值 (preset), 或者是可以從外部動態取得 (agile). 至於插片或是廣告的音量, 當然也要受到管制, 這也是 A/85 的目的. (This ATSC Recommended Practice (RP) provides guidance…to effectively control program-to-interstitial loudness.) 但 program-to-interstitial 的音量變化經常都是亂源. 

A/85 還講到 DRC (Dynamic Range Control) 有開關是為了要達到 reversible, 不然動態範圍壓下去就無法復原了. 在 P.26 提到: The AC-3 DRC system should not be relied upon to control program-to-interstitial loudness variations. 表示 DRC 也管不了廣告. 在 9.1.3 (P.29) 提到, DialNorm 是反映整部片子音量的準則, 所謂太大聲大小聲要拉起來壓下去, 都是依據 DialNorm 做判斷標準.

然後 9.1.4 解釋了 Dolby MS12 (密) 文件中沒有解釋的 profile, 幸好在公開的文件中就有講. AC3 定義了五種 profile, MS12 多一種 null profile. 但 9.1.5 有講到 DRC = “none", 也就是沒有 DRC 開關的選項.

• Music Light
• Music Standard
• Film Light
• Film Standard
• Speech

基本上這五種 profile 都跟 DialNorm 有關, 因為 Music 沒有對白, Speech 全部都是對白, 所以不同 profile 就代表不同的 DRC 調整. Light 跟不 light 的區別在於, light 版有比較多的 null area, 所以調的地方比較少. 

(The “Light” versions of the profiles have a much wider null area. Thus, gain reduction or expansion begins farther away from average program audio, resulting in less gain reduction or expansion than with the “Standard” version of the profile.) 

這也解釋了 [3] 裡面提到, Youtube 大約是 -13 LUFS, 而 Spotify 是 -14 LUFS (LHFS = LKFA). Youtube 基本上是 movie, Spotify 基本是 music. 如果對 Speech profile 開 DRC, 理論上會造成失真. 因為它已經全部都是人聲了, 壓了應該會破壞朗誦效果, 哈!

DRC 又可以分為有 metadata 和沒有 metadata. 有 metadata 就是前面講的這些, 沒有 metadata 的就像是 AGC (automatic gain control). 因為沒有 metadata, 所以是 irreversible.

[REF]

  1. https://en.wikipedia.org/wiki/Dialnorm
  2. https://www.atsc.org/wp-content/uploads/2015/03/Techniques-for-establishing-and-maintaining-audio-loudness-1.pdf
  3. 有關Audio normalization兩三事
  4. loudness, K-weighted, relative to full scale, measured with equipment that implements
    the algorithm specified by BS.1770. A unit of LKFS is equivalent to a decibel.
  5. Comfort Zone – the Comfort Zone is a range ( +2.4dB, -5.4dB) of the change to audio loudness that was found to be acceptable to a sample of listeners. The 0 dB point on the Comfort Zone scale is the average Target Loudness value or dialnorm of the channel.
  6. https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-4-201510-I!!PDF-E.pdf
  7. https://www.ensembledesigns.com/file_download/640/Ensemble_CALM_wp.pdf

災防告警廣播小註解

這篇的主題很難取, 因為可以用的名字太多了. 因為 COVID-19,  大家學到了細胞簡訊, 細胞廣播 [8], 類細胞簡訊等名詞, 它們都是用來傳遞重大災害的警示等等, 若搞不清他們的差異可以參考這篇 [1].

我主要想整理的是客戶可能需要的規格.

名詞 全名 Note
EAS [2] Emergency Alert Signaling radio and broadcast
WEA [9] Wireless Emergency Alerts wireless providers

EAS 是美國聯邦通信委員會 (FCC) [5] 所核准用的, 它的前前身和前身紀錄如下表. 最早用在國防用途, 後來轉為民生避難考量. 不意外最早只有廣播電台和電視需要支援.

名詞 全名 使用時間
EAS Emergency Alert Signaling 1997~now
EBS [6] or EANS Emergency Broadcast System
Emergency Action Notification System		 1963~1997
CONELRAD [7]   1951~1963

但是有了手機和網路之後, 防守的範圍就更廣了. 美國人依然喜歡改朝換代. WEA 也是格式的名稱, 所以此廣播的正式名稱應該是 CMAS.

名詞 全名 使用時間
WEA Emergency Broadcast System ~now
CMAS Commercial Mobile Alert System = WEA
PLAN Personal Localized Alerting Network  before

每個國家隊細胞廣播 (cell broadcast) [8] 的命名當然也不一樣. 不勝枚舉. 

名詞 全名 地區
EMA [3] Emergency Mobile Alerts 紐西蘭
WEA Wireless Emergency Alerts 美國
NL-Alert Netherlands Alert 荷蘭
EU-Alert EU Alert 歐盟

再來回頭講細胞廣播的格式. CAP [4] 是由 OASIS 所推出, 採 XML-based 的描述, 現在是 ITU-T X.3103 的標準. WEA 則是  Alliance for Telecommunications Industry Solutions (ATIS) 和 Telecommunications Industry Association (TIA) 所定的新規格, 特色包括能夠指定播放的區域. 多語言, 限時, 延時等等.

  • Flexible geographic targeting by using latitude/longitude “boxes” and other geospatial representations in three dimensions
  • Multilingual and multi-audience messaging
  • Phased and delayed effective times and expirations
  • Enhanced message update and cancellation features
  • Template support for framing complete and effective warning messages
  • Digital encryption and signature capability
  • Facility for digital images, audio, and video.
名詞 全名 Note
CAP Common Alerting Protocol 許多國家, 包括台灣
WEA Emergency Broadcast System 美國

[Note]

  1. https://www.bnext.com.tw/article/57390/what-is-pwc-warning-system
  2. https://en.wikipedia.org/wiki/Emergency_Alert_System
  3. https://en.wikipedia.org/wiki/Emergency_Mobile_Alert
  4. https://en.wikipedia.org/wiki/Common_Alerting_Protocol
  5. https://en.wikipedia.org/wiki/Federal_Communications_Commission
  6. https://en.wikipedia.org/wiki/Emergency_Broadcast_System
  7. https://en.wikipedia.org/wiki/CONELRAD
  8. https://en.wikipedia.org/wiki/Cell_Broadcast
  9. https://en.wikipedia.org/wiki/Wireless_Emergency_Alerts