用 Astrometa DVB-T2 收數位無線電視台 (DVB-T)

以前用的 USB 電視棒壞掉了,去網拍上找了一隻新的來用,翻了一下跟 LinuxTVWiki 上的 Astrometa DVB-T2 這頁的圖片一樣 (2014 版本的圖):

先講一下重點,如果你買到的 USB 電視棒跟我一樣,應該可以看到兩個 source 可以收 DVB-T,而這兩個 source 都可以測試看看,在我家裡測試 Sony CXD2837ER 的收訊明顯好很多:

另外順便一提無關緊要的事情,本來在查資料的時候以為是 2013 的古董版本,但研究了一會兒發現 2013 版的「DVBT2」字比較大,所以不是 2013 版的:

插入到 Ubuntu 的時候可以看到幾個有趣的東西:

[Sat Dec 30 11:59:49 2023] usb 1-6.3: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
[Sat Dec 30 11:59:49 2023] dvbdev: dvb_create_media_entity: media entity 'Realtek RTL2832 (DVB-T)' registered.
[Sat Dec 30 11:59:49 2023] usb 1-6.3: DVB: registering adapter 0 frontend 1 (Sony CXD2837ER DVB-T/T2/C demodulator)...
[Sat Dec 30 11:59:49 2023] dvbdev: dvb_create_media_entity: media entity 'Sony CXD2837ER DVB-T/T2/C demodulator' registered.

意外的發現有兩個支援 DVB-T 的晶片,首先是 Realtek RTL2832 有被抓到,然後被註冊到 /dev/dvb/adapter0/frontend0 這邊。

Realtek 官網上只翻到了 RTL2832U 的資料,裡面比較有趣的是支援了 ISDB-T,不過如果在日本的話還需要 B-CAS 才能解:

Includes ISDB-T(SBTVD-T) 1-Seg

另外 RTL2832U 也支援 FM:

Includes Radio Support (FM/DAB/DAB+)

而第二個的 Sony CXD2837ER 被註冊到 /dev/dvb/adapter0/frontend1 這邊,另外在 LinuxTVWiki 可以看到 CXD2837ER 只被用在了 2018 版本,而且在外觀的部分提到了「or same as 2014 or 2017 revision」,所以看起來手上的版本應該是 2018 版的,但是殼長得跟舊的一樣。

翻了 Sony CXD2837ER 的 datasheet,可以看到支援 DVB-{T2,T,C}:

The Sony CXD2837ER is a combined DVB-T2 (incl.T2-Lite), DVB-T and DVB-C demodulator

看起來是為了 DVB-T2 而放進來的?不過台灣目前還是用 DVB-T 就是了。

Anyway,目前用起來唯一的缺點是看電視的時候同時跑 dvb-fe-tool --femon -f 1 會造成畫面破格,這點要再看看怎麼解決,不過不是大問題...

美國 FTC 提案要阻擋退訂的 Dark Pattern

2021 年的時候寫過「最近很熱鬧的 New York Times 退訂截圖」這篇,在講紐約時報在退訂這塊的 dark pattern,這個方式後來被許多報社的網路服務使用 (像是 WSJ)。

後來加州政府通過法律阻擋這樣的 dark pattern,所以就有 Reddit 上面這樣的討論,教大家直接把 billing address 改到加州後就可以網路上退訂:「WSJ Subscription policy makes it easy to subscribe (online), but hard to unsubscribe (via phone).」。

現在看起來 FTC 打算推動變成全國性的法案,而且不只是網路服務,也包括了像是健身房與第四台的服務都必須提供對稱的方法 (訂閱與退訂):「The FTC wants to ban those tough-to-cancel gym and cable subscriptions」。

來繼續追進度,看看什麼時候通過...

用軟體降低電視背光老化現象產生的不平均

前幾天在 Hacker News Daily 上看到「TV backlight compensation (2020) (lofibucket.com)」這個,原文是 2020 年的文章「TV backlight compensation」,作者拿到一台不用錢的電視機,但這台電視機的背光已經老化了,發光亮度不平均,大概是這樣的情況:

