数据传输方法、装置、设备、车辆及存储介质与流程

1.本公开涉及通信技术领域，尤其涉及数据传输、跨终端互联、投屏技术领域。


背景技术：

2.随着车载场景的发展愈来愈快速，人们对车机和移动终端互联的需求也越来越明显。
3.目前，车载场景的多媒体数据传输，由移动终端基于传输控制协议(transmission control protocol，tcp)直接将编码后的视频数据和音频数据传输到车机端，tcp协议是面向连接的可靠性连接协议，可保证数据传输的正确性和顺序性。


技术实现要素：

4.本公开提供了一种数据传输方法、装置、设备以及存储介质。
5.根据本公开的一方面，提供了一种数据传输方法，包括：
6.获取待传输媒体流数据，其中，所述待传输媒体流数据中包括视频流数据和/或音频流数据；
7.根据所述待传输媒体流数据，生成实时传输协议rtp数据包；
8.基于rtp会话向车辆发送所述rtp数据包，以指示所述车辆通过解析所述rtp数据包得到相应的第一媒体流数据，并利用车载部件播放所述第一媒体流数据，其中，所述rtp会话基于用户数据报协议方式实现。
9.根据本公开的另一方面，提供了一种数据传输方法，包括：
10.基于实时传输协议rtp会话，接收移动终端发送的rtp数据包，其中，所述移动终端根据获取到的待传输媒体流数据生成所述rtp数据包，所述待传输媒体流数据中包括视频流数据和/或音频流数据，所述rtp会话基于用户数据报协议方式实现；
11.通过解析所述rtp数据包得到相应的第一媒体流数据；
12.利用车载部件播放所述第一媒体流数据。
13.根据本公开的另一方面，提供了一种数据传输装置，包括：
14.待传输数据获取模块，用于获取待传输媒体流数据，其中，所述待传输媒体流数据中包括视频流数据和/或音频流数据；
15.第一数据包生成模块，用于根据所述待传输媒体流数据，生成实时传输协议rtp数据包；
16.第一数据包发送模块，用于基于rtp会话向车辆发送所述rtp数据包，以指示所述车辆通过解析所述rtp数据包得到相应的第一媒体流数据，并利用车载部件播放所述第一媒体流数据，其中，所述rtp会话基于用户数据报协议方式实现。
17.根据本公开的另一方面，提供了一种数据传输装置，包括：
18.第一数据包接收模块，用于基于实时传输协议rtp会话，接收移动终端发送的rtp数据包，其中，所述移动终端根据获取到的待传输媒体流数据生成所述rtp数据包，所述待
传输媒体流数据中包括视频流数据和/或音频流数据，其中，所述rtp会话基于用户数据报协议方式实现；
19.第一数据包解析模块，用于通过解析所述rtp数据包得到相应的第一媒体流数据；
20.第一播放模块，用于利用车载部件播放所述第一媒体流数据。
21.根据本公开的另一方面，提供了一种移动终端，包括：
22.至少一个处理器；以及
23.与所述至少一个处理器通信连接的存储器；其中，
24.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本公开实施例所述的方法。
25.根据本公开的另一方面，提供了一种车辆，包括：
26.至少一个处理器；以及
27.与所述至少一个处理器通信连接的存储器；其中，
28.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本公开实施例所述的方法。
29.根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行本公开实施例所述的方法。
30.根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现本公开任意实施例所述的方法。
31.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
32.附图用于更好地理解本方案，不构成对本公开的限定。其中：
33.图1a是根据本公开实施例提供的一种数据传输方法的流程图；
34.图1b是根据本公开实施例提供的一种数据包结构示意图；
35.图2是根据本公开实施例提供的另一种数据传输方法的流程图；
36.图3是根据本公开实施例提供的又一种数据传输方法的流程图；
37.图4是根据本公开实施例提供的再一种数据传输方法的流程图；
38.图5是根据本公开实施例提供的一种数据传输方法的交互示意图；
39.图6是根据本公开实施例提供的一种数据传输装置的结构示意图；
40.图7是根据本公开实施例提供的另一种数据传输装置的结构示意图；
41.图8是用来实现本公开实施例的数据传输方法的移动终端的框图；
42.图9是用来实现本公开实施例的数据传输方法的车辆的框图。
具体实施方式
43.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
44.图1a是根据本公开实施例提供的一种数据传输方法的流程图，本公开实施例可适用于在移动终端和车辆之间进行数据传输的情况。该方法可由数据传输装置来执行，该装置可采用硬件和/或软件的方式来实现，可配置于移动终端中，其中，移动终端例如可以是手机、智能手表、或平板电脑等设备。参考图1a，该方法具体包括如下：
45.s101、获取待传输媒体流数据，其中，所述待传输媒体流数据中包括视频流数据和/或音频流数据；
46.s102、根据所述待传输媒体流数据，生成实时传输协议rtp数据包；
47.s103、基于rtp会话向车辆发送所述rtp数据包，以指示所述车辆通过解析所述rtp数据包得到相应的第一媒体流数据，并利用车载部件播放所述第一媒体流数据，其中，所述rtp会话基于用户数据报协议方式实现。
48.其中，待传输媒体流数据可以理解为移动终端中即将向车辆发送的媒体流数据，具体可以是向车辆中的车机发送。待传输媒体流数据中可以包括视频流数据，可以包括音频流数据，还可以同时包括视频流数据和音频流数据。本公开实施例中，视频流数据中可以包括多个视频帧，视频帧的来源不做限定，例如可以来自视频播放器类应用程序中的视频，还可以来自导航应用程序中的导航图像。音频流数据可以包括多个音频帧，音频帧的来源不做限定，例如可以来自视频播放器类应用程序中的音频，还可以来自导航应用程序中的导航语音。在待传输媒体流数据中包含移动终端屏幕正在显示的视频流数据的情况下，本公开实施例的技术方案可以实现移动终端向车辆投屏的效果。
49.本公开实施例中，移动终端和车辆之间可采用有线或无线方式进行通信连接。示例性的，可在移动终端和车辆之间建立基于用户数据报协议(user datagram protocol，udp)方式实现的实时传输协议(real-time transport protocol，rtp)会话，该会话的建立过程不做限定。可选的，先在移动终端和车辆之间建立主数据通道，该主数据通道可作为移动终端和车辆的基础事件传递的通道，具体用于传输基础数据，基础数据例如可以包括移动终端和/或车辆的网际协议(internet protocol，ip)地址和端口号等，基于ip地址和端口号可建立rtp会话。可选的，主数据通道可基于传输控制协议(transmission control protocol，tcp)建立，具体可以是建立套接字(socket)连接，该主数据通道可称为maindata socket。
50.示例性的，移动终端在获取到待传输媒体流数据后，可根据传输媒体流数据中的全部数据或部分数据，生成rtp数据包。例如，将待传输媒体流数据编码为预设格式的数据，再将编码后的数据封装为rtp数据包。其中，预设格式不做限定，例如，视频流数据对应的预设格式可以是h.264等，音频流数据对应的预设格式可以是mp3等。在进行rtp数据包封装时，视频流数据和音频流数据可分别封装，也可一起封装，具体不做限定。
51.示例性的，图1b是根据本公开实施例提供的一种数据包结构示意图，如图1b所示，rtp数据包包括包头(rtp首部)和包体，媒体流数据作为rtp数据包的包体(也即rtp数据流)，rtp数据包作为udp数据包的包体，根据rtp数据包和udp首部封装为udp数据包。
52.示例性的，在生成rtp数据包后，通过rtp会话向车辆传输rtp数据包，使得车辆可以在接收到rtp数据包后，通过解析rtp数据包来获取其中的媒体流数据(解析后得到的媒体流数据与待传输媒体流数据可能相同或不同，为便于区分，此处记为第一媒体流数据)，并利用车载部件对第一媒体流数据进行播放，车载部件可包括如车载显示屏或车载音响
等。
53.本公开实施例提供的技术方案，可以由移动终端根据待传输的媒体流数据生成rtp数据包，基于rtp会话向车辆发送rtp数据，使得车辆可以通过解析rtp数据包得到相应的媒体流数据并利用车载部件进行播放，由于rtp会话基于udp方式实现，面向数据传输，可随时开始传输数据包，且不需要保证数据包的正确性和顺序性，不需要处理数据包之间的关联性，可以减少移动终端和车辆的性能开销，另外，不需要提供流量控制或拥塞控制，可避免发生数据阻塞，进而提高数据传输效率，保证数据传输的实时性，使得车辆在播放媒体数据时能够保证流畅性。
54.在移动终端与车辆进行媒体流传输时，可以根据媒体流中数据类型的不同或不同数据之间的关联关系的不同，划分为不同的传输场景，在不同的传输场景中，传输需求的侧重点可能不同。一些场景可能更注重于数据流播放的流畅性；而一些场景可能更注重于数据流传输的可靠性，需要保证每一帧数据的正确性和顺序性。本公开实施例中，可以预先设定需要采用rtp会话传输的传输条件，记为预设传输条件，进而可在满足该预设传输条件的情况下，采用rtp会话进行传输。
55.在一种可选实施方式中，所述根据所述待传输媒体流数据，生成rtp数据包，包括：在确定所述待传输媒体流数据满足预设传输条件的情况下，根据所述待传输媒体流数据中的视频流数据，生成rtp数据包。其中，所述预设传输条件包括以下至少一种：所述待传输媒体流数据中仅包含视频流数据；所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度。这样设置的好处在于，在合适的传输场景下采用rtp会话进行传输，保证数据传输的时效性。
56.示例性的，若待传输媒体流数据中仅包含视频流数据，不包含音频流数据，则视频流数据不与其他数据存在关联，是独立播放的，例如导航应用中的导航视频流，可以允许丢包，优先保证时效性；若待传输媒体流数据中同时视频流数据和音频流数据，但视频流数据和音频流数据之间的关联程度低于预设关联程度，也即紧密程度较低，例如导航应用中的导航视频流和导航语音流，可以允许丢包，优先保证时效性；若待传输媒体流数据中包含的视频流数据和音频流数据的关联程度高于或等于预设关联程度，也即紧密程度较高，例如，电影中的电影画面和人物对话，若发生丢包，则会导致观看体验较差，需要保证可靠性，因此，认为不满足预设传输条件，也即不生成rtp数据包。
57.可选的，所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度，包括：所述待传输媒体流数据中包含的视频流数据和音频流数据，来自于非视频播放器类应用程序。这样设置的好处在于，可以快速判断出是否满足预设传输条件。其中，视频播放器类应用程序中播放的内容通常画面与声音的紧密程度较高，如电影、视频直播和短视视频作品等，因此，若待传输媒体流数据中视频流数据和音频流数据来自于同一视频播放器类应用程序，可认为不满足预设传输条件，若来自于非视频播放器类应用程序，如导航应用程序，可认为满足预设传输条件。
58.图2是根据本公开实施例提供的另一种数据传输方法的流程图，本实施例在上述各可选实施例的基础上，提出一种可选方案，在确定待传输媒体流数据不满足预设传输条件的情况下，采用tcp方式进行传输。参见图2，该方法包括：
59.s201、获取待传输媒体流数据。
60.示例性的，可在移动终端和车辆成功建立无线连接后，创建主数据通道，并保持主数据通道的连接。
61.s202、确定待传输媒体流数据是否满足预设传输条件，若是，则执行s203；否则，执行s205。
62.s203、根据待传输媒体流数据中的视频流数据，生成rtp数据包。
63.示例性的，可在确定待传输媒体流数据满足预设传输条件之后，根据主数据通道传输的ip地址和端口号建立rtp会话。若此时rtp会话已存在，则可直接进行生成rtp数据包的操作。
64.s204、基于rtp会话向车辆发送rtp数据包，以指示车辆通过解析rtp数据包得到相应的第一媒体流数据，并利用车载部件播放第一媒体流数据。
65.可选的，在确定待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度的情况下，根据待传输媒体流数据中的音频流数据，生成第二tcp数据包；基于主数据通道向车辆发送第二tcp数据包，以指示车辆通过解析第二tcp数据包得到相应的音频流数据，并利用车载部件播放所得到的音频流数据。这样设置的好处在于，音频流数据的数据量较少，可以将视频流数据和音频流数据分开采用不同的通道进行传输，保证音频传输的可靠性。
66.s205、根据待传输媒体流数据，生成第一tcp数据包。
67.可选的，在确定待传输媒体流数据不满足预设传输条件的情况下，销毁rtp会话。这样设置的好处在于，在确定不需要采用rtp会话进行数据传输时，及时销毁rtp会话，释放相应资源，提高资源利用率。
68.s206、基于主数据通道向车辆发送第一tcp数据包，以指示车辆通过解析第一tcp数据包得到相应的第二媒体流数据，并利用车载部件播放第二媒体流数据。
69.示例性的，若待传输媒体流数据不满足预设传输条件，可采用tcp方式进行传输，保证数据传输的准确性和顺序性。
70.本公开实施例提供的技术方案，根据待传输媒体流数据中是否包含视频流数据，以及包含的视频流数据和音频流数据之间的关联程度，来确定待传输媒体流数据的传输采用rtp方式还是tcp方式，满足不同传输场景下的不同传输需求，提升用户观看或收听媒体流的体验。
71.本公开实施例中，在采用rtp会话进行媒体流传输时，可能存在丢包情况，可利用实时传输控制协议(real-time transport control protocol，rtcp)会话进行rtcp控制包的发送，以便车辆侧可以及时获知丢包信息或网络质量信息。在一种可选实施方式中，还包括：生成rtcp控制包，其中，所述rtcp控制包中包括所述rtp数据包的发送情况信息；基于rtcp会话向所述车辆发送所述rtcp控制包，以指示所述车辆通过解析所述rtcp控制包得到所述发送情况信息，并根据所述发送情况信息确定丢包信息和/或网络质量信息。
72.其中，发送情况信息可以包括rtp数据包的序号以及rtp数据包的已发送数量等；丢包信息可以包括未成功接收的rtp数据包的序号以及丢包率等；网络质量信息可以用于体现rtp通道的网络质量，可以根据rtp数据包的丢包率确定，如丢包率较高时，可确定网络质量较差。
73.在一种可选实施方式中，所述rtcp会话基于主数据通道建立，所述主数据通道基
于tcp建立；所述方法还包括：基于所述主数据通道和/或所述rtcp会话，接收所述车辆发送的数据包重传指令；针对所述数据包重传指令所指示的目标rtp数据包进行重传操作。这样设置的好处在于，可以根据车辆的指示来选择需要进行重传的目标rtp数据，并进行重传，在一定程度上提升数据传输的完整性。
74.其中，目标rtp数据包可以包括全部未成功接收的rtp数据包，也可以包括部分未成功接收的rtp数据包。在包含部分的情况下，可以根据丢失的rtp数据包的重要性来进行选择，从而可避免一些不必要的重传操作。
75.在一种可选实施方式中，所述数据包重传指令由所述车辆根据丢包信息生成。其中，丢包信息中可包括丢失数据包对应的视频帧类型。例如，在对视频数据进行编码时，为了减少数据量，可以编码成不同类型的视频帧，如关键帧(i帧)、前向预测编码帧(p帧)和双向预测编码帧(b帧)，三种类型的重要性依次降低。对于重要性较高的丢包可以进行重传，也即确定为目标rtp数据包，如i帧，还可包括p帧；对于重要性较低的丢包可以忽略，不进行重传，如b帧，也可包括p帧。
76.在一种可选实施方式中，所述数据包重传指令由所述车辆根据丢包信息、以及预设车辆性能指标的当前取值和/或网络质量信息确定，其中，所述预设车辆性能指标与所述车辆的数据处理能力相关。这样设置的好处在于，可以结合网络质量信息和/或预设车辆性能指标，来灵活准确地根据实际情况确定需要进行重传的rtp数据包。
77.其中，预设车辆性能指标例如可以包括处理器，如中央处理器(central processing unit，cpu)，的空闲率或空载率等指标，可以根据占用率或负载率等进行计算。
78.可选的，车辆在确定预设车辆性能指标的当前取值低于第一预设性能阈值，和/或，根据网络质量信息确定当前网络质量低于第一预设质量阈值的情况下，根据丢包信息将目标视频帧类型的视频帧数据所属的未成功接收的rtp数据包确定为目标rtp数据包，以生成数据包重传指令，其中，所述目标视频帧类型包括关键帧。这样，移动终端可以在车辆的指示下，有针对性地对关键帧进行重传，优先保证关键帧传输的可靠性，可缓解车辆端的压力。
79.具体的，第一种情况，所述车辆在根据网络质量信息确定当前网络质量低于第一预设质量阈值的情况下，根据丢包信息将目标视频帧类型的视频帧数据所属的未成功接收的rtp数据包确定为目标rtp数据包，以生成数据包重传指令，例如，丢包率大于预设丢包率阈值，说明网络质量较差，可优先保证关键帧的可靠传输；或者，第二种情况，在确定预设车辆性能指标的当前取值低于第一预设性能阈值的情况下，根据丢包信息将目标视频帧类型的视频帧数据所属的未成功接收的rtp数据包确定为目标rtp数据包，以生成数据包重传指令，例如cpu空闲率低于预设空闲率阈值，或cpu负载率高于预设负载率阈值等，说明车辆当前用于处理媒体流传输的资源较少，可优先保证关键帧的可靠传输；或者，第三种情况，在根据网络质量信息确定当前网络质量低于第一预设质量阈值，且确定预设车辆性能指标的当前取值低于第一预设性能阈值的情况下，根据丢包信息将目标视频帧类型的视频帧数据所属的未成功接收的rtp数据包确定为目标rtp数据包，以生成数据包重传指令。
80.其中，所述目标视频帧类型包括关键帧，还可包括前向预测编码帧。可选的，针对上述三种不同情况，目标视频帧类型也可以不同。例如，第一种情况和第二种情况下，目标视频帧类型包括i帧和p帧，也即不包括b帧；第三种情况下，目标视频帧类型包括i帧，也即
不包括p帧和b帧。
81.可选的，车辆在确定预设车辆性能指标的当前取值高于第一预设性能阈值，或，根据网络质量信息确定当前网络质量高于第一预设质量阈值，或同时满足上述两项的情况下，根据丢包信息确定未成功接收的rtp数据包对应的视频帧数据是否为目标视频帧类型，若是，则确定为目标rtp数据包，以生成数据包重传指令，若否，则不生成数据包重传指令。
82.图3是根据本公开实施例提供的又一种数据传输方法的流程图，本实施例在上述各可选实施例的基础上，提出一种可选方案，移动终端可以根据车辆发送的数据包传输指令来有针对性的对目标视频帧类型的视频帧数据进行rtp方式的传输。参见图3，该方法包括：
83.s301、获取待传输媒体流数据。
84.s302、确定待传输媒体流数据满足预设传输条件的情况下，根据待传输媒体流数据中的视频流数据，生成rtp数据包。
85.s303、基于rtp会话向车辆发送rtp数据包，以指示车辆通过解析rtp数据包得到相应的第一媒体流数据，并利用车载部件播放第一媒体流数据。
86.s304、生成实时传输控制协议rtcp控制包，其中，rtcp控制包中包括rtp数据包的发送情况信息。
87.s305、基于rtcp会话向车辆发送rtcp控制包，以指示车辆通过解析rtcp控制包得到发送情况信息，并根据发送情况信息确定丢包信息和/或网络质量信息。
88.s306、基于主数据通道和/或rtcp会话，接收车辆发送的数据包重传指令。
89.其中，数据包重传指令由车辆根据丢包信息、以及预设车辆性能指标的当前取值和/或网络质量信息生成。
90.s307、针对数据包重传指令所指示的目标rtp数据包进行重传操作。
91.s308、基于主数据通道和/或rtcp会话，接收车辆发送的数据包传输指令。
92.其中，所述数据包传输指令由所述车辆根据预设车辆性能指标的当前取值和/或网络质量信息生成，所述数据包传输指令用于指示目标视频帧类型，所述预设车辆性能指标与所述车辆的数据处理能力相关。
93.示例性的，在基于rtp会话进行媒体流数据的传输过程中，网络质量或预设车辆性能指标可能会发生动态变化，车辆可以根据当前实际情况来指示移动终端传输的视频帧类型。
94.可选的，车辆在确定预设车辆性能指标的当前取值低于第二预设性能阈值，和/或，根据网络质量信息确定当前网络质量低于第二预设质量阈值的情况下，生成数据包传输指令，其中，数据包传输指令所指示的目标视频帧类型包括关键帧。这样，移动终端可以在车辆的指示下，对关键帧进行传输，减少非关键帧对传输通道的占用，提高关键帧传输成功的概率，缓解车辆端的压力。
95.例如，目标视频帧类型不包括非关键帧，减少非关键帧对传输通道的占用，提高关键帧传输成功的概率。可选的，在网络质量未低于预设最低质量阈值和/或预设车辆性能指标的当前取值未低于预设最低性能阈值的情况下，目标视频帧类型也可包括p帧。
96.s309、根据新获取的待传输媒体流数据中，符合目标视频帧类型的视频帧数据，生成新rtp数据包。
97.需要说明的是，此处新获取的待传输媒体流数据，用于与s301中获取的待传输媒体流数据进行区分，并不限定二者的获取时序；新rtp数据包用于与s302中的rtp数据包进行区分，也不限定二者的生成时序。若数据包传输指令由车辆根据预设车辆性能指标的当前取值生成，也即数据包传输指令的生成不依赖于网络质量信息的情况下，在s302之前，也可接收车辆发送的数据包传输指令，并根据s301中获取的待传输媒体流数据中，符合目标视频帧类型的视频帧数据，生成rtp数据包。
98.s310、基于rtp会话向车辆发送新rtp数据包，以指示车辆通过解析新rtp数据包得到相应的第三媒体流数据，并利用车载部件播放第三媒体流数据。
99.示例性的，车辆在接收到新rtp数据包后，解析得到的第三媒体流数据中可能仅包括i帧，或包括i帧和p帧，可以通过放弃全部或部分的非关键帧的传输的方式，提升关键帧传输的成功率，也可以缓解车辆端的负载等压力。
100.本公开实施例提供的技术方案，移动终端在采用rtp方式向车辆传输媒体流数据的过程中，通过rtcp会话传输rtcp控制包，使得车辆可以根据解析得到的rtp数据包的发送情况信息，及时准确地获知丢包信息和/或网络质量信息，并进一步根据丢包信息、以及预设车辆性能指标的当前取值和/或网络质量信息来生成数据包重传指令，移动终端在接收到数据包重传指令后，可以有针对性地进行丢包重传，此外，移动终端还可以接收车辆根据预设车辆性能指标的当前取值和/或网络质量信息生成数据包传输指令，并根据该指令对视频流数据中的视频帧进行有选择性的生成rtp数据包进行传输，减少非关键帧对传输通道的占用，提高关键帧传输成功的概率，缓解车辆端的压力。
101.图4是根据本公开实施例提供的再一种数据传输方法的流程图，本公开实施例可适用于在移动终端和车辆之间进行数据传输的情况。该方法可由数据传输装置来执行，该装置可采用硬件和/或软件的方式来实现，可配置于车辆中，具体可以是配置于车机中。参考图4，该方法具体包括如下：
102.s401、基于实时传输协议rtp会话，接收移动终端发送的rtp数据包，其中，所述移动终端根据获取到的待传输媒体流数据生成所述rtp数据包，所述待传输媒体流数据中包括视频流数据和/或音频流数据，所述rtp会话基于用户数据报协议方式实现；
103.s402、通过解析所述rtp数据包得到相应的第一媒体流数据；
104.s403、利用车载部件播放所述第一媒体流数据。
105.本公开实施例提供的技术方案，可以由车辆接收移动终端基于rtp会话发送的根据待传输的媒体流数据生成的rtp数据包，通过解析rtp数据包得到相应的媒体流数据并利用车载部件进行播放，由于rtp会话基于udp方式实现，面向数据传输，可随时开始传输数据包，且不需要保证数据包的正确性和顺序性，不需要处理数据包之间的关联性，可以减少移动终端和车辆的性能开销，另外，不需要提供流量控制或拥塞控制，可避免发生数据阻塞，进而提高数据传输效率，保证数据传输的实时性，使得车辆在播放媒体数据时能够保证流畅性。
106.在一种可选实施方式中，所述移动终端在确定所述待传输媒体流数据满足预设传输条件的情况下，根据所述待传输媒体流数据中的视频流数据生成所述rtp数据包。其中，所述预设传输条件包括以下至少一种：所述待传输媒体流数据中仅包含视频流数据；所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度。
这样设置的好处在于，在合适的传输场景下采用rtp会话进行传输，保证数据传输的时效性。
107.在一种可选实施方式中，所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度，包括：所述待传输媒体流数据中包含的视频流数据和音频流数据，来自于非视频播放器类应用程序。这样设置的好处在于，可以快速判断出是否满足预设传输条件。
108.在一种可选实施方式中，所述rtp会话基于主数据通道建立，所述主数据通道基于传输控制协议tcp建立。其中，所述方法还包括：基于所述主数据通道接收所述移动终端发送的第一tcp数据包，其中，所述第一tcp数据包由所述移动终端在确定所述待传输媒体流数据不满足所述预设传输条件的情况下，根据所述待传输媒体流数据生成；通过解析所述第一tcp数据包得到相应的第二媒体流数据；利用车载部件播放所述第二媒体流数据。这样设置的好处在于，在不满足rtp方式的传输条件时，采用tcp方式进行传输，保证媒体流数据的及时可靠传输，满足不同传输场景下的不同传输需求，提升用户观看或收听媒体流的体验。
109.在一种可选实施方式中，还包括：在确定所述待传输媒体流数据不满足所述预设传输条件的情况下，销毁所述rtp会话。这样设置的好处在于，在确定不需要采用rtp会话进行数据传输时，及时销毁rtp会话，释放相应资源，提高资源利用率。
110.在一种可选实施方式中，所述rtp会话基于主数据通道建立，所述主数据通道基于tcp建立；所述方法还包括：基于所述主数据通道接收所述移动终端发送的第二tcp数据包，其中，所述第二tcp数据包由所述移动终端在确定所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度的情况下，根据所述待传输媒体流数据中的音频流数据生成；通过解析所述第二tcp数据包得到相应的音频流数据；利用车载部件播放所得到的音频流数据。这样设置的好处在于，音频流数据的数据量较少，可以将视频流数据和音频流数据分开采用不同的通道进行传输，保证音频传输的可靠性。
111.在一种可选实施方式中，还包括：基于rtcp会话接收所述移动终端发送实时传输控制协议rtcp控制包，其中，所述rtcp控制包中包括所述rtp数据包的发送情况信息；通过解析所述rtcp控制包得到所述发送情况信息；根据所述发送情况信息确定丢包信息和/或网络质量信息。这样设置的好处在于，在采用rtp会话进行媒体流传输时，可能存在丢包情况，可利用rtcp会话进行rtcp控制包的发送，以便车辆侧可以及时获知丢包信息或网络质量信息。
112.在一种可选实施方式中，所述rtcp会话基于主数据通道建立，所述主数据通道基于tcp建立；所述方法还包括：基于所述主数据通道和/或所述rtcp会话向所述移动终端发送的数据包重传指令，以指示所述移动终端针对所述数据包重传指令所指示的目标rtp数据包进行重传操作。这样设置的好处在于，可以根据车辆的指示来选择需要进行重传的目标rtp数据，并进行重传，在一定程度上提升数据传输的完整性。
113.在一种可选实施方式中，所述方法还包括：根据丢包信息、以及预设车辆性能指标的当前取值和/或网络质量信息中的至少一项生成所述数据包重传指令，其中，所述预设车辆性能指标与所述车辆的数据处理能力相关。这样设置的好处在于，可以结合网络质量信息和/或预设车辆性能指标，来灵活准确地根据实际情况确定需要进行重传的rtp数据包。
114.在一种可选实施方式中，所述根据丢包信息、以及预设车辆性能指标的当前取值和/或网络质量信息生成所述数据包重传指令，包括：在确定预设车辆性能指标的当前取值低于第一预设性能阈值，和/或，根据网络质量信息确定当前网络质量低于第一预设质量阈值的情况下，根据丢包信息将目标视频帧类型的视频帧数据所属的未成功接收的rtp数据包确定为目标rtp数据包，以生成数据包重传指令，其中，所述目标视频帧类型包括关键帧。这样设置的好处在于，合理确定指示移动终端需要重传的rtp数据包中视频帧的类型，优先保证关键帧传输的可靠性，并可缓解车辆端的压力。
115.在一种可选实施方式中，所述rtcp会话基于主数据通道建立，所述主数据通道基于tcp建立。所述方法还包括：根据预设车辆性能指标的当前取值和/或网络质量信息生成数据包传输指令，其中，所述数据包传输指令用于指示目标视频帧类型，所述预设车辆性能指标与所述车辆的数据处理能力相关；基于所述主数据通道和/或所述rtcp会话，向所述移动终端发送所述数据包传输指令，以指示所述移动终端根据新获取的待传输媒体流数据中，符合所述目标视频帧类型的视频帧数据，生成新rtp数据包，并基于所述rtp会话返回所述新rtp数据包；通过解析所述新rtp数据包得到相应的第三媒体流数据；利用车载部件播放所述第三媒体流数据。这样设置的好处在于，由车辆根据网络情况或自身性能情况，指示移动终端需要采用rtp方式进行传输的视频帧的类型，有利于减少目标视频帧类型之外的视频帧数据的传输对传输通道的占用，提高目标视频帧类型的视频帧的传输成功的概率，缓解车辆端的压力。
116.在一种可选实施方式中，所述根据预设车辆性能指标的当前取值和/或网络质量信息生成数据包传输指令，包括：在确定预设车辆性能指标的当前取值低于第二预设性能阈值，和/或，根据网络质量信息确定当前网络质量低于第二预设质量阈值的情况下，生成数据包传输指令，其中，数据包传输指令所指示的目标视频帧类型包括关键帧。这样设置的好处在于，合理确定指示移动终端需要采用rtp方式进行传输的视频帧的类型，有利于减少非关键帧对传输通道的占用，提高关键帧传输成功的概率，缓解车辆端的压力。
117.图5是根据本公开实施例提供的一种数据传输方法的交互示意图。如图5所示，车辆和移动终端先建立主数据通道，在主数据通道上传输ip地址和端口号，以建立rtp会话和rtcp会话，移动终端在获取到待传输媒体流数据后，判断待传输媒体流数据是否满足预设传输条件，若满足，则采用rtp方式传输，若不满足，则采用主数据通道进行传输。在采用rtp方式传输时，将媒体流数据封装为rtp数据包，并生成rtcp控制包，通过rtp通道传输rtp数据包，通过rtcp通道传输rtcp控制包。车辆在收到rtp数据包后，进行解析，得到对应的媒体流数据，在车载显示屏上进行渲染展示。车辆在根据rtcp控制包确定存在丢包情况时，根据丢包信息、cpu占用率和丢包率等确定当前需要针对关键帧进行重传时，判断未成功接收的rtp数据包是否对应于关键帧，若是，则生成数据包重传指令，指示移动终端对丢包的关键帧进行重传。车辆在根据cpu占用率和丢包率等确定需要放弃非关键帧的传输时，可以向移动终端发送数据包传输指令，指示移动终端传输不包含非关键帧的rtp数据包。
118.本公开的技术方案中，所涉及的媒体流数据以及用户个人信息等的收集、存储、使用、加工、传输、提供和公开等，均符合相关法律法规的规定，且不违背公序良俗。
119.图6是根据本公开实施例提供的一种数据传输装置的结构示意图，本公开实施例可适用于在移动终端和车辆之间进行数据传输的情况。该装置可采用硬件和/或软件的方
式来实现，可配置于移动终端中，该装置可以实现本公开相应实施例所述的数据传输方法。如图6所示，该数据传输装置600包括：
120.待传输数据获取模块601，用于获取待传输媒体流数据，其中，所述待传输媒体流数据中包括视频流数据和/或音频流数据；
121.第一数据包生成模块602，用于根据所述待传输媒体流数据，生成实时传输协议rtp数据包；
122.第一数据包发送模块603，用于基于rtp会话向车辆发送所述rtp数据包，以指示所述车辆通过解析所述rtp数据包得到相应的第一媒体流数据，并利用车载部件播放所述第一媒体流数据，其中，所述rtp会话基于用户数据报协议方式实现。
123.本公开实施例提供的技术方案，可以由移动终端根据待传输的媒体流数据生成rtp数据包，基于rtp会话向车辆发送rtp数据，使得车辆可以通过解析rtp数据包得到相应的媒体流数据并利用车载部件进行播放，由于rtp会话基于udp方式实现，面向数据传输，可随时开始传输数据包，且不需要保证数据包的正确性和顺序性，不需要处理数据包之间的关联性，可以减少移动终端和车辆的性能开销，另外，不需要提供流量控制或拥塞控制，可避免发生数据阻塞，进而提高数据传输效率，保证数据传输的实时性，使得车辆在播放媒体数据时能够保证流畅性。
124.在一种可选实施方式中，所述第一数据包生成模块，具体用于：
125.在确定所述待传输媒体流数据满足预设传输条件的情况下，根据所述待传输媒体流数据中的视频流数据，生成rtp数据包；
126.其中，所述预设传输条件包括以下至少一种：
127.所述待传输媒体流数据中仅包含视频流数据；
128.所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度。
129.在一种可选实施方式中，所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度，包括：
130.所述待传输媒体流数据中包含的视频流数据和音频流数据，来自于非视频播放器类应用程序。
131.在一种可选实施方式中，所述rtp会话基于主数据通道建立，所述主数据通道基于传输控制协议tcp建立；
132.其中，所述装置还包括：
133.第二数据包生成模块，用于在确定所述待传输媒体流数据不满足所述预设传输条件的情况下，根据所述待传输媒体流数据，生成第一tcp数据包；
134.第二数据包发送模块，用于基于所述主数据通道向所述车辆发送所述第一tcp数据包，以指示所述车辆通过解析所述第一tcp数据包得到相应的第二媒体流数据，并利用车载部件播放所述第二媒体流数据。
135.在一种可选实施方式中，还包括：
136.第一会话销毁模块，用于在确定所述待传输媒体流数据不满足所述预设传输条件的情况下，销毁所述rtp会话。
137.在一种可选实施方式中，所述rtp会话基于主数据通道建立，所述主数据通道基于
tcp建立；
138.所述装置还包括：
139.第三数据包生成模块，用于在确定所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度的情况下，根据所述待传输媒体流数据中的音频流数据，生成第二tcp数据包；
140.第三数据包发送模块，用于基于所述主数据通道向所述车辆发送所述第二tcp数据包，以指示所述车辆通过解析所述第二tcp数据包得到相应的音频流数据，并利用车载部件播放所得到的音频流数据。
141.在一种可选实施方式中，还包括：
142.控制包生成模块，用于生成实时传输控制协议rtcp控制包，其中，所述rtcp控制包中包括所述rtp数据包的发送情况信息；
143.控制包发送模块，用于基于rtcp会话向所述车辆发送所述rtcp控制包，以指示所述车辆通过解析所述rtcp控制包得到所述发送情况信息，并根据所述发送情况信息确定丢包信息和/或网络质量信息。
144.在一种可选实施方式中，所述rtcp会话基于主数据通道建立，所述主数据通道基于tcp建立；
145.所述装置还包括：
146.重传指令接收模块，用于基于所述主数据通道和/或所述rtcp会话，接收所述车辆发送的数据包重传指令；
147.重传模块，用于针对所述数据包重传指令所指示的目标rtp数据包进行重传操作。
148.在一种可选实施方式中，所述数据包重传指令由所述车辆根据丢包信息、以及预设车辆性能指标的当前取值和/或网络质量信息生成，所述预设车辆性能指标与所述车辆的数据处理能力相关。
149.在一种可选实施方式中，所述rtcp会话基于主数据通道建立，所述主数据通道基于tcp建立；
150.所述装置还包括：
151.传输指令接收模块，用于基于所述主数据通道和/或所述rtcp会话，接收所述车辆发送的数据包传输指令，其中，所述数据包传输指令由所述车辆根据预设车辆性能指标的当前取值和/或网络质量信息生成，所述数据包传输指令用于指示目标视频帧类型，所述预设车辆性能指标与所述车辆的数据处理能力相关；
152.第四数据包生成模块，用于根据新获取的待传输媒体流数据中，符合所述目标视频帧类型的视频帧数据，生成新rtp数据包；
153.第四数据包发送模块，用于基于所述rtp会话向所述车辆发送所述新rtp数据包，以指示所述车辆通过解析所述新rtp数据包得到相应的第三媒体流数据，并利用车载部件播放所述第三媒体流数据。
154.图7是根据本公开实施例提供的另一种数据传输装置的结构示意图，本公开实施例可适用于在移动终端和车辆之间进行数据传输的情况。该装置可采用硬件和/或软件的方式来实现，可配置于车辆中，该装置可以实现本公开相应实施例所述的数据传输方法。如图7所示，该数据传输装置700包括：
155.第一数据包接收模块701，用于基于实时传输协议rtp会话，接收移动终端发送的rtp数据包，其中，所述移动终端根据获取到的待传输媒体流数据生成所述rtp数据包，所述待传输媒体流数据中包括视频流数据和/或音频流数据，所述rtp会话基于用户数据报协议方式实现；
156.第一数据包解析模块702，用于通过解析所述rtp数据包得到相应的第一媒体流数据；
157.第一播放模块703，用于利用车载部件播放所述第一媒体流数据。
158.本公开实施例提供的技术方案，可以由车辆接收移动终端基于rtp会话发送的根据待传输的媒体流数据生成的rtp数据包，通过解析rtp数据包得到相应的媒体流数据并利用车载部件进行播放，由于rtp会话基于udp方式实现，面向数据传输，可随时开始传输数据包，且不需要保证数据包的正确性和顺序性，不需要处理数据包之间的关联性，可以减少移动终端和车辆的性能开销，另外，不需要提供流量控制或拥塞控制，可避免发生数据阻塞，进而提高数据传输效率，保证数据传输的实时性，使得车辆在播放媒体数据时能够保证流畅性。
159.在一种可选实施方式中，所述移动终端在确定所述待传输媒体流数据满足预设传输条件的情况下，根据所述待传输媒体流数据中的视频流数据生成所述rtp数据包；
160.其中，所述预设传输条件包括以下至少一种：
161.所述待传输媒体流数据中仅包含视频流数据；
162.所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度。
163.在一种可选实施方式中，所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度，包括：
164.所述待传输媒体流数据中包含的视频流数据和音频流数据，来自于非视频播放器类应用程序。
165.在一种可选实施方式中，所述rtp会话基于主数据通道建立，所述主数据通道基于传输控制协议tcp建立；
166.其中，所述装置还包括：
167.第二数据包接收模块，用于基于所述主数据通道接收所述移动终端发送的第一tcp数据包，其中，所述第一tcp数据包由所述移动终端在确定所述待传输媒体流数据不满足所述预设传输条件的情况下，根据所述待传输媒体流数据生成；
168.第二数据包解析模块，用于通过解析所述第一tcp数据包得到相应的第二媒体流数据；
169.第二播放模块，用于利用车载部件播放所述第二媒体流数据。
170.在一种可选实施方式中，还包括：
171.第二会话销毁模块，用于在确定所述待传输媒体流数据不满足所述预设传输条件的情况下，销毁所述rtp会话。
172.在一种可选实施方式中，所述rtp会话基于主数据通道建立，所述主数据通道基于tcp建立；
173.所述装置还包括：
174.第三数据包接收模块，用于基于所述主数据通道接收所述移动终端发送的第二tcp数据包，其中，所述第二tcp数据包由所述移动终端在确定所述待传输媒体流数据中包含的视频流数据和音频流数据之间的关联程度低于预设关联程度的情况下，根据所述待传输媒体流数据中的音频流数据生成；
175.第三数据包解析模块，用于通过解析所述第二tcp数据包得到相应的音频流数据；
176.第三播放模块，用于利用车载部件播放所得到的音频流数据。
177.在一种可选实施方式中，还包括：
178.控制包接收模块，用于基于rtcp会话接收所述移动终端发送实时传输控制协议rtcp控制包，其中，所述rtcp控制包中包括所述rtp数据包的发送情况信息；
179.控制包解析模块，用于通过解析所述rtcp控制包得到所述发送情况信息；
180.信息确定模块，用于根据所述发送情况信息确定丢包信息和/或网络质量信息。
181.在一种可选实施方式中，所述rtcp会话基于主数据通道建立，所述主数据通道基于tcp建立；
182.所述装置还包括：
183.重传指令发送模块，用于基于所述主数据通道和/或所述rtcp会话向所述移动终端发送的数据包重传指令，以指示所述移动终端针对所述数据包重传指令所指示的目标rtp数据包进行重传操作。
184.在一种可选实施方式中，还包括：
185.重传指令生成模块，用于根据丢包信息、以及预设车辆性能指标的当前取值和/或网络质量信息中的至少一项生成所述数据包重传指令，其中，所述预设车辆性能指标与所述车辆的数据处理能力相关。
186.在一种可选实施方式中，所述重传指令生成模块具体用于：
187.在确定预设车辆性能指标的当前取值低于第一预设性能阈值，和/或，根据网络质量信息确定当前网络质量低于第一预设质量阈值的情况下，根据丢包信息将目标视频帧类型的视频帧数据所属的未成功接收的rtp数据包确定为目标rtp数据包，以生成数据包重传指令；其中，所述目标视频帧类型包括关键帧。
188.在一种可选实施方式中，所述rtcp会话基于主数据通道建立，所述主数据通道基于tcp建立；
189.所述装置还包括：
190.传输指令生成模块，用于根据预设车辆性能指标的当前取值和/或网络质量信息生成数据包传输指令，其中，所述数据包传输指令用于指示目标视频帧类型，所述预设车辆性能指标与所述车辆的数据处理能力相关；
191.传输指令发送模块，用于基于所述主数据通道和/或所述rtcp会话，向所述移动终端发送所述数据包传输指令，以指示所述移动终端根据新获取的待传输媒体流数据中，符合所述目标视频帧类型的视频帧数据，生成新rtp数据包，并基于所述rtp会话返回所述新rtp数据包；
192.第四数据包接收模块，用于通过解析所述新rtp数据包得到相应的第三媒体流数据；
193.第四播放模块，用于利用车载部件播放所述第三媒体流数据。
194.在一种可选实施方式中，所述传输指令生成模块具体用于：
195.在确定预设车辆性能指标的当前取值低于第二预设性能阈值，和/或，根据网络质量信息确定当前网络质量低于第二预设质量阈值的情况下，生成数据包传输指令，其中，数据包传输指令所指示的目标视频帧类型包括关键帧。
196.根据本公开的实施例，本公开还提供了一种移动终端、一种车辆、一种可读存储介质和一种计算机程序产品。
197.图8示出了可以用来实施本公开的实施例的示例移动终端800的示意性框图。移动终端旨在表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
198.如图8所示，移动终端800包括计算单元801，其可以根据存储在只读存储器(rom)802中的计算机程序或者从存储单元808加载到随机访问存储器(ram)803中的计算机程序，来执行各种适当的动作和处理。在ram 803中，还可存储移动终端800操作所需的各种程序和数据。计算单元801、rom 802以及ram 803通过总线804彼此相连。输入/输出(i/o)接口805也连接至总线804。
199.移动终端800中的多个部件连接至i/o接口805，包括：输入单元806，例如键盘、鼠标等；输出单元807，例如各种类型的显示器、扬声器等；存储单元808，例如磁盘、光盘等；以及通信单元809，例如网卡、调制解调器、无线通信收发机等。通信单元809允许移动终端800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
200.计算单元801可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元801的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元801执行上文所描述的各个方法和处理，例如数据传输方法。例如，在一些实施例中，数据传输方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元808。在一些实施例中，计算机程序的部分或者全部可以经由rom 802和/或通信单元809而被载入和/或安装到移动终端800上。当计算机程序加载到ram 803并由计算单元801执行时，可以执行上文描述的数据传输方法的一个或多个步骤。备选地，在其他实施例中，计算单元801可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行数据传输方法。
201.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、现场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、复杂可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
202.图9是用来实现本公开实施例的数据传输方法的车辆的框图，车辆900，包括：处理器901，以及与处理器901通信连接的存储器902，其中，存储器902存储有可被处理器901执
行的计算机程序，计算机程序被处理器901执行，以使所述处理器901能够执行本公开实施例中的数据传输方法。其中，处理器的数量可以是一个或多个，图9中以一个处理器为例。
203.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
204.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
205.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
206.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开提供的技术方案所期望的结果，本文在此不进行限制。
207.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。