零基礎入門:實時音視頻技術基礎知識全面盤點

2020-08-28 移動端IM技術分享

本文引用自公眾號「開發的貓」,本次收錄時有改動,感謝原作者「開發的貓」的分享。

1、引言

隨著行動網路速度越來越快、質量越來越來,實時音視頻技術已經在各種應用場景下全面開花,語音通話、視頻通話、視頻會議、遠程白板、遠程監控等等。

實時音視頻技術的開發也越來越受到重視,但是由於音視頻開發涉及知識面比較廣,入門門檻相對較高,讓許許多多開發者望而生畏。

雖然網上有很多的博文總結了實時音視頻技術的學習路線,但是相關的知識都相對獨立,有講「音視頻解碼相關」的、有講「OpenGL相關」的、也有講「FFmpeg相關的」、還有講「RTP/RTCP、RTMP、HLS、QUIC等通信相關的」,但是對於新手來說,把所有的知識銜接串聯起來,並很好的理解所有的知識,卻是非常困難的。

本人在學習音視頻開發的過程中,深刻體會到了由於知識的分散、過渡斷層帶來的種種困惑和痛苦,因此希望通過自己的理解,可以把音視頻開發相關的知識總結出來,並形成系列文章,循序漸進,剖析各個環節,一則對自己所學做一個總結和鞏固,二則希望可以幫助想入門音視頻開發的開發者小夥伴們。

本文是作者自已根據入門實時音視頻的親身經歷,對於基礎知識點的認知總結。雖然很淺顯,但相對小白來說,能稍微系統的了解這些概念就已經是很好的起點了。

本文已同步發布於「即時通訊技術圈」公眾號。

2、相關文章

《即時通訊音視頻開發(一):視頻編解碼之理論概述》

《即時通訊音視頻開發(六):如何開始音頻編解碼技術的學習》

《即時通訊音視頻開發(七):音頻基礎及編碼原理入門》

《即時通訊音視頻開發(十四):實時音視頻數據傳輸協議介紹》

《即時通訊音視頻開發(十九):零基礎,史上最通俗視頻編碼技術入門》(* 必讀)

《實時語音聊天中的音頻處理與編碼壓縮技術簡述》

《移動端實時音視頻直播技術詳解(一):開篇》

《移動端實時音視頻直播技術詳解(二):採集》

《移動端實時音視頻直播技術詳解(三):處理》

《移動端實時音視頻直播技術詳解(四):編碼和封裝》

《移動端實時音視頻直播技術詳解(五):推流和傳輸》

《移動端實時音視頻直播技術詳解(六):延遲優化》

《福利貼:最全實時音視頻開發要用到的開源工程匯總》(* 必讀)

《寫給小白的實時音視頻技術入門提綱》(* 必讀)

《愛奇藝技術分享:輕鬆詼諧,講解視頻編解碼技術的過去、現在和將來》

3、視頻是什麼?

3.1 動畫書

不知道大家小時候是否玩過一種動畫小人書,連續翻動的時候,小人書的畫面就會變成一個動畫,類似現在的gif格式圖片。

本來是一本靜態的小人書,通過翻動以後,就會變成一個有趣的小動畫,如果畫面夠多,翻動速度夠快的話,這其實就是一個小視頻。

而視頻的原理正是如此,由於人類眼睛的特殊結構,畫面快速切換時,畫面會有殘留,感覺起來就是連貫的動作。所以,視頻就是由一系列圖片構成的。

3.2 視頻幀

幀,是視頻的一個基本概念,表示一張畫面,如上面的翻頁動畫書中的一頁,就是一幀。一個視頻就是由許許多多幀組成的。

3.3 幀率

幀率,即單位時間內幀的數量,單位為:幀/秒 或fps(frames per second)。如動畫書中,一秒內包含多少張圖片,圖片越多,畫面越順滑,過渡越自然。

幀率的一般以下幾個典型值:

1)24/25 fps:1秒 24/25 幀,一般的電影幀率;

2)30/60 fps:1秒 30/60 幀,遊戲的幀率,30幀可以接受,60幀會感覺更加流暢逼真。

85 fps以上人眼基本無法察覺出來了,所以更高的幀率在視頻裡沒有太大意義。

3.4 色彩空間

這裡我們只講常用到的兩種色彩空間。