把電視機的背光問題當作是一個函數 f(x),然後把翻拍產生的亮度差當作是 g(x),目標是要找出 f(x) 的反函數 f-1(x):

然後從作者的程式碼與解釋可以看出來不是針對每個 pixel 都單獨調整,而是全部套用同一個公式,然後目標是針對黑白畫面去調整:

The whole point of this exercise was to make black-and-white movies look better.

透過軟體的修正可以得到下面這樣的結果,其中左上角是原圖,右上角是這張圖在電視上翻拍出來的樣子;左下角是運算後修正的圖,右下角是這張修正後的圖在電視上翻拍出來的樣子;可以看到修正後的不平均感少了一些:

作者是把這個修正掛到 MPC-BE 上面,但 Hacker News 上面有人提到也可以實做 Gnome 的版本,直接讓整個 OS 都可以套用:「Hello1024/gse-shader」。

有點拼但還蠻有趣的東西 XD

透過 DNS 擋 Smart TV 的廣告

Hacker News Daily 上看到「Smart-TV Blocklist for Pi-hole」這個,給 Pi-hole 吃的 blocklist,可以拿來擋 Smart TV 抓一堆廣告亂搞,另外很多自己刷的 WRT 也都支援這個格式,不一定要自己弄 Pi-hole,像是我家裡的 AdvancedTomato 也有支援:

本來馬上想到的是 AdGuard 提供的 DNS 94.140.14.14,結果掃了一下發現都沒有擋掉,難怪會需要另外自己搞...

另外一個想到的搞法是 NextDNS,但 IPv4 的部份要固定 IP 才有辦法 (像是 HiNet 提供的 PPPoE 固一),免費版的 quota 拿來掛 Smart TV 應該夠用...

Hacker News 上的討論在「Smart-TV blocklist for Pi-Hole (perflyst.github.io)」這邊,這年頭要弄台不連網的電視機愈來愈難了...

新世紀福音戰士的字型

沒想到在 Hacker News 首頁上看到第一名居然是這個連結:

2019 年的文章:「Neon Genesis Evangelion」,找資料的時候發現有簡體中文版的翻譯:「末世感叩击:《新世纪福音战士》的文字世界」。

這些字型是由日本的 Fontworks 所開發出來的 Matisse EB,在片尾的 credit 也可以看到「株式会社フォントワークスジャパン」:

主要是沒想到會在 Hacker News 首頁上的第一名看到這個...

Smart TV 與遊戲主機的 DNS 經常是設死的

Hacker News Daily 上看到「Your Smart TV is probably ignoring your PiHole」,裡面提到了很多遊戲主機並不會依照從 DHCP 拿到的 DNS 設定使用,而是直接設死:

Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

裡面提到的論文是「Characterizing Smart Home IoT Traffic in the Wild」這篇,裡面分析了不同種類的裝置 DNS 的狀況,以及 HTTP/HTTPS 的比率:

回到原來的文章,裡面提到了用 NAT 的方式把 1.1.1.1 的 TCP/UDP Port 53 導到 Pi-hole 上面過濾,這樣看起來還行,下面的 DNS over TLSDNS over HTTPS 因為走其他特定的 TCP port,應該是不受影響...

AWS Elemental MediaConvert 支援 AV1

在「2020/03/17 - AWS Elemental MediaConvert - 11 updated api methods」這邊看到的:

AWS Elemental MediaConvert SDK has added support for: AV1 encoding in File Group MP4, DASH and CMAF DASH outputs; PCM/WAV audio output in MPEG2-TS containers; and Opus audio in Webm inputs.

翻了一下同個站台的總表「AWS Elemental MediaConvert」這頁,看起來是第一次支援 AV1 輸出,這對於很在意頻寬的應用方便不少,另外翻了一下 Can I Use 這邊的資料「AV1 video format」,看起來也已經有不少環境可以用 AV1 了 (又看到 Safari,真不愧是 2020 年的 IE6):

