[發明專利]音視頻數據傳輸的方法和系統

在審

• 申請號: 202310261367.8
• 申請日: 2023-03-17
• 公開（公告）號: CN116233563A
• 公開（公告）日: 2023-06-06
• 發明（設計）人: 吳義;陳建;劉宏強
• 申請（專利權）人: 上海嗶哩嗶哩科技有限公司
• 主分類號: H04N21/63
• 分類號: H04N21/63;H04N21/643;H04N21/647
• 代理公司: 北京英特普羅知識產權代理有限公司 11015
• 代理人: 鄧小玲

本申請實施例提供了一種音視頻數據傳輸方法和系統，發送端與接收端之間建立基于QUIC協議的連接，所述基于QUIC協議的連接包含多個傳輸流，所述方法包括：對待傳輸的音視頻流數據進行解封裝得到多種類型的源數據；根據每一類所述源數據的類型進行封裝，得到支持預設協議的目標數據報文；從所述多個傳輸流中確定與所述目標數據報文的類型匹配的目標傳輸流，并通過所述目標傳輸流將所述目標數據報文傳輸至所述接收端。通過基于QUIC作為傳輸協議，在基于QUIC協議首次以1?RTT握手建連后，后續握手重連只需0?RTT；用自定義的預設協議取代RTMP協議，可實現基于QUIC協議建聯后直接發送音視頻數據，省去了RTMP握手的時間，大大降低了首幀的延遲。

技術領域

本申請實施例涉及數據傳輸技術領域，尤其涉及一種音視頻數據傳輸的方法、系統、計算機設備及計算機可讀存儲介質。

背景技術

現有技術中，如果采用TCP+RTMP的方案傳輸音視頻流數據，在傳輸音視頻數據之前必須得經過TCP的三次握手和RTMP的多次握手，這些握手會大大增加網絡的傳輸時延；而且，如果客戶端更換網絡，會導致TCP連接斷開，如需繼續接收音視頻數據，需要重新發起TCP和RTMP握手，這將導致用戶觀看視頻時出現卡頓或黑屏等情況，大大地降低用戶的觀看體驗。此外，利用同一個TCP連接傳輸音視頻數據時，為保證傳輸數據有序，TCP會出現隊頭阻塞問題，即在傳輸音視頻數據時，若排在前面的數據出現丟包時，會導致后面的數據即使收到也無法被應用層使用，造成音頻與視頻數據傳輸互相干擾，用戶觀看的視頻卡頓，影響觀看體驗。

發明內容

本申請實施例的目的是提供一種音視頻數據傳輸方法、系統、計算機設備及計算機可讀存儲介質，用于解決以下問題：在傳輸音視頻數據時，音頻與視頻數據傳輸互相干擾，導致用戶觀看的視頻卡頓，影響觀看體驗。

本申請實施例的一個方面提供了一種音視頻數據傳輸方法，應用于發送端，所述發送端與接收端之間建立基于QUIC協議的連接，所述基于QUIC協議的連接包含多個傳輸流，所述方法包括：

對待傳輸的音視頻流數據進行解封裝得到多種類型的源數據；

根據每一類所述源數據的類型進行封裝，得到支持預設協議的目標數據報文；

從所述多個傳輸流中確定與所述目標數據報文的類型匹配的目標傳輸流，并通過所述目標傳輸流將所述目標數據報文傳輸至所述接收端。

可選地，所述根據每一類所述源數據的類型進行封裝，得到支持預設協議的目標數據報文，包括：

在所述源數據中封裝基于所述預設協議的頭部數據；其中，所述基于所述預設協議的頭部數據包含類型字段；

根據所述源數據對應的類型配置所述類型字段的值，得到支持預設協議的目標數據報文。

可選地，所述基于所述預設協議的頭部數據還包含可變長度的格式字段，可變長度字段和時間戳字段；

所述根據每一類所述源數據的類型進行封裝，得到支持預設協議的目標數據報文，還包括：

確定所述源數據的長度，并根據所述源數據的長度配置所述可變長度的格式字段的值和可變長度字段的值；及，

確定所述源數據在所述音視頻流數據中對應的時間戳，并根據所述時間戳配置所述時間戳字段的值。

可選地，所述可變長度的格式字段和類型字段的字節長度之和為一個字節，所述時間戳的字節長度為四個字節，所述可變長度的格式字段用于指示所述可變長度字段對應的字節數。

可選地，所述根據所述源數據的長度配置所述可變長度的格式字段的值和可變長度字段的值，包括：

根據所述源數據的長度配置所述可變長度字段的值，并根據所述可變長度字段的值確定所述可變長度字段對應的字節數；