1)RGB:RGB的顏色模式應該是我們最熟悉的一種,在現在的電子設備中應用廣泛。通過R G B三種基礎色,可以混合出所有的顏色;

2)YUV:這裡著重講一下YUV,這種色彩空間並不是我們熟悉的。這是一種亮度與色度分離的色彩格式。

早期的電視都是黑白的,即只有亮度值,即Y。有了彩色電視以後,加入了UV兩種色度,形成現在的YUV,也叫YCbCr。

1)Y:亮度,就是灰度值。除了表示亮度信號外,還含有較多的綠色通道量;

2)U:藍色通道與亮度的差值;

3)V:紅色通道與亮度的差值。

如下圖,可以看到Y、V、U 3個分量的效果差值:

採用YUV有什麼優勢呢?

人眼對亮度敏感,對色度不敏感,因此減少部分UV的數據量,人眼卻無法感知出來,這樣可以通過壓縮UV的解析度,在不影響觀感的前提下,減小視頻的體積。

RGB和YUV的換算:

Y = 0.299R + 0.587G + 0.114B

U = -0.147R - 0.289G + 0.436B

V = 0.615R - 0.515G - 0.100B

——————————————————

R = Y + 1.14V

G = Y - 0.39U - 0.58V

B = Y + 2.03U

3.5 進一步學習

如果你認為上面的文字還是有點專業,則強烈建議閱讀下文:《即時通訊音視頻開發(十九):零基礎,史上最通俗視頻編碼技術入門》,絕對史上最通俗!

4、音頻是什麼?

4.1 基本知識

音頻數據的承載方式最常用的是脈衝編碼調製,即 PCM。

在自然界中,聲音是連續不斷的,是一種模擬信號,那怎樣才能把聲音保存下來呢?那就是把聲音數位化,即轉換為數位訊號。

我們知道聲音是一種波,有自己的振幅和頻率,那麼要保存聲音,就要保存聲音在各個時間點上的振幅。

而數位訊號並不能連續保存所有時間點的振幅,事實上,並不需要保存連續的信號,就可以還原到人耳可接受的聲音。

根據奈奎斯特採樣定理:為了不失真地恢復模擬信號,採樣頻率應該不小於模擬信號頻譜中最高頻率的2倍。

根據以上分析,PCM的採集步驟分為以下步驟:

模擬信號 -> 採樣 -> 量化 -> 編碼 -> 數位訊號

4.2 採樣率和採樣位數

採樣率,即採樣的頻率。

上面提到,採樣率要大於原聲波頻率的2倍,人耳能聽到的最高頻率為20kHz,所以為了滿足人耳的聽覺要求,採樣率至少為40kHz,通常為44.1kHz,更高的通常為48kHz。

採樣位數,涉及到上面提到的振幅量化。波形振幅在模擬信號上也是連續的樣本值,而在數位訊號中,信號一般是不連續的,所以模擬信號量化以後,只能取一個近似的整數值,為了記錄這些振幅值,採樣器會採用一個固定的位數來記錄這些振幅值,通常有8位、16位、32位。

位數越多,記錄的值越準確,還原度越高。

4.3 編碼

最後就是編碼了。由於數位訊號是由0,1組成的,因此,需要將幅度值轉換為一系列0和1進行存儲,也就是編碼,最後得到的數據就是數位訊號:一串0和1組成的數據。

整個過程如下:

4.4 聲道數

聲道數,是指支持能不同發聲(注意是不同聲音)的音響的個數。

單聲道:1個聲道

雙聲道:2個聲道

立體聲道:默認為2個聲道

立體聲道(4聲道):4個聲道

4.5 碼率

碼率,是指一個數據流中每秒鐘能通過的信息量,單位bps(bit per second)。

碼率 = 採樣率 * 採樣位數 * 聲道數

4.6 深入地學習

讀完上面的文字後,如果覺得不夠深入,可以繼續系統的學習以下資料:

《即時通訊音視頻開發(六):如何開始音頻編解碼技術的學習》

《即時通訊音視頻開發(七):音頻基礎及編碼原理入門》

《即時通訊音視頻開發(八):常見的實時語音通訊編碼標準》

《即時通訊音視頻開發(九):實時語音通訊的回音及回音消除概述》

《即時通訊音視頻開發(十):實時語音通訊的回音消除技術詳解》

