音視訊面試題集錦 2022.05

語言: CN / TW / HK
時間 2022-06-09 08:51:41
主題:

前些時間，我在知識星球上建立了一個音視訊技術社群： 關鍵幀的音視訊開發圈 ，在這裡群友們會一起做一些打卡任務。比如：週期性地整理音視訊相關的面試題，彙集一份 音視訊面試題集錦 ，你可以看看這個合集：音視訊面試題集錦。再比如：循序漸進地歸納總結音視訊技術知識，繪製一幅 音視訊知識圖譜 ，你可以看看這個合集：音視訊知識圖譜。

下面是 2022.05 月音視訊面試題集錦內容的節選：

1）如何根據 NALU 裸流資料來判斷其是 H.264 編碼還是 H.265 編碼？

1）通常在處理音視訊資料時，我們如何選擇解碼器？

通常我們不是根據 NALU 裸流資料中的資訊來選擇解碼器，而是根據媒體封裝層的資訊來確定解碼器。

媒體封裝層是表示媒體資料是什麼封裝格式的，比如 MP4、FLV。在這層資訊裡，通常會攜帶碼流編碼格式的資訊。

拿 MP4 來說，我們可以根據 Sample Description Box(moov/trak/mdia/minf/stbl/stsd) 中的資訊來確定其封裝的碼流的編碼格式。參考：《MP4 格式》。

對於 FLV，我們可以根據 VideoTagHeader 中的 CodecID 等資訊來確定其封裝的碼流的編碼格式。參考：《FLV 格式》。

這樣的好處是效率比較高，解封裝的時候就可以確定選擇何種解碼器了。

2）怎麼識別 NALU 裸流資料的編碼格式是 H.264 還是 H.265？

但是，如果出現題目中的情況，沒有對碼流進行封裝，而是直接傳輸碼流時，這時候 NALU 中有什麼欄位能標識自己的編碼格式嗎？答案是，沒有這樣明確的欄位能標識碼流的編碼格式。

但是這個問題也不是不能解決，因為 H.264、H.265 碼流本身也是遵循一定格式規範的，我們可以按照它的格式規範進行探測，如果能解析出來正確的資訊，那也可以確定它的編碼格式。

比如，拿 H.265 來說，FFmpeg 中 hevcdec.c 就有對其碼流資料進行探測的函式 hevc_probe(...) 。

所以，我們可以按照編碼格式規範探測，比如 H.265 如果解析出了 pps、sps、vps 的各欄位資訊符合規範，就認為它是 H.265 的編碼；如果不是，在你們的碼流格式範圍中就只剩 H.264 了；接下來將碼流資料交給對應的解碼器解碼即可。

2）為什麼視訊會議用 UDP？如果用 TCP 實現音視訊，需要建立幾次連線？用 UDP 實現音視訊，有什麼方法可以保證通話質量？

1）為什麼視訊會議用 UDP？

視訊會議場景最重要的體驗指標一般是『通話延時』和『語音音質』兩方面。

在傳輸層使用 UDP 的主要考慮是為了降低通話延時。因為 UDP 的不需要 TCP 那樣的面向連線、可靠傳輸、擁塞控制等機制，這些機制（比如三次握手建連、丟包重傳等）通常都會帶來相對 UDP 更高的延時。

當然，另外一方面原因是人們對視訊會議中影象資訊的損失容忍度是比較高的，這樣即使 UDP 無法保證可靠性，有時候還是可以接受的。

2）如果用 TCP 實現音視訊，需要建立幾次連線？

可以做到只建連一次，多路複用。

也可以音訊和視訊各使用一路連線。

3）用 UDP 實現音視訊，有什麼方法可以保證通話質量？

使用 UDP 享受了低延時，犧牲了可靠性。但可靠性犧牲太多導致不可用也是不可接受的，所以還需要做一些機制來保證一定的可靠性，比如我們可以參考 WebRTC 的機制：

  • NACK：通過丟包重傳解決丟包問題，會增加延時。

  • FEC：通過冗餘資料解決丟包問題，會增加頻寬佔用。

  • JitterBuffer：通過佇列對接收到的資料進行緩衝，出隊時將資料包均勻平滑的取出，解決視訊的亂序與抖動。

  • NetEQ：類似 JitterBuffer，解決音訊的亂序與抖動。

3）CDN 在直播中有哪些運用？

CDN 的全稱為 Content Delivery Network，即內容分發網路，是一個策略性部署的整體系統，主要用來解決由於網路頻寬小、使用者訪問量大、網點分佈不均勻等導致使用者訪問網站速度慢的問題。這中間就有了很多的 CDN 節點。

