lite-youtube-embed

繼續清 tab,在「YouTube embeds are heavy and it’s fixable (frontendmasters.com)」這邊看到的是提出改善 YouTube 的外嵌功能 (embed),因為 loading 太肥了。原文在「YouTube Embeds are Bananas Heavy and it’s Fixable」,裡面提到一個只有 YouTube 的 embed (iframe) 頁面就抓了 1.3MB 的資料:

On a page with literally nothing at all on it other than a YouTube Embed, we’re looking at:

32 requests
1.3 MB of data transfer
2.76s to load the page on my current WiFi connection

而「One YouTube Embed weighs almost 1.2 MB」這邊更提到了這邊的 resource 會線性疊加不會共用的:

The weight also grows linearly with every embed—resources are not shared: two embeds weigh 2.4 MB; three embeds weigh 3.6 MB (you get the idea).

測了一下 https://home.gslin.org/tmp/ytembed.html 這個,是 1.2MB transferred:

如果放兩個一樣的影片,也就是 https://home.gslin.org/tmp/ytembed2.html 的話,變成 2.4MB transferred:

所以不共用的部分的確超大,懷疑 iframe 之間不共用資源是不是跟 cache partition 的實作有關:「Google Chrome 要藉由拆開 HTTP Cache 提昇隱私」。

Anyway,所以作者提案用 lite-youtube-embed 這個套件改善:

Provide videos with a supercharged focus on visual performance. This custom element renders just like the real thing but approximately 224× faster.

不過這種事情你想得到,Google 也一定想得到,全篇只講 lite-youtube-embed 的好處一定哪邊有問題。

所以翻一下 Hacker News 上,在 id=40897582 這邊就有人提到缺點了,很明顯 lite-youtube-embed 的載入速度比較慢:

The author says they don't believe that a lighter version has been shown to reduce engagement.

I, on the other hand, fully believe that.

The recommended lite-youtube-embed project page has a demo of both lite and regular players [0], and the lite version takes noticeably longer to start playing the video.

Every additional millisecond of load time will reduce engagement, and here the difference is more on the order of hundreds of milliseconds or more.

[0] https://paulirish.github.io/lite-youtube-embed/

yeah,這樣就合理了。

即使 embed 吃超多資源,但因為 YouTube 是影音網站,主要的流量還是影音的部分,利用這個方法增加載入速度,在成本結構上面可以接受,而且還可以拿到更多瀏覽資料?

但對於網站端以及使用者端就不是什麼愉快的事情,所以網站端要不要用這個套件就是看各自的取捨了。

冼鏡光教授的「並行計算講堂」

在「Backend 台灣 (Backend Tw)」上看到冼鏡光教授的消息:(3257396121060908)

各位好

密西根理工大學資工系的冼鏡光教授,近期退休後將他的在學校授課時的並行計算(Concurrent Computing)課程、教材逐漸數位化,免費公開、分享給大家使用。

英文版的教材先前已全部製作完畢,近期教授正在努力製作中文版的部分,想讓台灣有興趣的工程師及學生比較不會受到語言的限制。

中文版的教材連結(目前更新至第二集):https://pages.mtu.edu/~shene/VIDEOS/CONCURRENT/index-TW.html

網頁在「【冼鏡光並行計算講堂】」;影片的部分是放到 YouTube 上面,可以參考 @ckshene7212/videos 這邊。

我們這個年代自學的 programmer 或多或少都有看過冼教授的書,不過畢業後看到冼教授的中文消息主要都是在攝影相關的領域,蠻開心可以看到教授退休後回來 CS 貢獻。

另外看了一下 html 頁面的寫法 (職業病?),沒有看到 doctype,大概是 html3 或是 html4 的用法,蠻有可能是教授自己用軟體弄的。

YouTube 頻道先訂閱起來,找時間翻一下影片...

Nvidia 在 Linux 上安裝核心驅動程式時將建議使用開源版本

在「NVIDIA to install open Linux kernel modules by default」這邊看到的新聞,引用的連結是官方的討論區「Unix graphics feature deprecation schedule」這篇。