《即時通訊音視頻開發(十一):實時語音通訊丟包補償技術詳解》

《即時通訊音視頻開發(十八):詳解音頻編解碼的原理、演進和應用選型》

《實時語音聊天中的音頻處理與編碼壓縮技術簡述》

《網易視頻雲技術分享:音頻處理與壓縮技術快速入門》

如果你認為還需要更淺的文章,則強烈建議閱讀下文(絕對史上最通俗):

《即時通訊音視頻開發(十九):零基礎,史上最通俗視頻編碼技術入門》

5、為什麼要編碼

這裡的編碼和上面音頻中提到的編碼不是同個概念,而是指壓縮編碼。

我們知道,在計算機的世界中,一切都是0和1組成的,音頻和視頻數據也不例外。由於音視頻的數據量龐大,如果按照裸流數據存儲的話,那將需要耗費非常大的存儲空間,也不利於傳送。而音視頻中,其實包含了大量0和1的重複數據,因此可以通過一定的算法來壓縮這些0和1的數據。

特別在視頻中,由於畫面是逐漸過渡的,因此整個視頻中,包含了大量畫面/像素的重複,這正好提供了非常大的壓縮空間。

因此,編碼可以大大減小音視頻數據的大小,讓音視頻更容易存儲和傳送。

那麼,未經編碼的原始音視頻,數據量至底有多大?

以一個解析度1920×1280,幀率30的視頻為例:

共:1920×1280=2,073,600(Pixels 像素),每個像素點是24bit(前面算過的哦);

也就是:每幅圖片2073600×24=49766400 bit,8 bit(位)=1 byte(字節);

所以:49766400bit=6220800byte≈6.22MB。

這是一幅1920×1280圖片的原始大小,再乘以幀率30。

也就是說:每秒視頻的大小是186.6MB,每分鐘大約是11GB,一部90分鐘的電影,約是1000GB。。。

(以上舉例引用自:《即時通訊音視頻開發(十九):零基礎,史上最通俗視頻編碼技術入門》)

6、視頻編碼

視頻編碼格式有很多,比如H26x系列和MPEG系列的編碼,這些編碼格式都是為了適應時代發展而出現的。

其中,H26x(1/2/3/4/5)系列由ITU(International Telecommunication Union)國際電傳視訊聯盟主導

MPEG(1/2/3/4)系列由MPEG(Moving Picture Experts Group, ISO旗下的組織)主導。

當然,他們也有聯合制定的編碼標準,那就是現在主流的編碼格式H264,當然還有下一代更先進的壓縮編碼標準H265。

視頻編碼知識比較專業,限於篇幅,我就不在此展開討論了。

如果想系統地了解視頻編碼技術,可以讀以下資料:

《即時通訊音視頻開發(一):視頻編解碼之理論概述》

《即時通訊音視頻開發(二):視頻編解碼之數字視頻介紹》

《即時通訊音視頻開發(三):視頻編解碼之編碼基礎》

《即時通訊音視頻開發(四):視頻編解碼之預測技術介紹》

《即時通訊音視頻開發(五):認識主流視頻編碼技術H.264》

《即時通訊音視頻開發(十二):多人實時音視頻聊天架構探討》

《即時通訊音視頻開發(十三):實時視頻編碼H.264的特點與優勢》

《即時通訊音視頻開發(十四):實時音視頻數據傳輸協議介紹》

《即時通訊音視頻開發(十五):聊聊P2P與實時音視頻的應用情況》

《即時通訊音視頻開發(十六):移動端實時音視頻開發的幾個建議》

《即時通訊音視頻開發(十七):視頻編碼H.264、VP8的前世今生》

7、音頻編碼

原始的PCM音頻數據也是非常大的數據量,因此也需要對其進行壓縮編碼。

和視頻編碼一樣,音頻也有許多的編碼格式,如:WAV、MP3、WMA、APE、FLAC等等,音樂發燒友應該對這些格式非常熟悉,特別是後兩種無損壓縮格式。

但是,我們今天的主角不是他們,而是另外一個叫AAC的壓縮格式。本節以AAC格式為例,直觀的了解音頻壓縮格式。

AAC是新一代的音頻有損壓縮技術,一種高壓縮比的音頻壓縮算法。在MP4視頻中的音頻數據,大多數時候都是採用AAC壓縮格式。