另外可以參考「Netflix Now Streaming AV1 on Android」這篇,Netflix 在今年稍早的時候也決定在 Android 平台上採用 AV1。

用 Machine Learning 改善 Streaming 品質的服務與論文

Hacker News 上看到「Puffer」這個服務,裡面利用了 machine learning algorithm 動態調整 bitrate,以提昇傳輸品質。

測試得到的數據後來被整理起來一起放進論文:「Continual learning improves Internet video streaming」。

在開頭介紹了 Fugu 這個演算法:

We describe Fugu, a continual learning algorithm for bitrate selection in streaming video.

而 Puffer 就是實驗網站:

We evaluate Fugu with Puffer, a public website we built that streams live TV using Fugu and existing algorithms. Over a nine-day period in January 2019, Puffer streamed 8,131 hours of video to 3,719 unique users.

這個站台提供了許多真實的頻道進行測試:

Stream live TV in your browser. There's no charge. You can watch U.S. TV stations affiliated with the NBC, CBS, ABC, PBS, FOX, and Univision networks.

可以看到 Fugu 的結果很好,比起其他提出的方案是全面性的改善:

這邊是用 WebSocket 測試,並且配合了不同的 TCP congestion algorithm,沒有太考慮額外的計算成本...

用 NN 演算法重製 Full HD 版的 Star Trek: DS9

看到「Remastering Star Trek: Deep Space Nine With Machine Learning」這篇,裡面用了類神經網路演算法,將本來只有 480p (SD) 的 Star Trek: DS9 升到 1080p (Full HD) 的版本,而且看起來效果還不錯...

意外的看到有人拿 Star Trek 的材料來玩... 依照作者的說明,DS9 一直沒有 Full HD 版的其中一個原因反而是因為「數位化」了。使用類比膠卷的母帶可以透過更高規格的重新掃描而得到高畫質版本,但 DS9 的母帶似乎已經是數位版了,所以反而造成無法透過重新掃描的方式取得 Full HD 版本:

While you can rescan analog film at a higher resolution, video is digital and can't be rescanned. This makes it much costlier to remaster this TV show, which is one of the reasons why it hasn't happened.

現有的 upscale 技術主要都還是以圖片為主,所以作者本來以為對於動態畫面的處理會遇到問題,但蠻意外的超出預期,從影片可以看出來:

看起來之後的 remaster 版本有可能可以靠這個方法先做初步,然後再讓人進去修?

Twitch 用 VP9 直播...

Twitch 整理了一篇「How VP9 delivers value for Twitch’s esports live streaming」,說明他們用 VP9 的經驗談。

裡面有很大的篇幅是在講 VP9 與 H.264 的比較,不過這兩個用的技術就已經不是同一個年代了,沒有進步的話就不用出來玩了...

裡面有講到一些有趣的東西,像是提到是用 FPGA 即時壓縮:

In this article, we will show that the FPGA-based real-time VP9 encoding can deliver at least 25% bitrate savings compared to the highest-quality H.264 encoders deployed in Twitch’s production today.

然後提到 1080p60 至少省了 25% 的頻寬 (這邊應該是相較於 H.264):

VP9’s Compression Efficiency for Live 1080p60 Encoding: We Can Achieve At Least 25% Bitrate Savings

查了一下,在桌機上的瀏覽器都差不多支援了:

VP9 is implemented in these web browsers:

Chromium and Google Chrome (usable by default since version 29 from May and August 2013, respectively),
Opera (since version 15 from July 2013),
Mozilla Firefox (since version 28 from March 2014),
Microsoft Edge (as of summer 2016).

行動裝置的話 Android 4.4+ 有支援,但在 iOS 上沒有支援...

整體看起來普及率算是不低,可以引入當主力 codec 降低頻寬成本,當設備不支援 VP9 時 (應該只有 iOS 透過 Safari 觀看的情況) 就用 H.264 stream 提供服務。