從 560 開始會議建議使用開源版本:

Starting in the release 560 series, it will be recommended to use the open flavor of NVIDIA Linux Kernel Modules 204 wherever possible (Turing or later GPUs, or Ada or later when using GPU virtualization).

點進去看「Open Linux Kernel Modules」這頁可以看到開源版本有一些專屬功能 (在「The following features will only work with the open kernel modules flavor of the driver」這段),蛋也有一些功能是開源版本沒有的 (在「The following features are not yet supported by the open kernel modules」這段)。

另外 Known Issues 這邊有提到些效能與功耗上的差異。

看起來是 porting 的差不多了?我覺得可以再等一兩個版本 XD

npm 被拿來放影片...

這邊講的 npm 是指 official repository... 在 Lobsters 上看到在 npm 上放 ts 檔的文章:「npm flooded with 748 packages that store movies」,原文在這:「npm flooded with 748 packages that store movies」。

發現問題的是 wlwz 這個 user (不確定什麼時候會不見,不過備份在 Internet ArchiveArchive Today 上都有)。

以列出來的第一個 wlwz-2312-1405 來看,可以從裡面看到十個 ts 檔:

找了一下字串,看起來中國那邊有人認出來是「武林外傳」了 (縮寫剛好就是 wlwz):「npm 被用来保存盗版视频」。

這算是是各種 hosting 需要面對的問題...

1990 年代俄羅斯人用 VHS 帶 (錄影帶) 備份數位資料的方法:ArVid

Hacker News 上看到「ArVid: how Russians squeezed 4 hard drives into one VHS tape in the 90s」這篇,在 1990 年代俄羅斯人發明了用 VHS 帶 (錄影帶) 備份數位資料的方式,這個套件叫做 ArVid

方法是利用家裡已經有的 VHS 機 (錄影機),然後在 386 的電腦上接一張 ISA 介面的卡 (對比現在的電腦環境就是 PCI-e 介面卡),然後把 ISA 卡接到 VHS 機的 Video In (負責備份資料) 與 Video Out (負責取回資料),另外 ISA 卡還有一個紅外線 LED 發射的模組線可以接到 (貼到) VHS 機器的接收處,這樣可以讓 ISA 卡透過「遙控器」的協定控制 VHS 播放器。

這個點子用的媒介其實類似於磁帶機,只是 ArVid 為了使用現成的 VHS 機,多了一個轉換成影像的步驟。

這邊 ArVid 加上了 Hamming code,提供之後讀取時,發現錯誤以及修正的能力。

三個小時的 VHS 帶可以存 2GB 的資料,這個空間大小的感覺拉一下「History of hard disk drives」這頁的資訊,可以感覺一下 1990 年代前期時這樣的東西大概是什麼感覺:

1990 – IBM 0681 "Redwing" – 857 megabytes, twelve 5.25-inch disks. First HDD with PRML Technology (Digital Read Channel with 'partial-response maximum-likelihood' algorithm).

1991 – Areal Technology MD-2060 – 60 megabytes, one 2.5-inch disk platter. First commercial hard drive with platters made from glass.

1991 – IBM 0663 "Corsair" – 1,004 megabytes, eight 3.5-inch disks; first HDD using magnetoresistive heads

1991 – Intégral Peripherals 1820 "Mustang" – 21.4 megabytes, one 1.8-inch disk, first 1.8-inch HDD

1992 – HP Kittyhawk – 20 MB, first 1.3-inch hard-disk drive

是個很有趣的產品啊...

估算 YouTube 影片總量的方式

Hacker News Daily 上看到「How big is YouTube? (ethanzuckerman.com)」這篇,原文在「How Big is YouTube?」。

算是個老問題了,而且應該是統計學上比較簡單的方法。先列出作者最後的成果:「TubeStats」。

作者用的方法是觀察 YouTube 的 vid:

Here’s how this works: YouTube URLs look like this: https://www.youtube.com/ watch?v=vXPJVwwEmiM

可以分析出來 vid 包括了 64-bit 的資訊,這個資料型態對工程師來說,看起來就很像是 uniformly distributed:

