CN103368690A - 车载设备的音视频流媒体信息的传输方法 - Google Patents

Abstract

本发明公开一种车载设备的音视频信息的传输方法，其硬件系统包括通过无线网络连接的无线车台和媒体中心；该方法中，无线车台开始不断地传输协议包，直到传完一个协议窗口大小的数据后，停止发送协议包，并发送续传确认指令,续传确认指令包含当前协议窗口内协议包的最大包顺序号；媒体中心接收协议包，解析协议包，并根据包顺序号（SEQ）计算协议包的排列顺序；当媒体中心接收到续传确认指令时，根据接收到当前协议窗口的所有协议包包顺序号及续传确认指令中的最大包顺序号计算本轮是否需补传，以及所需补传协议包的顺序号，以上信息包含在续传确认指令的反馈指令里；当媒体中心接收到传输结束指令时，结束本次流媒体信息传输。本发明合理利用带宽，有效的提高了传输效率。

Description

车载设备的音视频流媒体信息的传输方法

技术领域

本发明涉及无线通信领域中车载设备的音视频信息的传输方法，尤其涉及移动嵌入式设备流媒体通讯技术，具体是一种实现嵌入式车载设备音视频流媒体信息在无线网络上快速可靠传输的方法及系统。

背景技术

目前的嵌入式车载设备（下简称无线车台）的设计需要计划硬件成本，存在着CPU、内存、带宽等资源有限，I/O读写速度受限等问题。而嵌入式车载设备的无线传输具有以下特点：1、流量有限且费用较高；2、传输时快时慢，带宽不稳定；3、信号时有时无，使得无线覆盖存在盲区。而嵌入式车载设备的无线传输的信息中，音视频流媒体信息具有大容量的特点，其传输问题尤其突出。

要解决快速可靠传输大容量的音视频信息的问题，目前的做法是，首选UDP作为网络传输协议；其次，采用专用设备来保障带宽相对充足、网络相对稳定。上述做法中，采用专用设备实施高效稳定传输的方法，其成本高昂，无法兼顾硬件成本和传输的高效稳定性。

发明内容

因此，针对上述的问题，本发明提出车载设备的音视频信息的传输方法及系统，通过引入协议窗口和补传延迟机制，可以较好地平衡无线车台的硬件能力及其在无线网络传输中的种种不利因素，在保证传输可靠性的前提下，依据无线车台的网络传输特点，并尽量考虑硬件因素，达到提高传输效率的目的。

为实现上述目的，本发明采用以下技术方案：一种车载设备的音视频信息的传输方法，其硬件系统包括作为信息发送端的无线车台和作为信息接受端的媒体中心，媒体中心通常由多媒体应用服务器实现，其收集和管理多媒体信息，并为第三方用户（或软件）提供多媒体应用支撑。无线车台和媒体中心通过无线网络连接；该方法包括如下步骤：

步骤1：无线车台根据可用内存大小、CPU能力及带宽计算出协议窗口大小，将音视频流媒体信息加载到内存里，并将音视频流媒体信息按协议窗口打包为协议包；其中，协议窗口定义了在延迟确认的这段时间（简称延迟时间）内，所有协议包（UDP协议包或者TCP协议包均可）总共传输的音视频流媒体信息量，单位Byte。该协议窗口大小据实际情况而定，考虑延迟时间（180秒，即3分钟以内）、带宽及丢包率，其取值范围为1-3MB Bytes；

步骤2：无线车台向媒体中心发送协议包，该协议包包括数据包和控制命令包，数据包包含音视频流媒体信息和包顺序号（SEQ），控制命令包包含命令类型及命令顺序号；其包括以下内容： 

步骤21：无线车台首先通过命令控制指令告知媒体中心，开始传输协议包，媒体中心进入准备接收状态；其中无线车台和媒体中心之间使用的通信协议不限TCP或是UDP，为增加速度，优选使用UDP通信协议，并通过使用控制命令包作为确认机制来确保信息可靠送达，其具体做法如下：无线车台（发送方）在控制命令包中写入命令类型及命令顺序号，命令类型由双发约定，命令顺序号由无线车台维护，单调递增；无线车台在发送数据（音视频流媒体信息）之前将该控制命令包发送至媒体中心；媒体中心（接收方）解析出命令类型后，首先向无线车台反馈接收结果，然后再进行相应的业务处理，从而确保了通信的可靠性；

