汽车高速音视频传输车载以太网解决方案

车载以太网 车载以太网的大规模应用，实际上是随着汽车的电动化，智能化发展而来的。在分布式的EEA时代，各ECU之间需要相互传输的信号量极少，使用CAN总线即可实现互联。当汽车进入智能化时代，EEA架构向中央计算-区域控制方向演进。由于汽车内使用的传感器越来越多，传输的数据量越来越大，所需带宽也越来越多，因此需要有新的网络互联技术来支撑这一变化。为了满足中央计算机与区域控制器之间的互联要求，车载以太网被认为是一个合适的解决方案。

如上图所示，各个域控制器之间采用ETH车载以太网进行连接，而域控制器内部则还是采用星型架构。为了保证ETH传输的可靠，还要求多个域控制器之间的ETH进行互联，组成以太环网。由于ECU演进的程度不统一，它们所采用的互联技术，可能有CAN，CAN-FD，LIN，FlexRay等各种总线。而对于Camera, 显示屏等多媒体设备来说，所传输的数据量特别大，还需要采用特殊的串行-解串器进行连接。

上图所展示的还是集成式域控制器架构。整车电子电气架构按功能进行划分，分为车身域，ADAS域，信息娱乐域，底盘域，动力域等，各域控制器之间依赖中央网关进行互联。而对于中央集成-区域控制架构来说，以上的各域控制器将集中到一个中央计算机内部。各个ECU，仍然使用CAN，LIN，FlexRay等技术。它们按汽车物理区域的划分，分别挂载到不同位置的Zone区域控制器下。此时Zone起到了一个中继节点的作用，提供了以太网到其他总线的转发功能，如下图所示。

  高速视频传输(FPD-Link)

为了满足智能网联汽车对多传感器的需求，需要有高速视频传输总线来将这些传感器连接到中央计算机上。这些传感器一般为视觉摄像头或者大型液晶显示屏等。它们对通信的要求是，高带宽，低时延。通信连接类型一般是点到点的方式。例如用于高级自动辅助驾驶ADAS系统的摄像头，一般为5M的 Camera Sensor，它所需要的传输带宽高达 2.5Gbps，而这样的摄像头全车需要10多个。目前的车载以太网技术根本承载不了这样的带宽需求，因此只能考虑专用点到点的连接方式。

如下图所示，摄像头和显示屏，都通过专用的高速视频传输接口连接到中央计算平台上。其中智能座舱域控制器需要连接的是座舱内部摄像头(输入)和座舱内的显示屏(输出)。其中可能会使用到不同类型的传输接口以及线缆。

车载高速音视频传输接口还有另外一个特殊的需求，即长距离传输和车内电磁兼容性设计EMC(Electro Magnetic Compatibility)。相比起个人消费类电子设备，车载传感器所使用的连接接口工作环境可谓恶劣。首先是要考虑3-10米的传输距离。一个摄像头或者一个显示屏，与车载中央计算平台的物理距离，短则1至3米，长则可达10米，一般的数据接口根本无法满足这样长的传输距离。另一方面，车内工作环境复杂，温度高，电磁干扰大，数据传输距离增加会带来信号的衰减。因此，需要有专门的数据传输技术来满足车内高速音视频传输的需求。

摄像头或者显示屏上传输的视频信号，一般都是RGB、YUV、或者raw data等图像格式的数据。按图像的数据特点来看，每个像素都由多个bit组成。在最初的图像传输接口中，采用高速并行接口来传输数据。但这样带来的问题是接插件的针数多，尺寸大，传输线缆的重量，成本都会很高；线束的安装成本也很高，长距离传输的误码率相当高，导致传输带宽受限。

因此，采用串行传输是代替这种并行传输的有效解决方法。通过把发送端的多条并行数据（包括视频和控制、语音等数据）转换成单条的串行数据，在接收端再把串行的数据转换恢复成并行视频格式和低速控制信号，就能有效解决上文所提的“高带宽，低时延，长距离”传输的问题。

