Meta 將 AV1 導入即時通訊規模部署
Meta Engineering · 2026-06-22
原本的問題
Meta 在 Messenger 與 WhatsApp 的視訊通話中長期使用 H.264/AVC，但在低頻寬環境（10–400 kbps）下畫質難以維持。開源 AV1 編碼器的初始功耗比 H.264 高出 14%，直接導入對中低階裝置不可行。Android 裝置碎片化嚴重，無法以記憶體或出廠年份等靜態規則判斷裝置能力。
採用的方法
Meta 自行開發低複雜度 AV1 編碼器，使功耗降至與 H.264 相當；解碼端採用 dav1d。裝置資格判定改用 ML 框架，以真實統計效能資料取代實驗室規格。為支援非旗艦裝置，引入非對稱設計：中階裝置解碼 AV1、編碼仍用 H.264，逐步擴大覆蓋範圍。
錯誤恢復機制包含兩層設計：Temporal Layers（TL）讓 base layer 在封包遺失時仍可獨立解碼；Long-Term Reference（LTR）幀透過專有 RTP 標頭擴充與 ACK 回饋頻道，在串流中斷後重新同步。碼率控制持續追蹤 VBV 緩衝狀態，將緩衝延遲壓低至 200 ms 以下。
實際效果
在低至中階裝置的實際產品設定下，AV1 比 H.264 減少至少 20% 的位元率，端對端視訊延遲維持在 300 ms 以下。AV1 函式庫整合後二進位大小增加約 600 kB（壓縮後），透過量化矩陣縮減與跨功能共用函式庫解決。
- 位元率節省：≥20%（低至中階裝置）
- 端對端延遲上限：300 ms
- VBV 緩衝延遲上限：200 ms
- 二進位體積增量：600 kB（壓縮後）
Discord 如何將語音基礎架構遷移至邊緣節點
Discord Engineering · 2026-06-27
原本的問題
Discord 語音服務原本部署於約 30 個雲端資料中心，冰島、奧克蘭、拉哥斯等地區只能繞道遙遠的上游節點。單一 SFU 主機指派策略導致跨區通話（例如德國用戶被路由至冰島）出現 2.7 倍 ping 增加與 9% 封包遺失惡化。服務發現原本基於 etcd，無法擴展至 Cloudflare 的 25,000 台主機規模。
採用的方法
Discord 將 80% 以上的語音/視訊流量遷移至 Cloudflare 300+ PoP 節點，並以 Valkey（GCP 記憶體存放區）搭配 10 分鐘 TTL 重新設計服務發現機制——語音主機啟動後主動呼叫中央系統登錄，定期更新。由於 Cloudflare 會自主回收執行個體，部署器改為請求重建容器並加入 5 分鐘關機延遲以防通話中斷。
歐洲遷移期間發現兩個核心問題。第一，Tokio async Rust 執行時的 recv future 獨佔事件迴圈，造成媒體批次延遲飆至數百毫秒；解法是加入 9 毫秒 flush budget 強制排程器執行計時器。第二，virtio-net 單一佇列將所有 Receive softirq 綁定至同一 vCPU，搶佔 worker 執行緒；透過 taskset 調整 CPU affinity 並啟用 Receive Packet Steering（RPS）解決。Cloudflare 效能團隊以 eBPF 探針在 NIC 層打時間戳記，精準隔離各層處理時間。
實際效果
Frankfurt 的 ping 下降 34%、封包遺失下降 42%；歐洲與拉丁美洲整體封包遺失減少 20–60%。Santiago 的 expand ratio（音訊填補比率）下降 40%。
- Frankfurt ping：-34%，封包遺失：-42%
- 歐洲/拉美封包遺失：-20% 至 -60%
- Santiago expand ratio：-40%
- 媒體批次延遲基準：~1 ms（修復後）
- 已遷移地區 70% 顯示品質改善
DLL 從未正式卸載，卻已從記憶體消失的謎案（上）
Microsoft Old New Thing · 2026-06-25
原本的問題
某第三方 Windows 應用程式頻繁發生堆疊溢位崩潰，錯誤報告指向 shell32.dll，但調查顯示 shell32 只是受害者。combase.dll 的記憶體頁狀態回傳 MEM_FREE / PAGE_NOACCESS，但 Windows Loader 的模組資料庫（PEB_LDR_DATA）仍保有對該 DLL 的引用，且載入計數顯示為 0xFFFFFFFF（已釘選狀態）。
採用的方法
透過崩潰傾印分析，確認 combase.dll 是被以 VirtualFree() 等機制直接從位址空間移除，而非透過正規的 FreeLibrary() 路徑卸載。Loader 的保護機制被繞過，導致模組資料庫與實際記憶體狀態不一致。崩潰本身呈現遞迴例外處理死循環：存取已釋放記憶體觸發 Access Violation，KiUserExceptionDispatch 試圖轉交用戶模式處理，但 RtlLookupFunctionEntry() 查找例外處理器時再次命中已釋放記憶體，形成無限遞迴直至堆疊耗盡。
100 個崩潰樣本中有 46% 源自同一根本原因，但因每次由不同的 DLL 先存取到被強制釋放的模組，表面症狀各異。shell32 在 DLL_PROCESS_DETACH 期間的字串解構子呼叫了 CoTaskMemFree，而 CoTaskMemFree 屬於已消失的 combase.dll，因此成為崩潰的觸發點。
實際效果
本篇（上集）確立了「DLL 被強制移出記憶體但 Loader 仍保有引用」的根本模式，並揭示靜態儲存期物件的解構子若在 process 關閉期間呼叫其他 DLL，會因載入順序不確定性而暴露此類記憶體損毀。下集將繼續追查實際觸發強制卸載的元兇。