• <strike id="ocqkc"><acronym id="ocqkc"></acronym></strike>
  • <abbr id="ocqkc"></abbr>
  • <abbr id="ocqkc"></abbr>
  • 小鵬汽車官網
    當前位置:首頁 > 資訊 > 技術 > 正文

    基于典型的車載以太網框架,簡介流媒體如何傳輸及其總體架構和流程

    發布日期:瀏覽量:4854

    導讀:隨著汽車智能化和網聯化的發展,流媒體在汽車上的應用也越來越多。例如流媒體后視鏡就是通過后向攝像頭獲取數據處理后再播放給駕駛員看。智能駕駛功能也越來越多地把感知和規控信息渲染處理后傳輸給車載大屏播放。

    一、什么是流媒體?

    流媒體這個術語,相信對生長于網絡時代的我們來說,都不陌生。抽象一點說,流媒體就是在線觀看,而以前通過光碟或者完整下載才能觀看的則是傳統媒體。

    具體一點來說,流媒體(streaming media)是指將一連串的媒體數據壓縮后,經過網上分段發送數據,在網上即時傳輸影音以供觀賞的一種技術與過程。

    相信體驗過在線觀看和視頻電話的我們,都能理解到流媒體實時性和交互性強的優點。而隨著汽車智能化和網聯化的發展,流媒體在汽車上的應用也越來越多。例如流媒體后視鏡就是通過后向攝像頭獲取數據處理后再播放給駕駛員看。智能駕駛功能也越來越多地把感知和規控信息渲染處理后傳輸給車載大屏播放。                           

    圖1:雷克薩斯電子后視鏡 

    二、視頻傳輸基本術語

    在進一步分析視頻傳輸技術之前,我們從下面兩張IPhone相機設置界面出發,看看幾個視頻相關的術語。 

    圖2:IPhone視頻設置截圖 

    圖3:IPhone相機格式設置截圖

    1、視頻的分辨率

    指視頻在一定區域內包含的像素點的數量。單位“P”(Progressive)表示縱向有多少行像素,“k”則表示橫向有多少千像素。例如720P表示縱向有720行像素,而4k就是視頻橫向大約有4000列像素。

    按通常的橫縱比例定義:

    720P的分辨率為1280x720像素

    1080P的分辨率為1920*1080像素

    2k的分辨率為2560*1440像素

    4k的分辨率為3840*2160像素

    2、幀率

    指1秒內連續播放多少個畫面。一般達到每秒播放24個畫面就有動畫效果。幀率的單位是“fps”,常見的有24fps、30fps、60fps。幀率越高視頻播放起來會越流暢,但幀率越高,對設備要求也越高。

    3、視頻編碼解碼

    我們平時看到的視頻、圖片和音頻等大部分都是通過壓縮處理的。Codec編碼解碼器主要作用是對視頻信號進行壓縮和解壓縮。計算機工業定義通過24位測量系統的真彩色,這就定義了近百萬種顏色,接近人類視覺的極限。這意味著如果視頻需要以每秒30幀的速度播放,則每秒要傳輸高達27MB的信息。因而必須對信息進行壓縮處理,例如只記錄一幀完整畫面及其后幀與幀之間的差異部分,而不是每幀記錄全畫幅。

    我們常在播放視頻時看到的H264、H265就是編解碼格式。H265比H264更加新,壓縮效率也更高,但需要專用的硬件解碼器,因而可能不能在舊的設備上播放。IPhone相機拍攝格式選擇的“高效”其實就是H265,“兼容性最佳”其實就是H264。當然類似地,音頻也有編碼解碼,例如常見的MP3就是一種編碼(壓縮)格式。 

    三、流媒體傳輸總體架構

    接下來我們就結合典型的車載以太網來一起看看這個流媒體傳輸過程的總體架構和流程。下圖是兩個控制器之間視頻流傳輸的架構示意圖,例如其中一個可以是智能駕駛域控制器,另一個是智能座艙域控制器。 


    圖4:車載以太網視頻傳輸架構圖

    智駕域控渲染后的視頻通過特定編碼器后生成原始視頻流,然后封裝打包成PES流,然后再裝載到MPEG-TS的容器中,打包成TS流。TS流再通過RTP協議傳輸。在網絡傳輸上,RTP向下通過UDP、IP多層協議,完成以太網的傳輸。智能座艙域控制器收到以太網幀后,會逆向地對其進行分級組包拆包,解析出RTP報文,繼而是TS流和PES流。然后再把視頻流送進解碼器進行解壓縮和播放。

    而與視頻流平行傳輸的還有一路控制流通過RTCP協議傳輸。RTCP 提供數據分發質量反饋信息報告,接收端可以根據RTCP中的傳輸質量信息,反饋給上層應用端,以調整傳輸質量,例如網絡質量差的時候就不傳4k視頻,而改成傳720p。

    通過上述架構和總體流程的介紹可以看出,流媒體與本地存儲多媒體的一個本質區別是流媒體需要進行網絡傳輸后播放。例如在汽車上,激光雷達和攝像頭等傳感器會提供原始數據給智能駕駛域控制器,域控制器完成傳感器同步融合等處理后再渲染出表示周圍環境的視頻,甚至制作音頻,然后再將音視頻同時傳輸給車機在中控屏幕上播放。

    傳輸過程中,音視頻需要在控制器之間傳輸。傳輸下層協議的UDP、IP等都是通用的以太網傳輸協議和標準,而RTP/RTCP則是在以太網傳輸基礎上針對流媒體傳輸的關鍵協議。

    下文將對PES、TS和RTP/RTCP協議作進一步詳細介紹,希望對從事車載流媒體傳輸相關領域的同仁有所幫助。而如果只想了解車載流媒體以太網傳輸的基本概念,那就可以跳過接下來枯燥的傳輸協議介紹了。 

    四、PES和TS流

    編碼器里出來的原始音視頻裸流就是ES(Elementary Stream)流,ES流只包含一種音頻或者視頻。

    1、ES的第一次封裝:PES

    PES (Packetized Elementary Stream)流是ES流經過PES打包器處理后形成的數據流,在這個過程中完成了將ES流分組、打包、加入Header信息等操作。PES流的基本單位是PES包。PES包由Header和Payload組成。Payload部分組合起來就是原始的ES流,并不會修改ES的內容。一個PES包的最大長度是65535個字節。第一層封裝的主要目的是豐富傳輸流的信息。 

    2、ES的第二次封裝:MPEG-TS

    MPEG-TS,也稱MTS或TS(transport stream),是一種標準容器格式,是對PES包的進一步封裝。它主要用來傳輸和(傳輸過程中)存儲音頻、視頻和節目系統信息等。TS包的長度是188字節,4字節頭,184字節payload。所以一個PES包可能會被封裝成多個TS包。一個PES包必須由整數個TS包傳輸,如果承載一個PES包的最后一個TS包沒有被裝滿,則用填充字節進行填充。第二層封裝的目的是規范化傳輸的最小單元,保證傳輸的可靠性,以適應不太可靠的傳輸。

    TS包都是分為包頭 TS Header和TS Payload有效載荷部分,其中有效負載可以填入音頻、視頻、和節目映射表等其它形式數據。TS流可以理解為一個大的管道,里面傳輸的TS包可能會屬于不同的PES流,而TS Header中的PID則是用來識別PES流的關鍵字段。在TS流中找出相同PID的TS包,按順序排列,一般是如下圖所示的結構。第一個TS包的Payload里包含了PESHeader,最后一個TS包的Payload里包含了空位填充,以保證TS包188字節的固定長度。 

    圖5:典型的PES包封裝成TS包的示意圖

    五、RTP傳輸協議

    RTP全稱是Real-time Transport Protocol,實時傳輸協議,是一個網絡傳輸協議。它詳細說明了在以太網上傳遞音頻和視頻的標準數據包格式。RTP協議和RTP控制協議(RTCP)往往一起使用,而且它是創建在UDP協議上的。廣義的RTP標準其實包含了RTP和RTCP兩個子協議。所以當我們平時討論RTP的時候也要注意背景和語境,確認討論的是廣義的RTP還是狹義的RTP。下文用“RTP子協議”指示狹義,其余均是廣義。

    RTP為數據提供了具有實時特征的端對端傳送服務,如在組播或單播網絡服務下的交互式視頻音頻或模擬數據。應用程序通常在 UDP 上運行 RTP 以便使用其多路節點和校驗服務。

    分層協議的好處是能各司其職,高效應對復雜的傳輸問題。RTP 本身并沒有提供按時發送機制或其它服務質量(QoS)保證,它依賴于底層協議去實現這一過程。RTP 并不保證傳送或防止無序傳送,也不確定底層網絡的可靠性。

    下圖是基于以太網幀、RTP包和TS包的示意圖。與其他以太網通訊協議一樣,其報文頭包含了關鍵的媒體傳輸信息,也是該層協議的特征所在。 

    圖6:以太網幀、RTP包和TS包關系的示意圖

    下表對應的是RTP子協議Header。前12字節(即頭3行)是必填字段。

    表1:RTP子協議Header格式

    其中各個字段的含義:

    V:RTP協議的版本號,占2位,當前協議版本號為2。 

    P:填充標志,占1位,如果P=1,則在該報文的尾部填充一個或多個額外的八位組,它們不是有效載荷的一部分。

    X:擴展標志,占1位,如果X=1,則在RTP子協議報頭后跟有一個擴展報頭。

    CC:CSRC計數器,占4位,指示CSRC 標識符的個數。CSRC可以理解為音視頻的來源,例如一個RTP子協議包中包含了來自于兩個視頻來源的數據,則CC是2。下面的CSRC identifier也有2個。

    M: 標記,占1位,不同的有效載荷有不同的含義,對于視頻,標記一幀的結束;對于音頻,標記會話的開始。

    Payload Type:有效載荷類型,占7位,用于說明RTP子協議報文中有效載荷的類型,例如H263的視頻是34。而由于H264出現的比RTP的定義晚,一般H264的Payload Type都定義為RTP子協議保留號段中的96。

    Sequencenumber:序列號,占16位,用于標識發送者所發送的RTP子協議報文的序列號,每發送一個報文,序列號增1。接收者通過序列號來檢測報文丟失情況,重新排序報文,恢復數據。

    Timestamp:時間戳,占32位,時戳反映了該RTP子協議報文的第一個八位組的采樣時刻。接收者使用時戳來計算延遲和延遲抖動,并進行同步控制。

    SSRC identifier:同一個RTP會話中同步信源標識符,占32位,用于標識同步過的信源。

    CSRC identifier:特約信源標識符,每個CSRC標識符占32位,可以有0~15個。每個CSRC標識了包含在該RTP子協議報文有效載荷中的所有特約信源。CC中定義了RTP子協議包中有幾個信源,這個部分則定義了每個信源的ID。

    來源:焉知智能汽車 作者:一驥絕塵

    版權說明:“華夏EV網”轉載作品均注明出處,本網未注明出處和轉載的,是出于傳遞更多信息之目的,并不意味著贊同其觀點或證實其內容的真實性。如轉作品侵犯署名權,或有其他諸如版權、肖像權、知識產權等方面的傷害,并非本網故意為之,在接到相關權利人通知后將立即加以更正。

    文章標簽:

    本文網址:http://www.mgsoxford.com/newsshow-659.html

    分享到:
    相關文章
    查看更多
    亚洲av中文无码乱人伦在线咪咕| 亚洲一区中文字幕久久| 亚洲国产精品成人精品无码区在线| 中文字幕无码日韩专区免费| 亚洲乱亚洲乱少妇无码| 高潮潮喷奶水飞溅视频无码| 乱人伦人妻中文字幕无码| 无码精品尤物一区二区三区| 久久伊人中文无码| 中中文字幕亚洲无线码| 国产又爽又黄无码无遮挡在线观看| 中文字幕无码第1页| 国产免费久久久久久无码| 亚洲精品无码Av人在线观看国产| 777久久精品一区二区三区无码| 久久无码人妻精品一区二区三区| 东京热无码av一区二区| 最新中文字幕在线视频| 国产成人AV片无码免费| 精品欧洲av无码一区二区14| 国产激情无码一区二区三区| 免费VA在线观看无码| 中文字幕无码乱人伦| 天堂中文在线最新版| 亚洲AV无码AV男人的天堂| 国产午夜无码片免费| 精品少妇人妻av无码久久| 熟妇人妻系列av无码一区二区| 亚洲国产精品狼友中文久久久| 97无码免费人妻超级碰碰夜夜| 亚洲午夜无码AV毛片久久| 国产成人无码免费网站| 国产亚洲精久久久久久无码77777| 最近中文字幕mv免费高清视频8| 久久99精品久久久久久hb无码| 亚洲成A∨人片天堂网无码| 无码视频在线观看| 中文字幕在线看视频一区二区三区| 999久久久无码国产精品| 精品多人p群无码| 亚洲AV无码AV男人的天堂不卡|