步骤22: 无线车台开始不断地传输协议包，首先传输数据包，直到传完一个协议窗口大小的数据后，停止发送数据包，开始发送控制命令包，该控制命令包包含续传确认指令,续传确认指令包含当前协议窗口内数据包的最大包顺序号；为加快传输，音视频流媒体信息加载到内存时就已打成协议包；

步骤23：媒体中心接收协议包，解析该协议包，判断该协议包是数据包还是控制命令包；如果是数据包，则根据包顺序号计算协议包的排列顺序；如果是控制命令包，则解析出其具体命令，如果是续传确认指令，则根据接收到的当前协议窗口的所有数据包的包顺序号及续传确认指令中的最大包顺序号计算本轮是否需续传，以及所需续传的数据包的顺序号，以上信息包含在续传确认指令的反馈指令里，并向无线车台发送续传确认反馈命令控制指令，转到步骤24；如果是传输结束命令，则转到步骤26；将协议包的最大净负荷（单位：bits/package)记为流媒体最大传输单元，流媒体最大传输单元是固定长度的；协议包大小一般几乎均为流媒体最大传输单元（MTU）（仅最后一包可能小于MTU大小），方便计算分包，并在打包后加载到内存；计算流媒体最大传输单元时主要考虑因素为网络丢包率，通过测试发现流媒体最大传输单元（MTU）控制在12800 bits/package左右丢包率较小；一个协议窗口尺寸 =流媒体最大传输单元（MTU）×当前协议窗口UDP协议分包数量；

步骤24：无线车台接收到媒体中心发送的续传确认反馈命令控制指令后，向媒体中心补传相应的数据包；

步骤25：媒体中心接收无线车台发来的数据包；

步骤26：无线车台和媒体中心完成本次传输。

进一步的，所述步骤23中，媒体中心接收无线车台发送的协议包，并根据协议窗口大小分配循环接收缓存。当发生传输失败时，无线车台按照媒体中心接收失败的包序列号集（SEQs)进行补传，此时将补传的数据插入循环接收缓存中即可，方便省时。

进一步的，所述步骤24中，如果传输失败，无线车台按照接收到的包序列号集（SEQs)进行补传，具体包括以下内容：无线车台向媒体中心发送续传确认命令，媒体中心收到该续传确认命令，向无线车台发送续传确认反馈命令，同时，媒体中心计算需要补传的包序列号集（SEQs)，若无需补传则回发传输成功指令，若需要补充，则回发带包序列号集（SEQs)的续传确认指令；媒体中心收到传输结束指令后，结束本次传输。

进一步的，所述最大传输单元（MTU）根据可实际网络环境取经验值，该流媒体最大传输单元（MTU）优选取值为12800 bits/package。

进一步的，所述协议窗口大小取值范围为1-3MB Bytes。

本发明采用上述方案，具有如下优点：

1、协议窗口计算考虑到了无线车台的硬件特性及网络带宽，无线车台按协议窗口大小循环缓存音视频流媒体信息，有利于减少磁盘I/0延迟，合理利用带宽，提高传输效率；

2、续传确认延迟了一个协议窗口大小再发送，主要是解决不稳定网络环境下传输实时性问题，便于实现边传输边播放等功能；

3、同时，续传指令数据包大小远小于音视频流媒体信息包，有效地控制了网络流量。

附图说明

图1是本发明的传输方法中无线车台的处理流程图；

图2是本发明的传输方法中媒体中心的处理流程图。

具体实施方式

现结合附图和具体实施方式对本发明进一步说明。

无线车台存在成本问题，且在恶劣网络环境下工作，要实现快速可靠传输就需要一方面考虑受限的硬件因素，另一方面采用与之相配合的传输技术。本发明正是针对该问题而提出的。