首先要解释一下并行传输转换为串行传输的原理。要想实现长距离的高速传输，LVDS是一种可行的技术，即低压差分信号(Low-Voltage Differential Signaling)。它是一种低功耗，低误码率，低串扰和低辐射的差分信号传输技术。它通常需要通过一对信号线，以极低的电压摆幅高速差动来传输数据。

FPD-Link是基于LVDS物理层之上的一种通信标准。它的英文全称是Flat Panel Display Link，是美国国家半导体公司(后被德州仪器TI公司收购)于1996年提出的。FPD-Link I代芯片组将宽并行的RGB总线串行化为4或5对LVDS信号。如下图所示：21根并行信号线串行化为4对LVDS信号，其中3对数据线，1对时钟线。

到了FPD-Link III的时代，TI 停止使用 LVDS 模式，而改为CML模式。它通过一对屏蔽双绞线(STP)或者一根同轴电缆(Coax)即可传输高速串行信号。它可以实现在10米的距离上传输6Gbps的数据。通过增加一对串行和解串器，在传输线上可以实现高速正向通道和低速反向通道。

正向传输通道用于以最小的延迟将串行化视频、音频或其他数据发送到端点设备。为了实现这一点，串行器必须重新格式化其传入的数据并嵌入数据时钟，以便可以使用更少的导体将其输出。通过利用专有的回声消除技术，FPD-Link 串行器/解串器还允许通过一个物理导体进行全双工通信。

当高速数据沿正向方向从串行器传输到解串器时，低速数据也同时传输回到串行器，而无需时分复用。 FPD-Link 串行器和解串器设备通过在链路的每一端连续抵消其自己的传输信号来自动建立该双向通道。反向通道通常以比正向通道数据低得多的速度运行，以便于在两侧实现适当的分离，并且可以包含有关同步设备的信息、触摸中断、控制信号、状态信息等。

使用同步反向通道通信，还可以在链路上沿正向或反向方向启用 I2C 访问或 GPIO 传输。为了补偿通道插入损耗（该损耗可能很大，具体取决于运行速度以及所用电缆的类型或长度）FPD-Link 解串器利用多种均衡技术来恢复高频信号成分并减轻码间串扰、反射或外部噪声产生的影响。

高速视频信号从串行器传输到解串器的过程中经过PCB走线、连接器和线束，这些传输介质都会衰减信号幅度，增加信号噪声，而且频率越高，被影响的程度越大。如下图所示，串行器的输出数据的眼图为左边第一幅图所示，比较清晰、干净。经过传输线以后，眼图闭合，如中间第二幅图所示。为了补偿传输介质对信号的恶化，FPD Link 器件提供了Equalizer均衡器模块。这个模块放大补偿输入信号，且对信号高频部分补偿得更多，以此来部分抵消传输通道对信号的影响。通过Equalizer之后，输入信号的眼图重新张开，如右边第三幅图所示。

由于FPD Link需要适应不同类型不同长度的线束，所以均衡器的高频增益值分多个等级，芯片会自动检测输入信号的质量，自适应地设置最佳的均衡值，这个自适应模块叫AEQ。该模块在解串器每次上电时做一次自适应补偿，所以即便线束存在老化、温漂、线束个体差异等实际差异时，AEQ 都能够自动选择出最佳的补偿等级。另外，技术人员也可以读取上电以后的AEQ 的补偿值，如果明显高于正常值，可以判断当前传输通道可能存在短路、松动、弯曲等异常情况。

AEQ内还集成有CDR（Clock Data Recovery）电路，集成的锁相环电路锁定输入数据Incoming Data并输出降噪以后的较干净的同频率时钟Recovered Clock；同时这个干净时钟做为新的采样时钟，在Sampler上对输入数据重新采样并输出，从而达到滤除输入数据抖动、降低码间串扰、减少通道间串扰和恢复数据眼图的功能。  

  流媒体