That bit after “watch?v=” is an 11 digit string. The first ten digits can be a-z,A-Z,0-9 and _-. The last digit is special, and can only be one of 16 values. Turns out there are 2^64 possible YouTube addresses, an enormous number: 18.4 quintillion. There are lots of YouTube videos, but not that many. Let’s guess for a moment that there are 1 billion YouTube videos – if you picked URLs at random, you’d only get a valid address roughly once every 18.4 billion tries.

然後就是隨機去產生 vid 去掃,這個方法跟 drunk dialing 的行為很像,算是 random sampling 的方式:

We refer to this method as “drunk dialing”, as it’s basically as sophisticated as taking swigs from a bottle of bourbon and mashing digits on a telephone, hoping to find a human being to speak to. Jason found a couple of cheats that makes the method roughly 32,000 times as efficient, meaning our “phone call” connects lots more often. Kevin Zheng wrote a whole bunch of scripts to do the dialing, and over the course of several months, we collected more than 10,000 truly random YouTube videos.

另外在 2011 年就有提出來利用 autocomplete 機制去算:

By comparing our results to other ways of generating lists of YouTube videos, we can declare them “plausibly random” if they generate similar results. Fortunately, one method does – it was discovered by Jia Zhou et. al. in 2011, and it’s far more efficient than our naïve method. (You generate a five character string where one character is a dash – YouTube will autocomplete those URLs and spit out a matching video if one exists.) Kevin now polls YouTube using the “dash method” and uses the results to maintain our dashboard at Tubestats.

目前他們的預估大約是 13B 左右的影片,換算大約是用掉 33.63 bits 了 (233.6):

In our case, our drunk dials tried roughly 32k numbers at the same time, and we got a “hit” every 50,000 times or so. Our current estimate for the size of YouTube is 13.325 billion videos – we are now updating this number every few weeks at tubestats.org.

而這邊提到的 32768 * 50k 會中一次的部分,這邊的大約是 30.61 bits,這樣加起來是差不多 64 bits 沒錯。

不過要注意的是,他們沒有給出 interval,所以 13B 的上下可能是一倍左右的差距 (6.5B~26B 之類的),這邊的數字當作概念比較好...

Netflix 放出了 2023 上半年一萬八千部的播放統計資料

在「What We Watched: A Netflix engagement report (netflix.com)」這邊看到的,Netflix 的文章在「What We Watched: A Netflix Engagement Report」這邊,標題提到的 Excel 報告在 What_We_Watched_A_Netflix_Engagement_Report_2023Jan-Jun.xlsx 這邊。

Hacker News 上的留言 id=38621625 有提到這是 Writers Guild of America 的聯合罷工 (參考英文維基百科的「2023 Writers Guild of America strike」或是中文維基百科「2023年美國編劇協會大罷工」) 所協商出來的成果:

This is an outcome of the WGA strike negotiations. Now writers (and actors, and anyone else) can use this information to better negotiate their worth with studios, rather than it being 1-sided. All other streaming services should be following suit soon.

在「What We Won」這邊可以看到關於 transparency 的部分:

Streaming data transparency: Companies agree to provide the Guild, subject to a confidentiality agreement, the total number of hours streamed, both domestically and internationally, of self-produced high budget streaming programs (e.g., a Netflix original series). Aggregated information can be shared.

打開 Excel 檔可以看到 Netflix 就放出最低限度的資料,但就如同 comment 提到的,這份資料以及足以讓很多人有機會反過來談更好的合約。

另外一方面,也可以預期這份公開資料交叉其他的 metadata 可以分析出一些有趣的東西?

Twitch 宣佈退出韓國市場

Twitch 宣佈 2024/02/27 (星期二) 退出韓國市場:「An Update on Twitch in Korea」。日期不知道是怎麼選的,可能跟某些合約有關?

Twitch 目前的公告會有繁體中文,也可以看這份:「Twitch 韓國現況更新」。

另外今天早上找了一下,Hacker News 也有討論了:「An update on Twitch in Korea (twitch.tv)」。

目前官方給出來的理由是虧本,而且找不到方法克服虧本的問題:

Ultimately, the cost to operate Twitch in Korea is prohibitively expensive and we have spent significant effort working to reduce these costs so that we could find a way for the Twitch business to remain in Korea.

這邊提到的包括了 p2p model 以及降到 720p,但即使如此網路費用 (應該就是頻寬費用) 是其他區域的十倍以上:

First, we experimented with a peer-to-peer model for source quality. Then, we adjusted source quality to a maximum of 720p. While we have lowered costs from these efforts, our network fees in Korea are still 10 times more expensive than in most other countries. Twitch has been operating in Korea at a significant loss, and unfortunately there is no pathway forward for our business to run more sustainably in that country.

Cloudflare 這邊,2016 年還叫做 CloudFlare 的時候也有抱怨過:「CloudFlare 對 HiNet 成本的抱怨 (還有其他 ISP...)」。

當年是這樣寫 HiNetKT,成本大約是歐美區的 15 倍:

Two Asian locations stand out as being especially expensive: Seoul and Taipei. In these markets, with powerful incumbents (Korea Telecom and HiNet), transit costs 15x as much as in Europe or North America, or 150 units.

而尤其是韓國的部分,政府介入讓降價的速度比全世界慢,所以時間拉長後成本相較於其他地區就貴很多:

South Korea is perhaps the only country in the world where bandwidth costs are going up. This may be driven by new regulations from the Ministry of Science, ICT and Future Planning, which mandate the commercial terms of domestic interconnection, based on predetermined “Tiers” of participating networks. This is contrary to the model in most parts of the world, where networks self-regulate, and often peer without settlement. The government even prescribes the rate at which prices should decrease per year (-7.5%), which is significantly slower than the annual drop in unit bandwidth costs elsewhere in the world. We are only able to peer 2% of our traffic in South Korea.

不過不確定現在的情況,2016 年的 CloudFlare 跟 2023 年的 Cloudflare 已經差了七年了...

最近 AV1 的支援度

HN 上「AV1 video codec gains broader hardware support (fullystacked.net)」這篇在說 AV1 的支援度變得更好了,原文不長,在「The AV1 video codec gains broader hardware support」這邊。

Can I Use 上的 AV1 video format 可以看的比較清楚:

不過在瀏覽器上離直接取代掉其他的 video codec 還早,但算是個起頭,至少 iPhone 15 Pro 與 iPhone 15 Pro Max 上的 Safari 支援了,接下來就是看桌機的 Edge 什麼時候才又想到要把 AV1 開回來:

Edge has stopped supporting AV1 completely at some point prior to version 116 (additional information required).

擋 YouTube 短影音的設定

短影音類的影片因為沒有知識量 (沒有 reference 可以確認正確性),我完全不會看... 但 YouTube 上一般的影音我會翻,所以就會冒出這個需求了。

YouTube 的短影音有幾個地方會出現 (補充一下,我這邊是用英文版介面):

  • 首頁的左邊,會有一個 Shorts 的連結可以點進 Shorts 看。
  • 首頁的推薦裡面也會有 Shorts 的 section。

這兩個情況用這兩條擋:

www.youtube.com##a[title="Shorts"]
www.youtube.com##ytd-rich-section-renderer

這邊要注意的是,後者除了擋掉 Shorts 以外,還會擋掉各種 YouTube 的推銷 (像是電影之類的),這個也是我要擋的,所以我這邊直接用了 ytd-rich-section-renderer 這個元素來擋。

再來是各種穿插在頁面裡面的 Shorts 內容,像是首頁、訂閱頁與搜尋結果頁,這些就要找出對應的元素來擋:

www.youtube.com##ytd-reel-shelf-renderer
www.youtube.com##ytd-video-renderer:has(a[href*="/shorts/"])

另外一個跟短影音無關,但還是很影響專注度的是,YouTube 的搜尋結果會給你一堆很干擾結果的推薦,像是「People also watched」、「For you」、「Previously watched」以及「From related searches」,也可以設定擋掉:

www.youtube.com##:matches-path(/results) ytd-shelf-renderer[thumbnail-style]

目前用的差不多是這些...