具体的，本发明的车载设备的音视频流媒体信息的传输方法，无线车台作为发送方，媒体中心作为接受方，二者通过无线网络连接。

无线车台根据可用内存大小、CPU能力及带宽计算出协议窗口大小，并按协议窗口加载数据到内存里的循环发送缓存；无线车台主动发起流媒体传输时，通过通信协议告知媒体中心；无线车台开始传输协议包，协议包除了包含音视频流媒体信息还附带包顺序号（SEQ），以用于媒体中心判定是否已达到协议窗口尺寸，流媒体最大传输单元（MTU）是固定长度的；当发完协议窗口大小的数据后，发送续传确认指令；收到媒体中心回发的续传确认指令应答时，确定已传输成功或者按接收到的包序列号集（SEQs)进行补传，只有收到传输成功后，才释放内存并进行下一个协议窗口的传输；当所有加载到内存的音视频流媒体信息传完毕之后，发送传输结束指令完成本次传输。所述最大传输单元（MTU）根据可实际网络环境取经验值，通过测试发现流媒体最大传输单元（MTU）控制在12800 bits/package或12.5 kb/package(其约等于1.5KB/package；B - Byte ， b – bit，1 B = 8 b，KB - killobyte, kb - killobit)左右丢包率较小，因此流媒体最大传输单元可将12800 bits/package作为优选取值。 

媒体中心根据车台发送的协议窗口大小分配循环接收缓存，并开始接受流媒体协议包；当媒体中心收到车台续传确认指令，需计算需要补传的包序列号集（SEQs)，若无需补传则回发传输成功指令，若需要补充，则回发带包序列号集（SEQs)的补传指令；媒体中心收到传输结束指令后，接收本次传输。

作为一个具体的实施例，参照图1，无线车台的处理过程如下：

过程1：无线车台根据可用内存大小、CPU能力及带宽计算出协议窗口大小，并按协议窗口加载数据到内存；其中，协议窗口定义了在延迟确认的这段时间（简称延迟时间）内，所有数据协议包（UDP流媒体信息数据包）总共传输的音视频流媒体信息量，单位Byte。该协议窗口大小据实际情况而定，考虑延迟时间（180秒，即3分钟以内）、带宽及丢包率，其取值范围为1-3MB Bytes。举例如下：取值时考虑CPU主频、内存及I/O总线速率能够满足无线车台本地及时缓存的最低要求；若采用100Kbps(kilobit per second)无线带宽接入，用于净载荷的带宽在80Kbps左右，为其他应用保留20%带宽以后，用于流媒体传输的有效带宽约64Kbps，为控制协议窗口的延迟时间在3分钟以内，协议窗口大小12800 bits 或者 12.5 kb，对应约1000个协议包的大小，协议包的顺序号(SEQ)在协议窗口内的变化范围也即为1000。

过程2：无线车台向媒体中心发送音视频流媒体信息：首先通过开始传输命令控制指令告知媒体中心，准备开始传输音视频流媒体信息；然后无线车台将音视频流媒体信息打包为协议包开始传输，该协议包包括数据包和控制命令包，数据包包含音视频流媒体信息和包顺序号，控制命令包包含命令类型及命令顺序号；其数据包采用UDP通信协议；控制命令包使用的通信协议不限制TCP或是UDP，若使用UDP即控制命令包（表二），要使用确认机制确保信息送达，通常做法如下：命令发送方在指令数据内容中写入命令类型及命令顺序号（表二），命令类型由双发约定，命令顺序号由发起方维护，单调递增，命令发送方同时维护一个由命令序号唯一标识结点的重发命令队列并启动重发定时器，在发出命令控制协议时把命令控制协议包进队并打上时间戳，定时器超时却未收到命令接收方反馈指令时重发队列内符合超时条件（通过时间戳计算时隙）的命令控制协议包，在收到命令接收方反馈指令时出队；命令接收方解析出命令序号和类型，命令序号可唯一标识通信双方一次特定的业务交互，命令类型用于接收方进行相应的业务处理，在回应命令发送方反馈命令控制协议包时应保持反馈命令控制包的命令序号与接收时的命令序号一致；本实施例中，以基于UDP协议的数据包（简称UDP协议包）为例来说明本发明的可靠传输方案，如表一所示，该UDP协议包需携带包顺序号，能够有效地协同协议窗口工作；第1位为标识位，取值为0则表示该UDP协议包是数据包。本发明包含数据发送方和数据接收方两大部分。

