車(chē)載以太網(wǎng) 車(chē)載以太網(wǎng)的大規(guī)模應(yīng)用，實(shí)際上是隨著汽車(chē)的電動(dòng)化，智能化發(fā)展而來(lái)的。在分布式的EEA時(shí)代，各ECU之間需要相互傳輸?shù)?a target="_blank">信號(hào)量極少，使用CAN總線(xiàn)即可實(shí)現(xiàn)互聯(lián)。當(dāng)汽車(chē)進(jìn)入智能化時(shí)代，EEA架構(gòu)向中央計(jì)算-區(qū)域控制方向演進(jìn)。由于汽車(chē)內(nèi)使用的傳感器越來(lái)越多，傳輸?shù)臄?shù)據(jù)量越來(lái)越大，所需帶寬也越來(lái)越多，因此需要有新的網(wǎng)絡(luò)互聯(lián)技術(shù)來(lái)支撐這一變化。為了滿(mǎn)足中央計(jì)算機(jī)與區(qū)域控制器之間的互聯(lián)要求，車(chē)載以太網(wǎng)被認(rèn)為是一個(gè)合適的解決方案。

如上圖所示，各個(gè)域控制器之間采用ETH車(chē)載以太網(wǎng)進(jìn)行連接，而域控制器內(nèi)部則還是采用星型架構(gòu)。為了保證ETH傳輸?shù)目煽?，還要求多個(gè)域控制器之間的ETH進(jìn)行互聯(lián)，組成以太環(huán)網(wǎng)。由于ECU演進(jìn)的程度不統(tǒng)一，它們所采用的互聯(lián)技術(shù)，可能有CAN，CAN-FD，LIN，F(xiàn)lexRay等各種總線(xiàn)。而對(duì)于Camera,?顯示屏等多媒體設(shè)備來(lái)說(shuō)，所傳輸?shù)臄?shù)據(jù)量特別大，還需要采用特殊的串行-解串器進(jìn)行連接。

上圖所展示的還是集成式域控制器架構(gòu)。整車(chē)電子電氣架構(gòu)按功能進(jìn)行劃分，分為車(chē)身域，ADAS域，信息娛樂(lè)域，底盤(pán)域，動(dòng)力域等，各域控制器之間依賴(lài)中央網(wǎng)關(guān)進(jìn)行互聯(lián)。而對(duì)于中央集成-區(qū)域控制架構(gòu)來(lái)說(shuō)，以上的各域控制器將集中到一個(gè)中央計(jì)算機(jī)內(nèi)部。各個(gè)ECU，仍然使用CAN，LIN，F(xiàn)lexRay等技術(shù)。它們按汽車(chē)物理區(qū)域的劃分，分別掛載到不同位置的Zone區(qū)域控制器下。此時(shí)Zone起到了一個(gè)中繼節(jié)點(diǎn)的作用，提供了以太網(wǎng)到其他總線(xiàn)的轉(zhuǎn)發(fā)功能，如下圖所示。

? 高速視頻傳輸(FPD-Link)

為了滿(mǎn)足智能網(wǎng)聯(lián)汽車(chē)對(duì)多傳感器的需求，需要有高速視頻傳輸總線(xiàn)來(lái)將這些傳感器連接到中央計(jì)算機(jī)上。這些傳感器一般為視覺(jué)攝像頭或者大型液晶顯示屏等。它們對(duì)通信的要求是，高帶寬，低時(shí)延。通信連接類(lèi)型一般是點(diǎn)到點(diǎn)的方式。例如用于高級(jí)自動(dòng)輔助駕駛ADAS系統(tǒng)的攝像頭，一般為5M的?Camera Sensor，它所需要的傳輸帶寬高達(dá)?2.5Gbps，而這樣的攝像頭全車(chē)需要10多個(gè)。目前的車(chē)載以太網(wǎng)技術(shù)根本承載不了這樣的帶寬需求，因此只能考慮專(zhuān)用點(diǎn)到點(diǎn)的連接方式。

如下圖所示，攝像頭和顯示屏，都通過(guò)專(zhuān)用的高速視頻傳輸接口連接到中央計(jì)算平臺(tái)上。其中智能座艙域控制器需要連接的是座艙內(nèi)部攝像頭(輸入)和座艙內(nèi)的顯示屏(輸出)。其中可能會(huì)使用到不同類(lèi)型的傳輸接口以及線(xiàn)纜。