AAC格式主要分為兩種:ADIF、ADTS。

1)ADIF:Audio Data Interchange Format。音頻數據交換格式。這種格式的特徵是可以確定的找到這個音頻數據的開始,不需進行在音頻數據流中間開始的解碼,即它的解碼必須在明確定義的開始處進行。這種格式常用在磁碟文件中。

2)ADTS:Audio Data Transport Stream。音頻數據傳輸流。這種格式的特徵是它是一個有同步字的比特流,解碼可以在這個流中任何位置開始。它的特徵類似於mp3數據流格式。

ADTS可以在任意幀解碼,它每一幀都有頭信息。ADIF只有一個統一的頭,所以必須得到所有的數據後解碼。且這兩種的header的格式也是不同的,目前一般編碼後的都是ADTS格式的音頻流。

ADIF數據格式:

1header | raw_data

ADTS 一幀 數據格式(中間部分,左右省略號為前後數據幀):

AAC內部結構也不再贅述,如果有興趣,可以參考《AAC 文件解析及解碼流程》。

如果需要更深入地學習音頻編碼知識,可以看看以下資料:

《即時通訊音視頻開發(六):如何開始音頻編解碼技術的學習》

《即時通訊音視頻開發(七):音頻基礎及編碼原理入門》

《即時通訊音視頻開發(八):常見的實時語音通訊編碼標準》

《即時通訊音視頻開發(十八):詳解音頻編解碼的原理、演進和應用選型》

8、音視頻容器

細心的讀者可能已經發現,前面我們介紹的各種音視頻的編碼格式,沒有一種是我們平時使用到的視頻格式,比如:mp4、rmvb、avi、mkv、mov...

沒錯,這些我們熟悉的視頻格式,其實是包裹了音視頻編碼數據的容器,用來把以特定編碼標準編碼的視頻流和音頻流混在一起,成為一個文件。

例如:mp4支持H264、H265等視頻編碼和AAC、MP3等音頻編碼。

mp4是目前最流行的視頻格式,在移動端,一般將視頻封裝為mp4格式。

對於音視頻編碼格式和容器之間的關係,可以詳細讀《即時通訊音視頻開發(十九):零基礎,史上最通俗視頻編碼技術入門》一文中的「6、視頻編碼的國際標準」一節。

9、硬解碼和軟解碼

我們在一些播放器中會看到,有硬解碼和軟解碼兩種播放形式給我們選擇,但是我們大部分時候並不能感覺出他們的區別,對於普通用戶來說,只要能播放就行了。

那麼他們內部究竟有什麼區別呢?

在手機或者PC上,都會有CPU、GPU或者解碼器等硬體。通常,我們的計算都是在CPU上進行的,也就是我們軟體的執行晶片,而GPU主要負責畫面的顯示(是一種硬體加速)。

所謂軟解碼:就是指利用CPU的計算能力來解碼,通常如果CPU的能力不是很強的時候,一則解碼速度會比較慢,二則手機可能出現發熱現象。但是,由於使用統一的算法,兼容性會很好。

所謂硬解碼:指的是利用手機上專門的解碼晶片來加速解碼。通常硬解碼的解碼速度會快很多,但是由於硬解碼由各個廠家實現,質量參差不齊,非常容易出現兼容性問題。

10、參考資料

[1] 音視頻開發基礎知識

[2] YUV顏色編碼解析

[3] YUV數據格式

[4] 音頻基礎知識

[5] AAC 文件解析及解碼流程

[6] 入門理解H264編碼