表一，音视频流媒体信息包

过程3：判断UDP协议包是否已发完，或者是否已经发完重传，如果是则转到过程4，如果否，则转到过程2继续传输；

过程4：无线车台向媒体中心发送续传确认命令控制指令；

过程5：判断所有协议包是否传完了，如果是则转到过程6，如果否，则转到过程2继续传输；

过程6：无线车台向媒体中心发送传输结束命令控制指令。

上述过程中，作为发送方的无线车台主要负责协议窗口的计算，并触发一系列控制指令（表二），包含：开始传输命令控制指令（开始传输命令）、续传确认命令控制指令（续传确认命令）、传输结束命令控制指令（传输结束命令）；第1位为标识位，取值为1则表示是控制命令包。发送方（无线车台）根据本设备可用内存大小、CPU能力及带宽计算出协议窗口大小，并按协议窗口加载数据到内存里的循环发送缓存；发送方发起开始传输控制命令；发送方开始传输UDP音视频流媒体信息协议包；发送方发送续传确认控制命令，收到应答后决定已传输成功或者按接收到的包序列号集（SEQs)进行补传，只有收到传输成功后，才释放内存并进行下一个协议窗口的传输；发送方发送传输结束指令完成本次传输。

表二，控制命令包

发送方发起的续传确认指令控制信息（表二）需包含当前协议窗口最大的56位包顺序号（高24位+低32位），用于接收方正确处理续传确认应答。

另外，为加快传输，音视频流媒体信息加载到内存时就已打成协议包。表一和表二均为协议包格式，人为地把数据协议和控制协议分开了；表一为音视频流媒体信息包，即本文简称的协议包；表二为控制指令包，无论采用TCP或是UDP传输，表二协议格式已包含了足够多信息用以可靠发送指令。

媒体中心作为接受方，负责按协议窗口大小分批接收音视频流媒体信息，生成正确的续传确认应答，以及传输结束应答。参照图2，媒体中心的处理过程如下：

过程1a：媒体中心接收到开始传输命令控制指令，进入准备接收状态；

过程2a：媒体中心接收UDP协议包，解析该UDP协议包，通过其标识位（第1位）以判定是数据包还是控制命令包；如果是数据包则转到过程3a；如果是控制命令包，则转到过程4a；

过程3a：媒体中心接收数据包，解析出包顺序号以判定组包顺序，并对收到的数据包进行计算，如果计算出的结果是未完全接收完，则转到过程2a继续接收；

过程4a：媒体中心接收控制命令包，解析出控制命令，通过其命令类型和命令顺序号判定是续传确认命令还是传输结束命令；如果是续传确认命令，则转到过程5a；如果是传输结束命令，则转到过程6a；

过程5a：媒体中心向无线车台发送续传确认反馈命令控制指令，并转到过程2a继续接收；

过程6a：媒体中心结束接收数据。

上述过程中，无线车台进行传输时，开始不断地传输协议包，直到传完一个协议窗口大小的数据后，停止发送协议包，并发送续传确认指令,续传确认指令包含当前协议窗口内协议包的最大包顺序号；媒体中心接收协议包，解析协议包，并根据包顺序号（SEQ）计算协议包的排列顺序；当媒体中心接收到续传确认指令时，根据接收到当前协议窗口的所有协议包包顺序号及续传确认指令中的最大包顺序号计算本轮是否需补传，以及所需补传协议包的顺序号，以上信息包含在续传确认指令的反馈指令里。整个传输过程是按协议窗口大小，分轮次，顺序地传输协议包（即多媒体数据包）的。本发明合理利用带宽，有效的提高了传输效率。

