幹壞事是進步最大的原動力
在翻資料的時候翻到「Google Releases AOM-AV1 3.5 With More Speedups & Memory Optimizations」這篇，講 AOM-AV1 v3.5.0 的效能改善，看了 v3.4.0 的 changelog 可以看到最主要的大幫助是有 multithreading 的支援，但不確定跟其他的 AV1 library 相比可以有多快...
印象中 (好幾個月前的印象) 目前最快的應該是 SVT-AV1？記得 dav1d 有宣稱很快但不是 apple-to-apple 比較，比較像是 marketing 上的宣稱。
先前測試 AV1 在 Android 上的支援度與效能，記得在老一點的手機上軟解還是很辛苦啊，最後還是先選了 VP9 用，硬體解碼支援度比較廣，加上軟解需要的 CPU resource 也低不少。
Hacker News 首頁上看到「US Government Bans Export of Nvidia A100 and H100 GPUs to China and Russia (sec.gov)」這篇，是 NVIDIA 發出了 Form 8-K，說明美國政府禁止 A100 與 H100 或是更高階 (更快) 的卡以及產品輸出到中國 (包括香港) 與俄羅斯：「nvda-20220826.htm」。
先是指出 A100、H100 以及 A100X (Ampere) 被管制：
On August 26, 2022, the U.S. government, or USG, informed NVIDIA Corporation, or the Company, that the USG has imposed a new license requirement, effective immediately, for any future export to China (including Hong Kong) and Russia of the Company’s A100 and forthcoming H100 integrated circuits. DGX or any other systems which incorporate A100 or H100 integrated circuits and the A100X are also covered by the new license requirement.
另外是禁止新產品的部份，效能與 A100 相等或是更好的卡也被禁止輸出，除非有取得授權：
The license requirement also includes any future NVIDIA integrated circuit achieving both peak performance and chip-to-chip I/O performance equal to or greater than thresholds that are roughly equivalent to the A100, as well as any system that includes those circuits.
然後有提到軍事相關考量：
A license is required to export technology to support or develop covered products. The USG indicated that the new license requirement will address the risk that the covered products may be used in, or diverted to, a ‘military end use’ or ‘military end user’ in China and Russia. The Company does not sell products to customers in Russia.
有看到一些報導指出 AMD 也有收到類似的禁令 (畢竟也是個顯卡大廠)，但在「SEC Filings」這邊沒看到...
在 Hacker News 首頁上看到「To uncover a deepfake video call, ask the caller to turn sideways (metaphysic.ai)」這篇，講怎麼在 video call 的時候辨認是不是 deepfake 的人。原文在「To Uncover a Deepfake Video Call, Ask the Caller to Turn Sideways」這邊可以讀到。
文章裡面介紹一個很簡單的方式，就是轉頭拍側面，會看到明顯的缺陷：
這張 GIF 會更明顯：
Hacker News 上的討論也有人提到這是目前的技術限制，所以這個方法算是有效的。但以現在各類 machine learning 成長的速度來看，可能沒多久後就會有新技術突破這個方法了。
在「Varnish Software Achieves 500Gbps Throughput Per Server for UHD Video Content」這邊看到 PR 稿，由 Intel 與 Varnish 合作，宣稱達到單機 500Gbps 的 throughput 了：
According to Varnish Software, the following were the outcomes of the test:
- 509.7 Gbps live-linear throughput, using a dual-processor configuration
- 487.2 Gbps video-on-demand throughput, using a dual-processor configuration
白皮書在「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」這頁可以用個資交換下載，不過用搜尋引擎找一下可以發現 Intel 那邊有放出 PDF (但不確定兩邊給的是不是同一份)：「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」。
單 CPU 的伺服器是四個 100Gbps 界面接出來，雙 CPU 的伺服器是八個 (這邊 SUT 是 system under test 的縮寫)：
These client systems were connected to the CDN servers using 100 GbE links through a switch; 4x100 GbE connections for the single-processor SUT, and 8x100 GbE for the dualprocessor SUT. Testing was done using Wrk, a widely recognized open-source HTTP(S) benchmarking tool.
不過如果實際看圖會發現伺服器是兩個 100Gbps (單 CPU) 與四個 100Gbps (雙 CPU)，然後 wrk 也吃了兩個或是四個 100Gbps：
在白皮書最後面也有提到測試的配置，都是在 Ubuntu 20.04 上面跑，單 CPU 用的是兩張 Intel 的 100Gbps 網卡，雙 CPU 的用的是四張 Mellanox 的 100Gbps 網卡：
3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Single processor SUT configuration was based on the Supermicro SMC 110P-WTR-TNR single socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by two 100 GbE Intel® Ethernet Network Adapters E810. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 8 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80 generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnishplus-6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.
3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Dual processor SUT configuration was based on the Supermicro SMC 22OU-TNR dual socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by four 100 GbE Mellanox MCX516A-CDAT adapters. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 12 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80- generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnish-plus6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.
不過馬上就會滿頭問號，四張 100Gbps 是怎麼跑到 500Gbps 的頻寬...
這份 PR 馬上就讓人想到 Netflix 先前放出來的投影片 (先前有在「Netflix 在單機服務 400Gbps 的影音流量」這篇提到)，在 Netflix 的投影片裡面有提到他們在 Intel 平台上面受限於記憶體的頻寬，整台機器只能跑到 230Gbps。
另外一種猜測是，如果 Intel 與 Varnish 宣稱的 500Gbps 是算 switch 上的總流量 (有這樣算的嗎，你是 Juniper 嗎...)，那這邊的 500Gbps 換算回去差不多就是減半 (還很客氣的沒把 cache 沒中需要去 origin server 拉資料的流量扣掉)，跟 Netflix 在 FreeBSD 上跑出來的結果差不多啊...
坐等反駁 XDDD
看到 Amazon EC2 推出新機種 vt1，專門為影片壓縮而推出的 family type：「New – Amazon EC2 VT1 Instances for Live Multi-stream Video Transcoding」。
主要是透過 Alveo U30 Data Center Accelerator Card 這張卡加速，號稱比 GPU 機器還要省 30% 的費用 (CPU 的話可以到 60%)：
These VT1 instances feature Xilinx® Alveo™ U30 media accelerator transcoding cards with accelerated H.264/AVC and H.265/HEVC codecs and provide up to 30% better price per stream compared to the latest GPU-based EC2 instances and up to 60% better price per stream compared to the latest CPU-based EC2 instances.
看規格支援 H.264 與 H.265，不過看起來沒支援 royalty-free 的 VP9 與 AV1...
另外這跟 AWS Elemental MediaConvert 以及 AWS Elemental Live 好像稍微有點打對台？另外專利的費用不知道怎麼算...
Work from home 期間開會基本上就是幾個視訊軟體換來換去，Zoom 的話公司有買，自己開免費版的時候是 40mins 限制，另外 Slack 的畫面品質不怎麼樣，而 Google Meet 在疫情期間不限制時間，拿來聊天還蠻好用的。
看到「TLS support for Google Meet」這篇，文章裡面提到先前 Google Meet 是用 443/udp 跑 SRTP，這對很多公司的 firewall 需要另外開 (看到這個 UDP port 想到 QUIC 好像也是走這個 UDP port)，在家裡的話應該還好，對於公司的電腦就會麻煩一些。
文章裡提到，這次支援了 TLS (over 443/tcp)：
Some network setups do not work with SRTP over 443 which was preventing Meet calls from connecting. Meet now encapsulates SRTP in TLS which increases overall compatibility. This change will initially be available on the web, and will be available for mobile soon. We’ll announce it on the Google Workspace Updates blog when it’s available.
可以 fallback 回 443/tcp 走 TLS 的話穿透力應該就更好了，不過不知道免費版的有沒有也一起上，這邊只題到了 G Suite 系列會上：
Available to all Google Workspace customers, as well as G Suite Basic and Business customers
上次用 Google Meet 是在雲端聚餐聊天...
Twitter 上看到 jkgtw 提到 Lbry/Odysee 的速度快很多：
最近 lbry / odysee 在台灣看的速度突然變超快！雖然還不像 Youtube 那樣一點就看，但是也相差不遠了，真讚～ 👍 https://t.co/W5qGZsJsck
— Stephen (@jkgtw) March 12, 2021
看了一下資料，HiNet 到 cdn.lbryplayer.xyz 的 latency 增加了，但是 packet loss 改善了不少，看起來是把本來導去新加坡的流量改導去美國：
另外走 APOL 的 cable 這邊也有類似的情況，可以看出導去美國了：
測了一下影片觀看速度，1.5x 可以看，2x 還是放不太動，的確是比以前好不少。
Apple 推出了從 iCloud 的內容複製到 Google Photos 上的服務：「Apple Launches Service for Transferring iCloud Photos and Videos to Google Photos」。
我登入進去 iCloud 沒看到，後來才看到：
Apple's transfer service is available to customers in Australia, Canada, the European Union, Iceland, Liechtenstein, New Zealand, Norway, Switzerland, the United Kingdom, and the United States at this time.
服務的區域主要是歐洲北美紐西蘭，台灣暫時還沒辦法用，只能先看一下 screenshot 了：
既然是 Google Photos，能搬過去的就只有 Google Photos 有支援的類型，包括了大部分的圖片與影片格式：
Smart Albums, Live Photos, photo stream content, some metadata, and some RAW photos are not able to be transferred, but formats including .jpg, .png, .webp, .gif, some RAW files, .mpg, .mod, .mmv, .tod, .wmv, .asf, .avi, .divx, .mov, .m4v, .3gp, .3g2, .mp4, .m2t, .m2ts, .mts, and .mkv are compatible.
不知道推出這個功能後面的意義是什麼...
Hacker News Daily 上看到「Lyra audio codec enables high-quality voice calls at 3 kbps bitrate」，講 Google 新推出的 Lyra audio codec：「Lyra: A New Very Low-Bitrate Codec for Speech Compression」，論文在「Generative Speech Coding with Predictive Variance Regularization」這邊可以抓到。
目前 Google 提出來的想法是想辦法在 56kbps 的頻寬下實現還堪用的視訊通話：
Pairing Lyra with new video compression technologies, like AV1, will allow video chats to take place, even for users connecting to the internet via a 56kbps dial-in modem.
這次的突破在於可以使用 3kbps 的頻寬傳輸，但清晰度比 Opus 的 6kbps 效果還好不少。
Google 在文章裡面給了兩個 sample，一個是乾淨背景音，另外一個是吵雜的背景音，跟 Opus 與 Speex 比起來都好很多。
論文是說不需要太高的運算力，但沒翻到 GitHub 之類的 source code，先當作參考：
We provide extensive subjective performance evaluations that show that our system based on generative modeling provides state-of-the-art coding performance at 3 kb/s for real-world speech signals at reasonable computational complexity.