問：近些年，隨著智能駕駛技術(shù)的發(fā)展和車內(nèi)影音娛樂系統(tǒng)的豐富，越來越多的音視頻數(shù)據(jù)需要在車內(nèi)網(wǎng)絡(luò)進(jìn)行傳輸?，F(xiàn)在車載以太網(wǎng)日漸成熟，那么，我們可以使用車載以太網(wǎng)在車內(nèi)網(wǎng)絡(luò)傳輸音視頻數(shù)據(jù)嗎？
答：答案是肯定的。而且由于成本、傳輸帶寬等方面的因素，在有些場景下，也許只有車載以太網(wǎng)才能滿足我們的傳輸需求。
問：既能傳輸普通數(shù)據(jù)又能傳輸音視頻數(shù)據(jù)，感覺很方便啊。那么，傳輸音視頻數(shù)據(jù)和其他普通數(shù)據(jù)采用的傳輸協(xié)議相同嗎？
答：是不同的，網(wǎng)絡(luò)上有專門適用音視頻傳輸?shù)膮f(xié)議。目前，在車載以太網(wǎng)中常用的方案有兩個(gè)，分別是RTP和AVB。
? RTP（Real-time Transport Protocol），實(shí)時(shí)傳輸協(xié)議，采用RTP和RTCP（Real-time Transport Control Protocol，實(shí)時(shí)傳輸控制協(xié)議）兩個(gè)子協(xié)議實(shí)現(xiàn)音視頻數(shù)據(jù)的傳輸，遵循的標(biāo)準(zhǔn)為RFC 3550。
? AVB（Audio Video Bridging），音視頻橋接技術(shù)，采用 IEEE 1722，IEEE 802.1AS，IEEE 802.1Qav, IEEE 802.1Qat等一系列 IEEE 標(biāo)準(zhǔn)，通過保證帶寬、控制傳輸延時(shí)、時(shí)鐘同步等功能和機(jī)制實(shí)現(xiàn)音視頻數(shù)據(jù)在網(wǎng)絡(luò)上的實(shí)時(shí)傳輸。
這里要注意的是，不管采用哪種技術(shù)，這里所傳輸?shù)挠行лd荷數(shù)據(jù)（payload）是一樣的，都是音視頻媒體數(shù)據(jù)（e.g. H.264），不同的是所采用的傳輸方式。
問：那么具體應(yīng)該選擇哪種方案呢，或者說什么時(shí)候用RTP，什么時(shí)候用AVB呢？
答：這個(gè)取決于網(wǎng)絡(luò)架構(gòu)，應(yīng)用場景和成本等因素，需要具體問題具體分析。RTP的機(jī)制相對(duì)比較簡單，而AVB的機(jī)制會(huì)復(fù)雜一些。下面我們?cè)敿?xì)介紹一下。
下圖是OSI網(wǎng)絡(luò)模型，左邊是AVB架構(gòu)，右邊是基于TCP/IP的傳統(tǒng)架構(gòu)。
我們可以看到RTP協(xié)議位于模型的5至7層，底層為傳輸層，在RFC 3550中推薦使用UDP為其底層傳輸協(xié)議，有的同學(xué)可能知道IEEE 1733，（一份將RTP協(xié)議和AVB相關(guān)機(jī)制整合使用的標(biāo)準(zhǔn)），但由于過于小眾，今天這里就不過多介紹了。RTP協(xié)議本身沒有連接的概念，為端到端的傳輸模式，無法保證數(shù)據(jù)的傳輸質(zhì)量。我們知道在復(fù)雜的網(wǎng)絡(luò)環(huán)境中，采用UDP傳輸?shù)臄?shù)據(jù)有可能出現(xiàn)丟包的情況，RTP可以借助RTCP提供的傳輸質(zhì)量反饋信息，調(diào)整數(shù)據(jù)發(fā)送行為，從而盡可能的保障傳輸服務(wù)。但是，如果車內(nèi)網(wǎng)絡(luò)環(huán)境簡單，通過合理的設(shè)計(jì)，我們可以規(guī)避傳輸過程中有可能出現(xiàn)的種種問題，從而使用RTP在車內(nèi)進(jìn)行音視頻數(shù)據(jù)傳輸。
比如下面的應(yīng)用場景：
Figure 1
攝像頭和顯示屏直連，攝像頭采集視頻數(shù)據(jù)，通過以太網(wǎng)傳輸至顯示屏，顯示屏實(shí)時(shí)顯示攝像頭所捕獲到的視頻畫面。類似這樣一對(duì)一直連的網(wǎng)絡(luò)拓?fù)洌绻@條鏈路上的帶寬充裕，可以直接使用RTP進(jìn)行音視頻傳輸。
問：感覺RTP很簡單啊，是不是直連的網(wǎng)絡(luò)拓?fù)?，一般都可以使用RTP進(jìn)行傳輸呢？
答：是的，可以這么說。如果不是直連，但場景中Switch節(jié)點(diǎn)轉(zhuǎn)發(fā)延時(shí)可控，在鏈路帶寬充裕的情況下，RTP一般也都可以滿足傳輸需求。
問：了解了，那網(wǎng)絡(luò)環(huán)境復(fù)雜就需要使用AVB嗎？
答：和RTP相比，在OSI模型中，我們可以看到AVB的一系列協(xié)議是直接基于數(shù)據(jù)鏈路層進(jìn)行傳輸?shù)?，簡單的層?jí)架構(gòu)，使數(shù)據(jù)的處理時(shí)間更加可控。AVB共有四個(gè)子協(xié)議，分別是：
? IEEE1722，音視頻傳輸協(xié)議AVTP
? IEEE 802.1AS，時(shí)間同步協(xié)議gPTP
? IEEE 802.1Qav，時(shí)間敏感數(shù)據(jù)轉(zhuǎn)發(fā)和隊(duì)列優(yōu)化協(xié)議FQTSS
? IEEE 802.1Qat，流預(yù)留協(xié)議SRP
我們通過下面的場景具體介紹下AVB技術(shù)的應(yīng)用情況：
Figure 2
如圖所示，車內(nèi)網(wǎng)絡(luò)中攝像頭、顯示屏、ECU1和ECU2通過Switch相互連接，同時(shí)，攝像頭、ECU1和ECU2均有與顯示屏通信的需求。如果ECU1和ECU2有突發(fā)的數(shù)據(jù)需要發(fā)送至顯示屏，那么Switch和顯示屏之間的鏈路帶寬就會(huì)被大量占用，導(dǎo)致攝像頭的視頻數(shù)據(jù)無法準(zhǔn)確傳輸。其次，我們知道車載以太網(wǎng)傳輸路徑上的延時(shí)主要來自于Switch的轉(zhuǎn)發(fā)延時(shí)，如果有大量數(shù)據(jù)在Switch隊(duì)列中等待，網(wǎng)絡(luò)就會(huì)出現(xiàn)擁塞，導(dǎo)致延時(shí)，從而影響數(shù)據(jù)的傳輸質(zhì)量。以上場景，想要實(shí)現(xiàn)實(shí)時(shí)視頻傳輸，有兩個(gè)問題需要解決：其一是保證鏈路的傳輸帶寬；其二是要控制Switch的轉(zhuǎn)發(fā)延時(shí)。
這種情況下，基于UDP的RTP傳輸就很難滿足需求了，需要AVB技術(shù)來解決這些問題。首先要獲取多流并發(fā)時(shí)各個(gè)數(shù)據(jù)流量的所需帶寬并靜態(tài)配置，其次再將數(shù)據(jù)劃分出不同優(yōu)先級(jí)，保證高優(yōu)先級(jí)數(shù)據(jù)優(yōu)先轉(zhuǎn)發(fā)。AVB中，F(xiàn)QTSS可以通過基于信用的轉(zhuǎn)發(fā)方式（CBS，credit-based shaper），在保證高優(yōu)先級(jí)數(shù)據(jù)轉(zhuǎn)發(fā)的同時(shí)，也可以轉(zhuǎn)發(fā)其他低優(yōu)先級(jí)數(shù)據(jù)。優(yōu)先級(jí)可劃分為SR class A，SR class B等級(jí)別，在這個(gè)場景中，如果視頻數(shù)據(jù)的優(yōu)先級(jí)較高，可以將其劃分為SR class A，在7跳之內(nèi)，SR class A數(shù)據(jù)默認(rèn)的相對(duì)很長傳輸時(shí)間僅為毫秒級(jí)別，可以滿足實(shí)時(shí)視頻傳輸?shù)男枨?。通過以上方法，場景中的帶寬和延時(shí)問題都可以用AVB技術(shù)解決，進(jìn)而就可以實(shí)現(xiàn)流暢的視頻數(shù)據(jù)傳輸了。
通過以上應(yīng)用實(shí)例，我們簡單的介紹了RTP和AVB兩種在車內(nèi)網(wǎng)絡(luò)傳輸音視頻數(shù)據(jù)的方案。如果網(wǎng)絡(luò)環(huán)境簡單，有足夠的傳輸帶寬，那么基于TCP/IP架構(gòu)的RTP可以直接滿足端到端的音視頻傳輸需求，簡單方便，性價(jià)比高。但是如果車內(nèi)音視頻數(shù)據(jù)的傳輸路徑上有一個(gè)或多個(gè)Switch節(jié)點(diǎn)，存在多流并發(fā)的場景，或者有時(shí)鐘同步的需求，就需要借助AVB技術(shù)中的gPTP，F(xiàn)QTSS，AVTP等技術(shù)和機(jī)制才能實(shí)現(xiàn)穩(wěn)定的實(shí)時(shí)音視頻數(shù)據(jù)傳輸。具體使用哪種方案，是使用所有機(jī)制還是選擇性使用，還需要根據(jù)車型和應(yīng)用場景，具體案例具體分析，借助時(shí)間分析工具進(jìn)行仿真優(yōu)化，才能呈現(xiàn)出良好的傳輸效果。