尽管结合优选实施方案具体展示和介绍了本发明，但所属领域的技术人员应该明白，在不脱离所附权利要求书所限定的本发明的精神和范围内，在形式上和细节上可以对本发明做出各种变化，均为本发明的保护范围。  

Claims (6)

1.一种车载设备的音视频信息的传输方法，其硬件系统包括作为信息发送端的无线车台和作为信息接受端的媒体中心，无线车台和媒体中心通过无线网络连接；该方法包括如下步骤：

步骤1：无线车台根据可用内存大小、CPU能力及带宽计算出协议窗口大小，将音视频流媒体信息加载到内存里，并将音视频流媒体信息按协议窗口打包为协议包；其中，协议窗口定义了在延迟确认的这段时间内，所有协议包总共传输的流媒体数据量，单位为Byte；

步骤2：无线车台向媒体中心发送协议包，该协议包包括数据包和控制命令包，数据包包含音视频流媒体信息和包顺序号，控制命令包包含命令类型及命令顺序号；其包括以下内容：

步骤21：无线车台首先通过命令控制指令告知媒体中心，开始传输协议包，媒体中心进入准备接收状态； 

步骤22:无线车台开始不断地传输协议包，首先传输数据包，直到传完一个协议窗口大小的数据后，停止发送数据包，开始发送控制命令包，该控制命令包包含续传确认指令,续传确认指令包含当前协议窗口内数据包的最大包顺序号；

步骤23：媒体中心接收协议包，解析该协议包，判断该协议包是数据包还是控制命令包；如果是数据包，则根据包顺序号计算协议包的排列顺序；如果是控制命令包，则解析出其具体命令，如果是续传确认指令，则根据接收到的当前协议窗口的所有数据包的包顺序号及续传确认指令中的最大包顺序号计算本轮是否需续传，以及所需续传的数据包的顺序号，并向无线车台发送续传确认反馈命令控制指令，转到步骤24；如果是传输结束命令，则转到步骤26；将协议包的最大净负荷记为流媒体最大传输单元，单位：bits/package；流媒体最大传输单元是固定长度的；

步骤24：无线车台接收到媒体中心发送的续传确认反馈命令控制指令后，向媒体中心补传相应的数据包；

步骤25：媒体中心接收无线车台发来的数据包；

步骤26：无线车台和媒体中心完成本次传输。

2.根据权利要求1所述的传输方法，其特征在于：所述步骤21中，无线车台和媒体中心之间使用的通信协议为UDP通信协议，通过使用控制命令包作为确认机制来确保信息可靠送达，其具体做法如下：无线车台在控制命令包中写入命令类型及命令顺序号，在发送数据之前将该控制命令包发送至媒体中心；媒体中心解析出命令类型后，首先向无线车台反馈接收结果，然后再进行相应的业务处理。

3.根据权利要求1所述的传输方法，其特征在于：所述步骤23中，媒体中心接收无线车台发送的协议包，并根据协议窗口大小分配循环接收缓存，当发生传输失败时，无线车台按照媒体中心接收失败的包序列号集进行补传，此时将补传的数据插入循环接收缓存中即可。

4.根据权利要求1或2或3所述的传输方法，其特征在于：所述步骤24中，如果传输失败，无线车台按照接收到的包序列号集进行补传，具体包括以下内容：无线车台向媒体中心发送续传确认命令，媒体中心收到该续传确认命令，向无线车台发送续传确认反馈命令，同时，媒体中心计算需要补传的包序列号集，若无需补传则回发传输成功指令，若需要补充，则回发带包序列号集的续传确认指令；媒体中心收到传输结束指令后，结束本次传输。

5.根据权利要求1所述的传输方法，其特征在于：所述协议窗口大小取值范围为1-3MB Bytes。

6.根据权利要求1所述的传输方法，其特征在于：所述流媒体最大传输单元取值为12800 bits/package。

Images