(本文同步發布於:http://www.52im.net/thread-3079-1-1.html)

相關焦點

  • 零基礎入門:實時音視頻技術基礎知識全面盤點
    1、引言隨著行動網路速度越來越快、質量越來越來,實時音視頻技術已經在各種應用場景下全面開花,語音通話、視頻通話、視頻會議、遠程白板、遠程監控等等。實時音視頻技術的開發也越來越受到重視,但是由於音視頻開發涉及知識面比較廣,入門門檻相對較高,讓許許多多開發者望而生畏。
  • 實時音視頻面視必備:快速掌握11個視頻技術相關的基礎概念
    雖然實時音視頻技術的應用越來越普及,但對於程式設計師來說,這方面的技術門檻仍然存在(準備地說是仍然很高),想要在短時間內全面掌握實時音視頻相關的技術難度非常大。不過,作為想從事這方面工作的小白面視者,是無法在短時間內全面掌握音視頻技術,但可以通過快速了解相關的知識概念,在自已在腦中快速組織起相應的知識圖譜,有助於日後針對相關知識點逐個深入學習和研究,也算是一種高效的技術學習方法
  • Android 音視頻學習基礎——1.1 音視頻基礎知識
    基礎數據 通過上圖 可以了解播放器的原理,其實就是將一個壓縮數據還原成一個基礎數據的過程。那麼什麼時基礎數據,基礎數據就是硬體所能識別的數據,音頻硬體所能識別的是pcm。下面分開將。編碼數據和格式 常見的音頻編碼格式有AAC MP3 AC-3 WAV 等,視頻的有H264 H265.那麼什麼是編碼格式。它經常和後面講的封裝格式混在一塊。編碼格式:是將上面講到的基礎數據,進行通過算法一般是各種壓縮算法,後輸出的數據。比如,上面講到的pcm數據中的 1111 1111.通過壓縮後可能就變成了 1101。(做個假設)。
  • 了不起的WebRTC:生態日趨完善,或將實時音視頻技術白菜化
    (本文同步發布於:52im.net/thread-1631-1-1.html)2、相關文章《開源實時音視頻技術WebRTC的現狀》《簡述開源實時音視頻技術WebRTC的優缺點》《訪談WebRTC標準之父:WebRTC的過去、現在和未來》《良心分享:WebRTC 零基礎開發者教程(中文)[附件下載]》《WebRTC實時音視頻技術的整體架構介紹
  • 實時音視頻技術專場活動回顧(一):Flutter實時音視頻應用場景實踐
    11月7日,即構和上海GDG技術社區聯合舉辦了實時音視頻雲上技術分享專場,來自即構科技和Bilibili的資深技術專家進行了深度分享。大會吸引了眾多開發人員交流、觀看,並在活動過程中與分享嘉賓進行了熱烈互動。下面我們將整理嘉賓們分享的核心內容,錯過活動直播的小夥伴可以繼續觀看學習。
  • 七牛雲RTN:基於WebRTC零基礎搭建實時音視頻平臺
    引言  近年來,在線教育、狼人殺、在線抓娃娃、線上 KTV 等多人視頻互動模式不斷湧現,實時音視頻通信風頭正勁,實時音視頻技術 WebRTC 也因此受到了廣泛關注。相關數據顯示,2017-2021 年期間,全球網絡實時通信(WebRTC)市場將以 34.37% 的年均複合增長率增長。
  • 互動協作白板與音視頻實時同步技術實踐
    本文整理自即構科技互動白板技術負責人陳曉聰在LiveVideoStack的線上分享,內容主要圍繞白板與音視頻的同步和白板的多端實時互動兩個角度,深度解析即構在互動白板方面的技術探索實踐。技術點主要圍繞音視頻與白板的同步和多端實時互動同步講解。
  • 音視頻技術開發周刊|音視頻技術|webrtc|https
    每周一期,縱覽音視頻技術領域的乾貨和新聞投稿:contribute@livevideostack.com。架構WebRTC M84 版本發布M83 反而更令人興奮。https://groups.google.com/forum/?
  • 零基礎入門學畫畫要學什麼基礎知識
    本文由「學美術上美術集網校」原創,圖片素材來自網絡,僅供學習分享 零基礎入門學畫畫要學什麼基礎知識?這些知識作為新手的你一定要知道。剛接觸繪畫的朋友,是不是不知道自己該怎么正確的開始學習。
  • 音視頻技術開發周刊|172
    ,我們通常可以使用libx264, ffmpeg等第三方視頻編碼庫,但是如果對編碼的速度有一定的要求,要實現實時甚至超實時的高速視頻編碼,我們並沒有太多選項,只能使用Android提供的MediaCodec硬編碼模塊。
  • 實時視頻美顏需要社交基礎,不太可能催生音視頻領域的「美圖秀秀」
    幾多歡喜幾多愁,在各種美顏產品橫飛的當下,想借著視頻一驗真身的的網友,終於連這一塊淨土也失去了。已經有很多人從社會學層面解讀了視頻美顏背後的市場驅動力;除了這些原因,雷鋒網更關心的是這個新功能開發和上線背後的一些產品和技術實現問題,以及會多大程度影響現有的音視頻產品。
  • 騰訊技術分享:微信小程序音視頻與WebRTC互通的技術思路和實踐
    :微信實時視頻聊天技術的演進》《騰訊音視頻實驗室:使用AI黑科技實現超低碼率的高清實時視頻聊天》有關WebRTC的技術文章:《開源實時音視頻技術WebRTC的現狀》《簡述開源實時音視頻技術WebRTC的優缺點》《訪談WebRTC標準之父:WebRTC的過去、現在和未來》《良心分享:WebRTC 零基礎開發者教程(中文)[附件下載]》《WebRTC實時音視頻技術的整體架構介紹
  • 即構科技實時音視頻sdk,四步在應用內快速實現音視頻功能
    當代音視頻技術融計算機、聲音、文本、圖像、動畫、 視頻和通信等多種功能於一體,得益於網際網路技術的普及與發展,實現了音、視頻信息的資源共享。音視頻技術早已深入到人們日常生活、學習、工作、生產、管理等各個方面,它並正潛移默化地改變著我們生活的面貌。
  • 環信實時音視頻雲亮相LiveVideoStackCon 2019
    4月19-20日, LiveVideoStackCon音視頻技術大會在上海隆重舉辦。本屆會議以「多媒體技術賦能新世界」為主題,匯集400餘位多媒體技術生態中的代表,聚焦音頻、視頻、圖像、AI等技術的最新探索與應用實踐,重新闡述音視頻技術在不同行業中的力量。
  • 華為雲RTC:華為雲實時音視頻賦能更多創新場景
    重災疫情下,全民線上使得「非接觸」式概念火了,而RTC(實時音視頻)技術則是支持所有線上非接觸式實時互動場景的基石。可見,實時音視頻的技術還沒達到我們期望的技術頂點,如端到端的延遲,對不同手機終端、SDK的適配,以及網絡可靠性和安全性,這面臨的是成堆的技術問題需要解決。突破重圍,華為雲RCT如何成為音視頻行業黑馬?疫情爆發初期,視頻會議和在線直播課面臨井噴式湧入,許多平臺未能扛住壓力,出現卡頓、崩潰。
  • 聊聊實時音視頻中的技術難點:回聲消除+噪聲消除
    文 | 菊風媒體引擎資深研究團隊在各個實時音視頻互動場景中,回聲和噪聲對於影響用戶體驗而言都是很大的問題。音視頻正在發展成為網際網路線上溝通的必然趨勢,在自然的交流環境中,回聲和噪聲是非常影響溝通體驗的。
  • 音視頻技術開發周刊
    音視頻技術 短視頻 SDK研發路線 從 0-1 寫一個如何開發一款音視頻編輯的 SDK 系列文章。 實時視頻的鏡頭失真校正 本文來自Vidovation的網絡研討會,主持人是Vidovation的CTO兼聯合創始人Jim Jachetta,演講者是Alpha Image的執行長MC Patel。主要介紹了實時視頻的鏡頭失真校正。
  • 產品經理,你要了解一些音視頻技術
    此外,伴隨著抖音、快手等短視頻類應用的爆發,視頻類產品更是時刻充斥著我們的生活。那麼,直播類或者視頻的產品背後涉及到的音視頻技術知識都有哪些呢?本文將從直播類產品的基礎架構出發,闡述一些基礎的音視頻技術知識。
  • 最低延遲66ms,融雲帶來更流暢的實時音視頻服務體驗
    繼融雲實時音視頻3.0上線運行一年後,全球領先的網際網路通信雲服務商融雲在近期宣布對實時音視頻服務進行全面升級。通過「IM即時通訊+實時音視頻+推送」的一體化解決方案,「用一套 SDK ,解決所有通信場景」,打造一流的實時音視頻服務,獲開發者極大關注。
  • 實時互動PaaS終成正果,音視頻需求爆發正當時
    公司為開發者提 供實時視頻、實時音頻、實時消息、實時錄製等多個 API,開發者只需 簡單調用,即可在應用內構建多種實時音視頻互動場景。對於大部分開發者而言,構建實時音視頻參與功能既困難又昂貴。實時視頻或語音互動要求用戶之間以毫秒級的延遲可靠地多路傳輸大量數據。