流媒体（streaming media）是指将一连串的媒体数据压缩后，经过网上分段发送数据，在网上即时传输影音以供观赏的一种技术与过程。随着汽车智能化和网联化的发展，流媒体在汽车上的应用也越来越多。例如流媒体后视镜就是通过后向摄像头获取数据处理后再播放给驾驶员看。智能驾驶功能也越来越多地把感知和规控信息渲染处理后传输给车载大屏播放。

基本术语

分辨率

指视频在一定区域内包含的像素点的数量。单位“P”（Progressive）表示纵向有多少行像素，“k”则表示横向有多少千像素。例如720P表示纵向有720行像素，而4k就是视频横向大约有4000列像素。   按通常的横纵比例定义， 720P的分辨率为1280x720像素

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

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

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

帧率   指1秒内连续播放多少个画面。一般达到每秒播放24个画面就有动画效果。帧率的单位是“fps”，常见的有24fps、30fps、60fps。帧率越高视频播放起来会越流畅，但帧率越高，对设备要求也越高。      编码解码

我们平时看到的视频、图片和音频等大部分都是通过压缩处理的。Codec编码解码器主要作用是对视频信号进行压缩和解压缩。对信息进行压缩处理，例如只记录一帧完整画面及其后帧与帧之间的差异部分，而不是每帧记录全画幅。

常见的H264、H265就是编解码格式。H265比H264更加新，压缩效率也更高，但需要专用的硬件解码器，因而可能不能在旧的设备上播放。IPhone相机拍摄格式选择的“高效”其实就是H265，“兼容性最佳”其实就是H264。当然类似地，音频也有编码解码，例如常见的MP3就是一种编码（压缩）格式。 

总体架构

下图是两个控制器之间视频流传输的架构示意图，例如其中一个可以是智能驾驶域控制器，另一个是智能座舱域控制器。  

智驾域控渲染后的视频通过特定编码器后生成原始视频流，然后封装打包成PES流，然后再装载到MPEG-TS的容器中，打包成TS流。TS流再通过RTP协议传输。在网络传输上，RTP向下通过UDP、IP多层协议，完成以太网的传输。智能座舱域控制器收到以太网帧后，会逆向地对其进行分级组包拆包，解析出RTP报文，继而是TS流和PES流。然后再把视频流送进解码器进行解压缩和播放。

而与视频流平行传输的还有一路控制流通过RTCP协议传输。RTCP 提供数据分发质量反馈信息报告，接收端可以根据RTCP中的传输质量信息，反馈给上层应用端，以调整传输质量，例如网络质量差的时候就不传4k视频，而改成传720p。

通过上述架构和总体流程的介绍可以看出，流媒体与本地存储多媒体的一个本质区别是流媒体需要进行网络传输后播放。例如在汽车上，激光雷达和摄像头等传感器会提供原始数据给智能驾驶域控制器，域控制器完成传感器同步融合等处理后再渲染出表示周围环境的视频，甚至制作音频，然后再将音视频同时传输给车机在中控屏幕上播放。传输过程中，音视频需要在控制器之间传输。传输下层协议的UDP、IP等都是通用的以太网传输协议和标准，而RTP/RTCP则是在以太网传输基础上针对流媒体传输的关键协议。 

PES和TS流

编码器里出来的原始音视频裸流就是ES（Elementary Stream）流，ES流只包含一种音频或者视频。   ES的第一次封装：PES。   PES （Packetized Elementary Stream）流是ES流经过PES打包器处理后形成的数据流，在这个过程中完成了将ES流分组、打包、加入Header信息等操作。PES流的基本单位是PES包。PES包由Header和Payload组成。Payload部分组合起来就是原始的ES流，并不会修改ES的内容。一个PES包的最大长度是65535个字节。第一层封装的主要目的是丰富传输流的信息。

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字节的固定长度。

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包的示意图。与其他以太网通讯协议一样，其报文头包含了关键的媒体传输信息，也是该层协议的特征所在。

下表对应的是RTP子协议Header。前12字节（即头3行）是必填字段。

其中各个字段的含义是，

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。   审核编辑：黄飞