快手音視訊開發面試真題：編解碼+WebRTC+低延遲全考察

背景介紹

我做音視訊開發2年了，之前在一家直播公司負責推流和播放器的開發，主要用C++寫音視訊處理模組，對FFmpeg、WebRTC這些框架比較熟悉。快手的音視訊開發崗位是我一直想去的，畢竟快手是國內音視訊技術的標竿，編解碼、傳輸、渲染都是行業頂尖的。

我是透過Boss直聘投的履歷，崗位是音視訊開發工程師。大概3天後就收到了面試邀請，效率很高。整個流程是三輪技術面，週期大概兩週。

面試流程覆盤

一面：音視訊基礎+H.264/H.265（約70分鐘）

一面面試官是個音視訊老兵，上來就問了我對音視訊整體流程的理解，我從採集、編碼、傳輸、解碼、渲染五個環節講了。面試官點了點頭，然後開始逐個環節深挖。

編碼部分：面試官讓我詳細講H.264的編碼流程，從幀內預測、幀間預測、變換量化到熵編碼，我按順序講了。面試官追問了I幀、P幀、B幀的區別和作用，以及GOP結構對延遲的影響。我講了長GOP可以提升壓縮率但增加延遲，短GOP則相反。然後問了H.264和H.265的核心區別，我講了CTU、更多預測模式、SAO濾波器等H.265的改進點。面試官還問了一個實際的問題：H.265的編碼效率比H.264高多少？我說同品質下碼率能省40%-50%，但編碼複雜度是H.264的3-4倍。

封裝格式部分：問了FLV、MP4、TS這三種封裝格式的特點和適用場景。我講了FLV適合直播流、MP4適合點播、TS適合廣播。面試官追問了MP4的moov atom放在檔案開頭和結尾的區別，以及對播放的影響。

音訊部分：問了AAC的編碼原理和LC、HE-AAC的區別。還問了一個比較有意思的問題：為什麼音訊編碼一般用頻域方法而視訊編碼用空域+時域方法？我從人耳和人眼的感知特性差異回答了。

一面結束的時候面試官說「基礎挺扎實的」，我心裡有了底。

二面：WebRTC+低延遲傳輸（約80分鐘）

二面是整個面試最難的一輪，面試官是WebRTC方向的專家。

WebRTC部分：面試官讓我講WebRTC的整體架構，我從PeerConnection、Transport、Media Engine三層講了。然後重點問了網路傳輸部分：ICE框架的完整流程（STUN、TURN、候選地址收集），DTLS-SRTP的加密握手流程，以及擁塞控制演算法。面試官對GCC（Google Congestion Control）演算法特別感興趣，讓我詳細講了基於延遲的擁塞檢測和碼率調整邏輯。我畫了GCC的架構圖，講了到達時間濾波器、過載檢測器、碼率控制器的協作流程。

低延遲傳輸部分：面試官問了一個很實際的問題：直播場景下如何做到端到端1秒以內的延遲？我從編碼側（低延遲編碼參數、短GOP）、傳輸側（QUIC/UDP替代TCP、FEC前向糾錯）、播放側（低延遲緩衝策略、快速啟播）三個層面講了。面試官追問了FEC和ARQ的選擇策略，我說了FEC適合高延遲網路、ARQ適合低延遲網路的判斷依據。然後問了SRT協定和RIST協定的了解，我簡單講了下。

實戰場景：面試官給了一個場景——跨國直播推流，網路抖動大，偶爾丟包，如何保證畫質和流暢度？我講了自適應碼率策略、SVC分層編碼、FEC+ARQ混合糾錯、多路徑傳輸等方案。面試官對SVC的分層編碼很感興趣，讓我講了時域SVC和空域SVC的區別。

二面聊了80分鐘，感覺被掏空了，但也確實學到了不少。

三面：專案深挖+綜合考察（約60分鐘）

三面面試官應該是部門負責人，風格比較開放。

專案深挖：面試官讓我講一個最有挑戰的音視訊專案。我選了之前做的一個超低延遲直播方案，從需求背景（端到端延遲要求500ms以內）到技術方案（WebRTC+QUIC+SVC）到最終效果（實測延遲400ms，卡頓率0.5%）。面試官對QUIC替代TCP的細節很感興趣，問了多路復用、0-RTT連線、連線遷移等特性。然後問了我遇到的最大技術挑戰是什麼，我講了一個弱網環境下碼率自適應的調優過程，從演算法選擇到參數調優到線上驗證。

綜合考察：面試官問了我對音視訊行業趨勢的看法，我聊了AV1編解碼、空間計算、AI超分三個方向。然後問了職業規劃，為什麼選擇快手。最後問了一個開放題：如果讓你設計一個萬人連麥的架構，你會怎麼做？我從SFU架構、串流媒體轉發、音訊混流、下行碼率自適應幾個角度回答了。

真題彙總

1. H.264的編碼流程？I幀、P幀、B幀的區別？

2. GOP結構對延遲的影響？

3. H.264和H.265的核心區別？

4. FLV、MP4、TS封裝格式的特點和適用場景？

5. MP4的moov atom放在檔案開頭和結尾的區別？

6. AAC的編碼原理？LC和HE-AAC的區別？

7. WebRTC的整體架構？

8. ICE框架的完整流程？

9. GCC擁塞控制演算法的原理？

10. 直播場景下如何做到端到端1秒以內的延遲？

11. FEC和ARQ的選擇策略？

12. 跨國直播推流如何保證畫質和流暢度？

13. 時域SVC和空域SVC的區別？

14. QUIC替代TCP的優勢？

15. 設計一個萬人連麥的架構？

心得建議

1. 編解碼原理要深入理解：快手音視訊面試不是問你會不會用FFmpeg，而是問你懂不懂編解碼的底層原理。H.264/H.265的編碼流程、預測模式、熵編碼這些要能講清楚。建議讀《Video Codec Design》和H.264規範。

2. WebRTC是加分利器：很多候選人只會用FFmpeg，不懂WebRTC。但快手的即時通訊場景大量使用WebRTC，這塊是硬實力。建議讀WebRTC原始碼，至少理解核心模組。

3. 低延遲傳輸要有實戰經驗：延遲最佳化不是調幾個參數就能搞定的，需要從編碼、傳輸、播放全鏈路考慮。建議搭建一個端到端的低延遲直播系統，實際測量和最佳化。

4. 關注行業最新技術：AV1、QUIC、SVC這些新技術在面試中經常被問到。建議關注VideoLAN、IETF、WebRTC標準組的最新動態。

5. 專案要有量化資料：面試官很看重專案的實際效果，延遲降低了多少、卡頓率是多少、QoE提升了多少。建議在專案中做好資料埋點和效果評估。

FAQ

Q：快手音視訊面試對C++要求高嗎？

A：要求比較高。音視訊開發大量使用C++，面試官會問C++的記憶體管理、多執行緒、模板等。建議有扎實的C++基礎。

Q：沒有WebRTC經驗能過嗎？

A：有難度。快手即時通訊場景大量使用WebRTC，如果完全沒經驗，建議至少做個WebRTC的demo專案，理解核心概念。

Q：面試會問演算法題嗎？

A：會，但偏實用性。我這次被問了一個環形緩衝區的實作和一個生產者-消費者模型的設計。

Q：快手音視訊團隊的技術棧是什麼？

A：主要是C++，編碼用x264/x265/SVT-AV1，傳輸用WebRTC/SRT/QUIC，播放用自研播放器。面試官也提到團隊在探索AI編解碼方向。