具體實現是通過在現有的網路中，增加一層新的網路架構，將網站的內容釋出到離使用者最近的網路節點上，這樣使用者可以就近獲取所需的內容，解決之前網路擁塞、訪問延遲高的問題，提高使用者體驗。

圖一：CDN 各節點的協議

如圖一所示，不同的流媒體走的節點和協議做了區分，網路擁塞減少，訪問延遲降低，頻寬得到良好的控制等等。CDN 直播中常用的流媒體協議包括 RTMP、HLS、HTTP FLV 等。RTMP（Real Time Messaging Protocol）是基於 TCP 的，由 Adobe 公司為 Flash 播放器和伺服器之間音訊、視訊傳輸開發的開放協議。HLS（HTTP Live Streaming）是基於 HTTP 的，是 Apple 公司開放的音視訊傳輸協議。HTTP FLV 則是將 RTMP 封裝在 HTTP 協議之上的，可以更好的穿透防火牆等。

CDN 架構設計比較複雜，不同的 CDN 廠商，也在對其架構進行不斷的優化，所以架構不能統一而論。這裡只是對一些基本的架構進行簡單的剖析。CDN 主要包含：源站、快取伺服器、智慧 DNS、客戶端等幾個主要組成部分。

  • 源站：是指釋出內容的原始站點。新增、刪除和更改網站的檔案，都是在源站上進行的；另外快取伺服器所抓取的物件也全部來自於源站。對於直播來說，源站為主播客戶端。

  • 快取伺服器：是直接提供給使用者訪問的站點資源，由一臺或數臺伺服器組成；當用戶發起訪問時，他的訪問請求被智慧 DNS 定位到離他較近的快取伺服器。如果使用者所請求的內容剛好在快取裡面，則直接把內容返還給使用者；如果訪問所需的內容沒有被快取，則快取伺服器向鄰近的快取伺服器或直接向源站抓取內容，然後再返還給使用者。

  • 智慧 DNS：是整個 CDN 技術的核心，它主要根據使用者的來源，以及當前快取伺服器的負載情況等，將其訪問請求指向離使用者比較近且負載較小的快取伺服器。通過智慧 DNS 解析，讓使用者訪問同服務商下、負載較小的伺服器，可以消除網路訪問慢的問題，達到加速作用。

  • 客戶端：即發起訪問的普通使用者。對於直播來說，就是觀眾客戶端，例如手機客戶端，PC 客戶端。

圖二：CDN 資料請求流程

用圖二表示整個流程描述如下：主播開始進行直播，向智慧 DNS 傳送解析請求，智慧 DNS 返回最優 CDN 節點，IP 地址，主播端採集音視訊資料，傳送給 CDN 節點，CDN 節點進行快取等處理，觀眾端要觀看此主播的視訊，向智慧 DNS 傳送解析請求，智慧 DNS 返回最優 CDN 節點 IP 地址，觀眾端向 CDN 節點請求音視訊資料，CDN 節點同步其他節點的音視訊資料，CDN 節點將音視訊資料傳送給觀眾端。

4）為什麼會有 YUV 這種資料？它相比 RGB 資料有什麼優點？

RGB 工業顯示器要求一幅彩色影象由分開的 R、G、B 訊號組成，而電視顯示器則需要混合訊號輸入，為了實現對這兩種標準的相容，NTSC（美國國家電視系統委員會）制定了 YIQ 顏色模型，它的主要優點是可以實現對彩色電視和黑白電視的相容，即可以用黑白電視收看彩色電視訊號。YUV 顏色模型則是在 YIQ 的基礎上發展而來。
YUV 顏色模型中用亮度、色度來表示顏色。它的亮度資訊和色度資訊是分離的，其中 Y 表示亮度通道，U 和 V 則表示色度通道。如果只有 Y 資訊，沒有 U、V 資訊，那麼表示的影象就是灰度影象。YUV 常用在各種影像處理場景中。YUV 在對照片或視訊編碼時，考慮到人眼對亮度資訊的敏感度高於色度資訊，允許降低色度的頻寬。這樣一來就可以對色度資訊進行壓縮，所以 YUV 可以相對 RGB 使用更少的資料頻寬。比如常見的取樣格式有：4:2:1、4:1:1、4:2:0 等，它們分別相對 RGB 壓縮了 33.3%、50%、50% 的資料量。

如果你也對音視訊技術感興趣，比如，符合下面的情況：

  • 在校大學生 → 學習音視訊開發

  • iOS/Android 客戶端開發 → 轉入音視訊領域

  • 直播/短視訊業務開發 → 深入音視訊底層 SDK 開發

  • 音視訊 SDK 開發 → 提升技能，解決優化瓶頸

可以長按識別或掃描下面二維碼，瞭解一下這個社群，根據自己的情況按需加入：

識別二維碼加入我們
「」