車(chē)載高速音視頻傳輸接口還有另外一個(gè)特殊的需求，即長(zhǎng)距離傳輸和車(chē)內(nèi)電磁兼容性設(shè)計(jì)EMC(Electro Magnetic Compatibility)。相比起個(gè)人消費(fèi)類(lèi)電子設(shè)備，車(chē)載傳感器所使用的連接接口工作環(huán)境可謂惡劣。首先是要考慮3-10米的傳輸距離。一個(gè)攝像頭或者一個(gè)顯示屏，與車(chē)載中央計(jì)算平臺(tái)的物理距離，短則1至3米，長(zhǎng)則可達(dá)10米，一般的數(shù)據(jù)接口根本無(wú)法滿(mǎn)足這樣長(zhǎng)的傳輸距離。另一方面，車(chē)內(nèi)工作環(huán)境復(fù)雜，溫度高，電磁干擾大，數(shù)據(jù)傳輸距離增加會(huì)帶來(lái)信號(hào)的衰減。因此，需要有專(zhuān)門(mén)的數(shù)據(jù)傳輸技術(shù)來(lái)滿(mǎn)足車(chē)內(nèi)高速音視頻傳輸?shù)男枨蟆?/p>

攝像頭或者顯示屏上傳輸?shù)?a target="_blank">視頻信號(hào)，一般都是RGB、YUV、或者raw data等圖像格式的數(shù)據(jù)。按圖像的數(shù)據(jù)特點(diǎn)來(lái)看，每個(gè)像素都由多個(gè)bit組成。在最初的圖像傳輸接口中，采用高速并行接口來(lái)傳輸數(shù)據(jù)。但這樣帶來(lái)的問(wèn)題是接插件的針數(shù)多，尺寸大，傳輸線(xiàn)纜的重量，成本都會(huì)很高；線(xiàn)束的安裝成本也很高，長(zhǎng)距離傳輸?shù)恼`碼率相當(dāng)高，導(dǎo)致傳輸帶寬受限。

因此，采用串行傳輸是代替這種并行傳輸?shù)挠行Ы鉀Q方法。通過(guò)把發(fā)送端的多條并行數(shù)據(jù)（包括視頻和控制、語(yǔ)音等數(shù)據(jù)）轉(zhuǎn)換成單條的串行數(shù)據(jù)，在接收端再把串行的數(shù)據(jù)轉(zhuǎn)換恢復(fù)成并行視頻格式和低速控制信號(hào)，就能有效解決上文所提的“高帶寬，低時(shí)延，長(zhǎng)距離”傳輸?shù)膯?wèn)題。

首先要解釋一下并行傳輸轉(zhuǎn)換為串行傳輸?shù)脑?。要想?shí)現(xiàn)長(zhǎng)距離的高速傳輸，LVDS是一種可行的技術(shù)，即低壓差分信號(hào)(Low-Voltage Differential Signaling)。它是一種低功耗，低誤碼率，低串?dāng)_和低輻射的差分信號(hào)傳輸技術(shù)。它通常需要通過(guò)一對(duì)信號(hào)線(xiàn)，以極低的電壓擺幅高速差動(dòng)來(lái)傳輸數(shù)據(jù)。

FPD-Link是基于LVDS物理層之上的一種通信標(biāo)準(zhǔn)。它的英文全稱(chēng)是Flat Panel Display Link，是美國(guó)國(guó)家半導(dǎo)體公司(后被德州儀器TI公司收購(gòu))于1996年提出的。FPD-Link I代芯片組將寬并行的RGB總線(xiàn)串行化為4或5對(duì)LVDS信號(hào)。如下圖所示：21根并行信號(hào)線(xiàn)串行化為4對(duì)LVDS信號(hào)，其中3對(duì)數(shù)據(jù)線(xiàn)，1對(duì)時(shí)鐘線(xiàn)。

到了FPD-Link III的時(shí)代，TI?停止使用?LVDS?模式，而改為CML模式。它通過(guò)一對(duì)屏蔽雙絞線(xiàn)(STP)或者一根同軸電纜(Coax)即可傳輸高速串行信號(hào)。它可以實(shí)現(xiàn)在10米的距離上傳輸6Gbps的數(shù)據(jù)。通過(guò)增加一對(duì)串行和解串器，在傳輸線(xiàn)上可以實(shí)現(xiàn)高速正向通道和低速反向通道。

正向傳輸通道用于以最小的延遲將串行化視頻、音頻或其他數(shù)據(jù)發(fā)送到端點(diǎn)設(shè)備。為了實(shí)現(xiàn)這一點(diǎn)，串行器必須重新格式化其傳入的數(shù)據(jù)并嵌入數(shù)據(jù)時(shí)鐘，以便可以使用更少的導(dǎo)體將其輸出。通過(guò)利用專(zhuān)有的回聲消除技術(shù)，F(xiàn)PD-Link?串行器/解串器還允許通過(guò)一個(gè)物理導(dǎo)體進(jìn)行全雙工通信。

當(dāng)高速數(shù)據(jù)沿正向方向從串行器傳輸?shù)浇獯鲿r(shí)，低速數(shù)據(jù)也同時(shí)傳輸回到串行器，而無(wú)需時(shí)分復(fù)用。?FPD-Link?串行器和解串器設(shè)備通過(guò)在鏈路的每一端連續(xù)抵消其自己的傳輸信號(hào)來(lái)自動(dòng)建立該雙向通道。反向通道通常以比正向通道數(shù)據(jù)低得多的速度運(yùn)行，以便于在兩側(cè)實(shí)現(xiàn)適當(dāng)?shù)姆蛛x，并且可以包含有關(guān)同步設(shè)備的信息、觸摸中斷、控制信號(hào)、狀態(tài)信息等。

使用同步反向通道通信，還可以在鏈路上沿正向或反向方向啟用?I2C?訪(fǎng)問(wèn)或?GPIO?傳輸。為了補(bǔ)償通道插入損耗（該損耗可能很大，具體取決于運(yùn)行速度以及所用電纜的類(lèi)型或長(zhǎng)度）FPD-Link?解串器利用多種均衡技術(shù)來(lái)恢復(fù)高頻信號(hào)成分并減輕碼間串?dāng)_、反射或外部噪聲產(chǎn)生的影響。

高速視頻信號(hào)從串行器傳輸?shù)浇獯鞯倪^(guò)程中經(jīng)過(guò)PCB走線(xiàn)、連接器和線(xiàn)束，這些傳輸介質(zhì)都會(huì)衰減信號(hào)幅度，增加信號(hào)噪聲，而且頻率越高，被影響的程度越大。如下圖所示，串行器的輸出數(shù)據(jù)的眼圖為左邊第一幅圖所示，比較清晰、干凈。經(jīng)過(guò)傳輸線(xiàn)以后，眼圖閉合，如中間第二幅圖所示。為了補(bǔ)償傳輸介質(zhì)對(duì)信號(hào)的惡化，F(xiàn)PD Link?器件提供了Equalizer均衡器模塊。這個(gè)模塊放大補(bǔ)償輸入信號(hào)，且對(duì)信號(hào)高頻部分補(bǔ)償?shù)酶?，以此?lái)部分抵消傳輸通道對(duì)信號(hào)的影響。通過(guò)Equalizer之后，輸入信號(hào)的眼圖重新張開(kāi)，如右邊第三幅圖所示。

由于FPD Link需要適應(yīng)不同類(lèi)型不同長(zhǎng)度的線(xiàn)束，所以均衡器的高頻增益值分多個(gè)等級(jí)，芯片會(huì)自動(dòng)檢測(cè)輸入信號(hào)的質(zhì)量，自適應(yīng)地設(shè)置最佳的均衡值，這個(gè)自適應(yīng)模塊叫AEQ。該模塊在解串器每次上電時(shí)做一次自適應(yīng)補(bǔ)償，所以即便線(xiàn)束存在老化、溫漂、線(xiàn)束個(gè)體差異等實(shí)際差異時(shí)，AEQ?都能夠自動(dòng)選擇出最佳的補(bǔ)償?shù)燃?jí)。另外，技術(shù)人員也可以讀取上電以后的AEQ?的補(bǔ)償值，如果明顯高于正常值，可以判斷當(dāng)前傳輸通道可能存在短路、松動(dòng)、彎曲等異常情況。

AEQ內(nèi)還集成有CDR（Clock Data Recovery）電路，集成的鎖相環(huán)電路鎖定輸入數(shù)據(jù)Incoming Data并輸出降噪以后的較干凈的同頻率時(shí)鐘Recovered Clock；同時(shí)這個(gè)干凈時(shí)鐘做為新的采樣時(shí)鐘，在Sampler上對(duì)輸入數(shù)據(jù)重新采樣并輸出，從而達(dá)到濾除輸入數(shù)據(jù)抖動(dòng)、降低碼間串?dāng)_、減少通道間串?dāng)_和恢復(fù)數(shù)據(jù)眼圖的功能。 ?

? 流媒體

流媒體（streaming media）是指將一連串的媒體數(shù)據(jù)壓縮后，經(jīng)過(guò)網(wǎng)上分段發(fā)送數(shù)據(jù)，在網(wǎng)上即時(shí)傳輸影音以供觀賞的一種技術(shù)與過(guò)程。隨著汽車(chē)智能化和網(wǎng)聯(lián)化的發(fā)展，流媒體在汽車(chē)上的應(yīng)用也越來(lái)越多。例如流媒體后視鏡就是通過(guò)后向攝像頭獲取數(shù)據(jù)處理后再播放給駕駛員看。智能駕駛功能也越來(lái)越多地把感知和規(guī)控信息渲染處理后傳輸給車(chē)載大屏播放。

基本術(shù)語(yǔ)

分辨率

指視頻在一定區(qū)域內(nèi)包含的像素點(diǎn)的數(shù)量。單位“P”（Progressive）表示縱向有多少行像素，“k”則表示橫向有多少千像素。例如720P表示縱向有720行像素，而4k就是視頻橫向大約有4000列像素。 ? 按通常的橫縱比例定義， 720P的分辨率為1280x720像素

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

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

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

幀率 ? 指1秒內(nèi)連續(xù)播放多少個(gè)畫(huà)面。一般達(dá)到每秒播放24個(gè)畫(huà)面就有動(dòng)畫(huà)效果。幀率的單位是“fps”，常見(jiàn)的有24fps、30fps、60fps。幀率越高視頻播放起來(lái)會(huì)越流暢，但幀率越高，對(duì)設(shè)備要求也越高。? ? ? 編碼解碼

我們平時(shí)看到的視頻、圖片和音頻等大部分都是通過(guò)壓縮處理的。Codec編碼解碼器主要作用是對(duì)視頻信號(hào)進(jìn)行壓縮和解壓縮。對(duì)信息進(jìn)行壓縮處理，例如只記錄一幀完整畫(huà)面及其后幀與幀之間的差異部分，而不是每幀記錄全畫(huà)幅。

常見(jiàn)的H264、H265就是編解碼格式。H265比H264更加新，壓縮效率也更高，但需要專(zhuān)用的硬件解碼器，因而可能不能在舊的設(shè)備上播放。IPhone相機(jī)拍攝格式選擇的“高效”其實(shí)就是H265，“兼容性最佳”其實(shí)就是H264。當(dāng)然類(lèi)似地，音頻也有編碼解碼，例如常見(jiàn)的MP3就是一種編碼（壓縮）格式。?

總體架構(gòu)

下圖是兩個(gè)控制器之間視頻流傳輸?shù)募軜?gòu)示意圖，例如其中一個(gè)可以是智能駕駛域控制器，另一個(gè)是智能座艙域控制器。 ?

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

而與視頻流平行傳輸?shù)倪€有一路控制流通過(guò)RTCP協(xié)議傳輸。RTCP?提供數(shù)據(jù)分發(fā)質(zhì)量反饋信息報(bào)告，接收端可以根據(jù)RTCP中的傳輸質(zhì)量信息，反饋給上層應(yīng)用端，以調(diào)整傳輸質(zhì)量，例如網(wǎng)絡(luò)質(zhì)量差的時(shí)候就不傳4k視頻，而改成傳720p。

通過(guò)上述架構(gòu)和總體流程的介紹可以看出，流媒體與本地存儲(chǔ)多媒體的一個(gè)本質(zhì)區(qū)別是流媒體需要進(jìn)行網(wǎng)絡(luò)傳輸后播放。例如在汽車(chē)上，激光雷達(dá)和攝像頭等傳感器會(huì)提供原始數(shù)據(jù)給智能駕駛域控制器，域控制器完成傳感器同步融合等處理后再渲染出表示周?chē)h(huán)境的視頻，甚至制作音頻，然后再將音視頻同時(shí)傳輸給車(chē)機(jī)在中控屏幕上播放。傳輸過(guò)程中，音視頻需要在控制器之間傳輸。傳輸下層協(xié)議的UDP、IP等都是通用的以太網(wǎng)傳輸協(xié)議和標(biāo)準(zhǔn)，而RTP/RTCP則是在以太網(wǎng)傳輸基礎(chǔ)上針對(duì)流媒體傳輸?shù)年P(guān)鍵協(xié)議。?

PES和TS流

編碼器里出來(lái)的原始音視頻裸流就是ES（Elementary Stream）流，ES流只包含一種音頻或者視頻。 ? ES的第一次封裝：PES。 ? PES?（Packetized Elementary Stream）流是ES流經(jīng)過(guò)PES打包器處理后形成的數(shù)據(jù)流，在這個(gè)過(guò)程中完成了將ES流分組、打包、加入Header信息等操作。PES流的基本單位是PES包。PES包由Header和Payload組成。Payload部分組合起來(lái)就是原始的ES流，并不會(huì)修改ES的內(nèi)容。一個(gè)PES包的最大長(zhǎng)度是65535個(gè)字節(jié)。第一層封裝的主要目的是豐富傳輸流的信息。

ES的第二次封裝：MPEG-TS。

MPEG-TS，也稱(chēng)MTS或TS（transport stream），是一種標(biāo)準(zhǔn)容器格式，是對(duì)PES包的進(jìn)一步封裝。它主要用來(lái)傳輸和（傳輸過(guò)程中）存儲(chǔ)音頻、視頻和節(jié)目系統(tǒng)信息等。TS包的長(zhǎng)度是188字節(jié)，4字節(jié)頭，184字節(jié)payload。所以一個(gè)PES包可能會(huì)被封裝成多個(gè)TS包。一個(gè)PES包必須由整數(shù)個(gè)TS包傳輸，如果承載一個(gè)PES包的最后一個(gè)TS包沒(méi)有被裝滿(mǎn)，則用填充字節(jié)進(jìn)行填充。第二層封裝的目的是規(guī)范化傳輸?shù)淖钚卧?，保證傳輸?shù)目煽啃?，以適應(yīng)不太可靠的傳輸。

TS包都是分為包頭?TS Header和TS Payload有效載荷部分，其中有效負(fù)載可以填入音頻、視頻、和節(jié)目映射表等其它形式數(shù)據(jù)。TS流可以理解為一個(gè)大的管道，里面?zhèn)鬏數(shù)腡S包可能會(huì)屬于不同的PES流，而TS Header中的PID則是用來(lái)識(shí)別PES流的關(guān)鍵字段。在TS流中找出相同PID的TS包，按順序排列，一般是如下圖所示的結(jié)構(gòu)。第一個(gè)TS包的Payload里包含了PESHeader，最后一個(gè)TS包的Payload里包含了空位填充，以保證TS包188字節(jié)的固定長(zhǎng)度。

RTP傳輸協(xié)議

RTP全稱(chēng)是Real-time Transport Protocol，實(shí)時(shí)傳輸協(xié)議，是一個(gè)網(wǎng)絡(luò)傳輸協(xié)議。它詳細(xì)說(shuō)明了在以太網(wǎng)上傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包格式。RTP協(xié)議和RTP控制協(xié)議（RTCP）往往一起使用，而且它是創(chuàng)建在UDP協(xié)議上的。廣義的RTP標(biāo)準(zhǔn)其實(shí)包含了RTP和RTCP兩個(gè)子協(xié)議。所以當(dāng)我們平時(shí)討論RTP的時(shí)候也要注意背景和語(yǔ)境，確認(rèn)討論的是廣義的RTP還是狹義的RTP。下文用“RTP子協(xié)議”指示狹義，其余均是廣義。

RTP為數(shù)據(jù)提供了具有實(shí)時(shí)特征的端對(duì)端傳送服務(wù)，如在組播或單播網(wǎng)絡(luò)服務(wù)下的交互式視頻音頻或模擬數(shù)據(jù)。應(yīng)用程序通常在?UDP?上運(yùn)行?RTP?以便使用其多路節(jié)點(diǎn)和校驗(yàn)服務(wù)。分層協(xié)議的好處是能各司其職，高效應(yīng)對(duì)復(fù)雜的傳輸問(wèn)題。RTP?本身并沒(méi)有提供按時(shí)發(fā)送機(jī)制或其它服務(wù)質(zhì)量（QoS）保證，它依賴(lài)于底層協(xié)議去實(shí)現(xiàn)這一過(guò)程。

RTP?并不保證傳送或防止無(wú)序傳送，也不確定底層網(wǎng)絡(luò)的可靠性。下圖是基于以太網(wǎng)幀、RTP包和TS包的示意圖。與其他以太網(wǎng)通訊協(xié)議一樣，其報(bào)文頭包含了關(guān)鍵的媒體傳輸信息，也是該層協(xié)議的特征所在。

下表對(duì)應(yīng)的是RTP子協(xié)議Header。前12字節(jié)（即頭3行）是必填字段。

其中各個(gè)字段的含義是，

V：RTP協(xié)議的版本號(hào)，占2位，當(dāng)前協(xié)議版本號(hào)為2。

P：填充標(biāo)志，占1位，如果P=1，則在該報(bào)文的尾部填充一個(gè)或多個(gè)額外的八位組，它們不是有效載荷的一部分。

X：擴(kuò)展標(biāo)志，占1位，如果X=1，則在RTP子協(xié)議報(bào)頭后跟有一個(gè)擴(kuò)展報(bào)頭。

CC：CSRC計(jì)數(shù)器，占4位，指示CSRC?標(biāo)識(shí)符的個(gè)數(shù)。CSRC可以理解為音視頻的來(lái)源，例如一個(gè)RTP子協(xié)議包中包含了來(lái)自于兩個(gè)視頻來(lái)源的數(shù)據(jù)，則CC是2。下面的CSRC identifier也有2個(gè)。

M:標(biāo)記，占1位，不同的有效載荷有不同的含義，對(duì)于視頻，標(biāo)記一幀的結(jié)束；對(duì)于音頻，標(biāo)記會(huì)話(huà)的開(kāi)始。

Payload Type：有效載荷類(lèi)型，占7位，用于說(shuō)明RTP子協(xié)議報(bào)文中有效載荷的類(lèi)型，例如H263的視頻是34。而由于H264出現(xiàn)的比RTP的定義晚，一般H264的Payload Type都定義為RTP子協(xié)議保留號(hào)段中的96。

Sequencenumber：序列號(hào)，占16位，用于標(biāo)識(shí)發(fā)送者所發(fā)送的RTP子協(xié)議報(bào)文的序列號(hào)，每發(fā)送一個(gè)報(bào)文，序列號(hào)增1。接收者通過(guò)序列號(hào)來(lái)檢測(cè)報(bào)文丟失情況，重新排序報(bào)文，恢復(fù)數(shù)據(jù)。

Timestamp：時(shí)間戳，占32位，時(shí)戳反映了該RTP子協(xié)議報(bào)文的第一個(gè)八位組的采樣時(shí)刻。接收者使用時(shí)戳來(lái)計(jì)算延遲和延遲抖動(dòng)，并進(jìn)行同步控制。

SSRC identifier：同一個(gè)RTP會(huì)話(huà)中同步信源標(biāo)識(shí)符，占32位，用于標(biāo)識(shí)同步過(guò)的信源。

CSRC identifier：特約信源標(biāo)識(shí)符，每個(gè)CSRC標(biāo)識(shí)符占32位，可以有0～15個(gè)。每個(gè)CSRC標(biāo)識(shí)了包含在該RTP子協(xié)議報(bào)文有效載荷中的所有特約信源。CC中定義了RTP子協(xié)議包中有幾個(gè)信源，這個(gè)部分則定義了每個(gè)信源的ID。 ? 審核編輯：黃飛

?