用于中继的按需本地化视频共享的方法和设备与流程

示意性实施例总体上涉及用于中继的按需本地化视频共享的方法和设备。

背景技术：

路线规划和映射在过去的许多年里得到了极大的改进。客户通常使用提供特定位置的图像的服务来引导他们到目的地或增加对区域的熟悉程度。不幸的是，这些图像通常是静态的，表示映射发生时的时间点。随着自主车辆、拼车服务和联网车辆变得越来越流行，实时地看到感兴趣的区域的需求也在增加。

目前，当数英里外的道路上发生交通堵塞或者数字地图上出现施工区域时，用户几乎没有关于行驶缓慢状况的可用信息。虽然一些地图数据可指示预期的速度限制或延误，但是通常用户对延误的性质、长度和持续时间一无所知。

当前的选择是收听本地无线电台并接收关于交通问题的性质的引导。当然，因为很少有本地无线电台提供持续的交通更新，所以驾驶员可能需要等待近一小时才接收到有用的信息。虽然驾驶员可以总是试图绕过问题或避开问题，但驾驶员这样做可能浪费大量的时间来避免最终成为相当小的问题的问题。由于驾驶员的信息可能仅限于显示存在行驶缓慢状况的地图，因此驾驶员无法得知问题的严重程度。

技术实现要素：

在第一示意性实施例中，一种系统包括处理器，所述处理器被配置为：从主机车辆接收请求，所述请求针对与所述请求中指定的位置有关的视频。所述处理器还被配置为：确定接收到所述请求的候选车辆是否能在接收到所述请求时提供所请求的视频。所述处理器还被配置为：如果候选车辆不能提供所请求的视频，则将所述请求中继到与候选车辆无线通信的收发器，否则记录并发送所请求的视频。

在第二示意性实施例中，一种系统包括处理器，所述处理器被配置为：从主机车辆接收包括位置的视频请求。所述处理器还被配置为：访问当前的候选车辆位置的记录。所述处理器还被配置为：基于所述候选车辆位置，确定在所述位置的预定义阈值距离内的候选车辆。所述处理器还被配置为：向候选车辆发送用于记录视频的指令。所述处理器还被配置为：从候选车辆接收记录的视频并将记录的视频发送到主机车辆。

在第三示意性实施例中，一种计算机实现的方法包括：响应于通过无线传输在候选车辆接收到的来自主机车辆的请求，利用候选车辆相机记录感兴趣区域(aoi)的视频，所述候选车辆包括所述候选车辆相机并执行所述记录。所述方法还包括：将记录的视频发送到无线连接到所述候选车辆的多个收发器，并响应于确定所述候选车辆相机不再能看到所述aoi，将所述请求发送到所述多个收发器。

附图说明

图1示出了示意性的车辆计算系统；

图2a和图2b示出了用于请求和接收按需视频的示意性处理；

图3示出了用于源车辆选择的示意性处理；

图4示出了用于请求终止的示意性处理；

图5示出了用于请求存续的示意性处理。

具体实施方式

根据需要，在此公开具体的实施例；然而，应理解的是，所公开的实施例仅为示意性的，并且可以以多种可替代形式实施。附图无需按比例绘制；可夸大或最小化一些特征以示出特定组件的细节。因此，此处所公开的具体结构和功能细节不应被解释为限制，而仅仅作为用于教导本领域技术人员以多种形式利用所要求保护的主题的代表性基础。

图1示出了用于车辆31的基于车辆的计算系统(vcs)1的示例框式拓扑图。这种基于车辆的计算系统1的示例为由福特汽车公司制造的sync系统。设置有基于车辆的计算系统的车辆可包含位于车辆中的可视前端界面4。如果所述界面设置有例如触摸敏感屏幕，则用户还能够与所述界面进行交互。在另一示意性实施例中，通过按钮按压或具有自动语音识别和语音合成的口语对话系统来进行交互。

在图1所示的示意性实施例1中，处理器3控制基于车辆的计算系统的至少一部分操作。设置在车辆内的处理器允许对命令和例程进行车载处理。另外，处理器连接到非持久性存储器5和持久性存储器7两者。在此示意性实施例中，非持久性存储器是随机存取存储器(ram)，持久性存储器是硬盘驱动器(hdd)或闪存。一般说来，持久性(非暂时性)存储器可包括当计算机或其它装置掉电时保持数据的所有形式的存储器。这些存储器包括但不限于：hdd、cd、dvd、磁带、固态驱动器、便携式usb驱动器和任何其它适当形式的持久性存储器。

处理器还设置有允许用户与处理器进行交互的多个不同的输入。在此示意性实施例中，麦克风29、辅助输入25(用于输入33)、usb输入23、gps输入24、屏幕4(其可为触摸屏显示器)和蓝牙输入15全部被设置。还设置输入选择器51，以允许用户在各种输入之间进行切换。对于麦克风和辅助连接器两者的输入在被传送到处理器之前由转换器27对所述输入进行模数转换。尽管未示出，但是与vcs进行通信的众多车辆组件和辅助组件可使用车辆网络(诸如但不限于can总线)向vcs(或其组件)传送数据并传送来自vcs(或其组件)的数据。

系统的输出可包括但不限于视觉显示器4以及扬声器13或立体声系统输出。扬声器连接到放大器11，并通过数模转换器9从处理器3接收其信号。还可分别沿19和21所示的双向数据流产生到远程蓝牙装置(诸如，个人导航装置(pnd)54)或usb装置(诸如，车辆导航装置60)的输出。

在一个示意性实施例中，系统1使用蓝牙收发器15与用户的移动装置53(例如，蜂窝电话、智能电话、pda或具有无线远程网络连接能力的任何其它装置)进行通信(17)。移动装置随后可被用于通过例如与蜂窝塔57的通信(55)来与车辆31外部的网络61进行通信(59)。在一些实施例中，蜂窝塔57可以是wi-fi接入点。

移动装置与蓝牙收发器之间的示例性通信由信号14表示。

可通过按钮52或类似的输入来指示移动装置53与蓝牙收发器15进行配对。相应地，cpu被指示车载蓝牙收发器将与移动装置中的蓝牙收发器进行配对。

可利用例如与移动装置53关联的数据计划、话上数据或dtmf音在cpu3与网络61之间传送数据。可选地，可期望包括具有天线18的车载调制解调器63以便在cpu3与网络61之间通过语音频带传送数据(16)。移动装置53随后可被用于通过例如与蜂窝塔57的通信(55)来与车辆31外部的网络61进行通信(59)。在一些实施例中，调制解调器63可与蜂窝塔57建立通信20，以与网络61进行通信。作为非限制性示例，调制解调器63可以是usb蜂窝调制解调器，并且通信20可以是蜂窝通信。

在一个示意性实施例中，处理器设置有包括用于与调制解调器应用软件进行通信的api的操作系统。调制解调器应用软件可访问蓝牙收发器上的嵌入式模块或固件，以完成与(诸如在移动装置中发现的)远程蓝牙收发器的无线通信。蓝牙是ieee802pan(个域网)协议的子集。ieee802lan(局域网)协议包括wi-fi并与ieee802pan具有相当多的交叉功能。两者都适合于车辆内的无线通信。可在该领域中使用的另一通信方式是自由空间光通信(诸如irda)和非标准化消费者红外(ir)协议。

在另一实施例中，移动装置53包括用于语音频带或宽带数据通信的调制解调器。在话上数据的实施例中，当移动装置的所有者可在数据被传送的同时通过装置说话时，可实施已知为频分复用的技术。在其它时间，当所有者没有在使用装置时，数据传送可使用整个带宽(在一个示例中是300hz至3.4khz)。尽管频分复用对于车辆与互联网之间的模拟蜂窝通信而言可能是常见的并仍在被使用，但其已经在很大程度上被用于数字蜂窝通信的码域多址(cdma)、时域多址(tdma)、空域多址(sdma)的混合体所替代。如果用户具有与移动装置关联的数据计划，则所述数据计划可允许宽带传输且系统可使用宽得多的带宽(加速数据传送)。在另一实施例中，移动装置53被安装至车辆31的蜂窝通信装置(未示出)所替代。在另一实施例中，移动装置(nd)53可以是能够通过例如(而不限于)802.11g网络(即，wi-fi)或wimax网络进行通信的无线局域网(lan)装置。

在一个实施例中，传入数据可经由话上数据或数据计划通过移动装置，通过车载蓝牙收发器，并进入车辆的内部处理器3。例如，在某些临时数据的情况下，数据可被存储在hdd或其它存储介质7上，直至不再需要所述数据时为止。

可与车辆进行交互的其它的源包括：具有例如usb连接56和/或天线58的个人导航装置54、具有usb连接62或其它连接的车辆导航装置60、车载gps装置24或具有与网络61的连接能力的远程导航系统(未示出)。usb是一类串行联网协议中的一种。ieee1394(火线^tm(苹果)、i.link^tm(索尼)和lynx^tm(德州仪器))、eia(电子工业协会)串行协议、ieee1284(centronics端口)、s/pdif(索尼/飞利浦数字互连格式)和usb-if(usb开发者论坛)形成了装置-装置串行标准的骨干。多数协议可针对电通信或光通信被实施。

此外，cpu可与各种其它的辅助装置65进行通信。这些装置可通过无线连接67或有线连接69来连接。辅助装置65可包括但不限于个人媒体播放器、无线保健装置、便携式计算机等。

此外或可选地，可使用例如wi-fi(ieee803.11)收发器71将cpu连接到基于车辆的无线路由器73。这可允许cpu在本地路由器73的范围内连接到远程网络。

除了由位于车辆中的车辆计算系统执行示例性处理之外，在某些实施例中，还可由与车辆计算系统通信的计算系统来执行示例性处理。这样的系统可包括但不限于：无线装置(例如，但不限于，移动电话)或通过无线装置连接的远程计算系统(例如，但不限于，服务器)。这样的系统可被统称为与车辆关联的计算系统(vacs)。在某些实施例中，vacs的特定组件可根据系统的特定实施方式来执行处理的特定部分。通过示例而并非限制的方式，如果处理具有与配对的无线装置进行发送或者接收信息的步骤，则很可能由于无线装置不会与自身进行信息的“发送和接收”而使得无线装置不执行该处理的这一部分。本领域的普通技术人员将理解何时不适合对给定解决方案应用特定的计算系统。

在每个在此讨论的示意性实施例中，示出了可由计算系统执行的处理的示例性的、非限制的示例。针对每个处理，执行处理的计算系统可出于执行处理的有限目的而变成被配置为用于执行处理的专用处理器。所有的处理不需要全部被执行，并且被理解为是可被执行以实现本发明的要素的多种类型的处理的示例。可根据需要向示例性处理添加额外的步骤或从示例性处理去除额外的步骤。

针对在示出示意性处理流程的附图中描述的示意性实施例，应注意的是，通用处理器可被临时用作专用处理器，以用于执行通过这些附图示出的部分或全部示例性方法的目的。当执行提供用于执行所述方法的部分或全部步骤的指令的代码时，处理器可被临时改用为专用处理器，直到所述方法完成时为止。在另一示例中，在适当的程度上，根据预先配置的处理器运行的固件可使得处理器充当为了执行所述方法或所述方法的某种合理变型的目的而被提供的专用处理器。

尽管交通直升机和交通摄像机偶尔作为直播交通信息的源，但是这些系统通常是高度本地化的并且对于90％以上的现存道路行驶缓慢状况的作用通常很小。此外，因为驾驶员通常不能轻易地访问交通馈送或tv频道，所以由这些源提供的直播视频实际上对在路上的驾驶员是无用的。

直播视频的重要的源是在事件现场具有相机的人员，但同样对于多数驾驶员来说是本质上无用的，这是因为那些驾驶员不能接收直播相机馈送。也就是说，即使有人靠边停车并开始拍摄事件，但事实上没有人在路上能够访问该视频。

许多现代车辆装备有车载外视相机作为车辆感测套件的一部分。这些相机可用作驾驶员辅助系统的一部分，但所述相机还可在上述模型中起到重要作用。通过记录正在发生的事件的视频，车辆提供具有已知位置和通信网络的一部分(通过远程信息处理)的馈送源。

如果用户可访问车辆视频馈送，则该用户能够看到车辆所见。由于多数原始设备制造商(oem)能在驾驶员允许的情况下访问车辆上的数据，所以oem可利用视频点源(在路上的车辆)来向其他客户分发视频。

当然，视频需要大量的带宽和数据存储，所以使在路上的每个车辆不间断地记录、传输和存储连续的视频馈送可能不会非常有效率。此外，通常对没有事件发生的随机路段不感兴趣。然而，通过使用按需模型，车辆可响应于请求而记录视频，这提供了感兴趣的区域(aoi)的有针对性的现场视频。

一种方法利用制造商能力来定位车辆并寻求作为数据提供者的车辆。在此示例中，响应于针对现场视频的请求，oem选择一个或更多个候选视频提供车辆并向这些车辆请求直播馈送。然后，这些直播馈送中的一个或更多个可被传回到请求车辆，以提供aoi的按需直播视频覆盖。

另一个选择利用专用短程通信(dsrc)收发器和其它车辆来形成移动网状网络或自组织网络(mobilemeshorad-hocnetwork)，以沿着道路从车辆到车辆、从收发器到车辆、从车辆到收发器和从收发器到收发器对请求进行中继。在群集足够多的车辆的情况下，可以建立非常长的网络链，并且请求可轻易地传送到驾驶员前方数英里发生事件的位置。基于请求所指示的位置或区域，当请求到达指示的区域时，本地车辆或多个本地车辆响应于请求而开始记录视频。然后这个视频以类似的方式被中继回该请求车辆(或如果优选的话，则直接经由远程信息处理被发送)。只要网络链没有中断，该视频将最终到达目标车辆。

在诸如此类的网络中，除非使用连续的数据通信，否则持续的连接不是必要的。由于车辆可存储数据包直至可到达网络中的下一跳，单个车辆离开一个网络(车辆和收发器的组)并沿着道路行驶20英里到达新的网络(车辆和收发器的组)可有效地形成网络之间的单向桥接，即使没有网络对象具有超过1000英尺左右的通信范围。行驶中的车辆在与第一网络通信时仅存储所有数据包，然后行驶到第二网络并中继所有存储的数据包。

虽然这样的空档阻止了不间断的流式传输，但是它允许自组织网络基本上覆盖全国的道路网络而不需要每100英尺或1000英尺物理地提供接入点或中继。尽管数据不是即时直播的(即，视频是5分钟前发生的事情，而不是现在的情况)，但是即使在最坏的情况下数据实际上也是“足够生动的”并因此向请求的驾驶员提供比可能从相对静止的地图获得的信息多得多的信息。如果有不间断的数据流(车辆和收发器在数据源和请求的车辆之间处于足够近的接近度内)，则数据可接近实时地被中继回请求方。

图2a和图2b示出了用于请求和接收按需视频的示意性处理。在此示例中，在201，用户车辆(主机车辆)请求来自目标位置的视频。用户可通过选择地图位置、地图区域、交通或行驶缓慢事件、感兴趣的点(poi)等来指定位置。尽管可能是单独的点位置，但是为方便起见区域在此被称为感兴趣的区域(aoi)。

然后，在203，主机车辆通过dsrc网络或利用远程信息处理系统广播针对视频的请求。两个选项可同时使用，或者车辆可选择优选的选项。请求可包括例如主机标识符、主机位置和指示的aoi。当用户可指定点或区域时，处理可利用被认为在aoi视线范围内的车辆，使得响应请求的车辆不必须物理地位于aoi或位置来为请求提供服务。确定处理可利用阈值周界和相机朝向(相机能看到的内容)来选择特定的候选车辆。

在示出的远程信息处理的示例中，在205，处理利用蜂窝网络(lte网络)为请求提供服务。主机车辆将请求发送到云服务器，其中，在207，云服务器确定在指定的aoi的阈值距离内的一个或更多个车辆。在选择候选车辆时，云服务器还可考虑拥堵(可能阻挡低位相机)和/或车辆行驶方向等。

一旦云服务器确定了候选车辆，则在209，云服务器将请求发送到确定的候选车辆。车辆接收还可包括参数集(诸如，记录时间、aoi坐标等)的请求。车辆可利用参数来确认选择的候选车辆的适用性，并且可在211在合适的情况下发送回现场相机馈送。如果选择的候选车辆不能为请求提供服务或不满足参数，则车辆可拒绝请求，并且云服务器可选择另一个候选车辆。

在213，云服务器将视频从目标车辆中继到主机车辆，主机车辆因此接收由目标车辆相机记录的接近实况的录像片段(footage)。只要在215主机车辆持续请求视频，处理就可利用当前目标车辆或新的目标车辆(如果先前的车辆出于某种原因而不能为请求提供服务的话)而继续进行。

在还在图2a和图2b中示出的示意性替代方案中，在217，处理利用车辆到车辆(v2v)和/或车辆到基础设施(v2i)网络(217)来将请求中继跳转到一个或更多个候选车辆。在这个示例中，给定车辆在219从主机接收请求，并在211自我确定该给定车辆是否满足与请求关联的参数(例如而非限制，给定车辆是否在aoi阈值距离内、是否具有合适的行驶方向、对于有用的相机数据来说车流是否太密集等)。

如果给定车辆确定它不适合为请求提供服务，则在223车辆将请求级联传递(cascade)到更多车辆和基础设施。在一个模型中，这可包括将请求发送到与给定车辆通信的所有其它车辆和收发器，但是还可利用限制所述级联传递的其它模型。自我确定处理在每个接收到请求的车辆中重复，直到车辆确认其可为请求提供服务。

所述级联传递的模型的一个明显的问题是请求基本上会在车辆之间反弹持续不确定量的时间，而特定车辆已经在为请求提供服务。这可能导致大量的候选车辆试图不必要地为请求提供服务，因此图4示出了在选择了候选车辆之后如何终止请求的示例。另一个选项是对请求设置短的有效期，使得请求的级联传递在合理的短时间段内结束，然后如果一个或更多个车辆在为请求提供服务，则主机接收到馈送，并且如果主机在所述时间段内没有接收到馈送，则主机可重新发送请求(因为跳转中继(hop-relay)将因超时而终止)。在重新尝试之前，主机也可以内置用于容纳视频返回到主机的时间的时间缓冲，使得主机不会在视频馈送正在传入但只是尚未到达主机时重新发送请求。

一旦合适的目标车辆接收到级联传递的请求，则在224，该车辆广播通过车辆相机记录的所请求的aoi的视频馈送。在225，这个消息被在主机和目标(候选)车辆之间的其它车辆和基础设施接收。在227，每个接收到馈送的车辆可自我确定该车辆是否为主机，并且如果该车辆不是主机，则在229，该车辆以类似于请求传递的方式级联传递视频馈送。在这个模型中，在链中的任意特定车辆也可选择开始接收视频，这将向中间驾驶员提供感兴趣的区域的偶然录像片段，如果该aoi是也将影响这些驾驶员的事故或其它行驶缓慢状况则这会是有用的。

一旦请求到达主机车辆，则在231，主机车辆显示录像片段或馈送(这可基于网络可持续性或用户请求而变化)。如果在233用户想要额外的录像片段或者想要馈送继续进行，则可重复请求和返回处理。

图3示出了用于源车辆选择的示意性处理。在此示例中，处理利用请求所指定的参数来选择用于请求服务的一个或更多个候选车辆。在301，处理从主机车辆接收请求，所述请求至少指示感兴趣的区域。还可包括主机车辆的行驶方向或位置，使得在aoi与交通相关并且在道路的与主机车辆相反的一侧上存在拥堵的情况下，该数据可能不一定是相关的。这还可有助于防止选择不合适的候选(有时可包括向反方向行驶的车辆)。从记录的角度来看，相反的车流有时可以是有用的，因为如果不被拥堵影响的话该车流可以快速地捕捉整个拥堵，所以反向行驶的车辆不总是被忽略，但在其它情况下，这些车辆可位于在正确的aoi内但不被定位成提供很多感兴趣的数据。

在303，接收到请求的云服务器访问数据库，所述数据库包括多个可能的候选车辆的当前车辆位置。例如，云服务器可围绕aoi设置预定义的周界，并且可检查在所述周界内的所有可能的车辆。所述周界可基于什么样的车辆相机位置看到请求的aoi、区域内的交通、树木、建筑等的密集程度等。在一个实例中，围绕aoi的50英尺的周界可能是合适的，并且在另一个实例中，500英尺的周界可能是合适的。

基于给定的车辆相机可看到并记录aoi的合理预期，处理可在305选择一个或更多个候选车辆用于向请求提供服务。如果没有候选，则处理可在309向主机车辆报告错误。在此示例中，尽管也可考虑超时和其它终止条件，但是处理持续尝试查找候选直到在311主机车辆到达目标位置。一旦主机车辆实际到达目标位置，则处理在313终止。另一方面，如果在主机到达该位置前找到候选，则处理在307选择候选并且继续将请求发送到这些车辆。单个候选可足以服务于多数请求，但还可根据需要使用来自多个候选的多个馈送。

图4示出了用于请求终止的示意性处理。在此示例中，所述处理用于基于特定车辆正在向处理提供服务的事实而终止当前请求。在级联传递模型中，几乎不可能确定哪些车辆当前持有请求并试图做出响应，所以对于服务车辆而言可能难以简单地直接联系所有其它候选并告知它们请求正在被处理。相反，在此示例中，在401，进行记录的当前的目标(候选)车辆可向周围车辆发送停止指令。这可包括例如发送请求标识符使得周围车辆知道停止指令涉及到哪个请求。

接收到停止指令的周围车辆可终止为请求提供服务的尝试并终止对请求进行中继。如果包括了请求标识符，则这些车辆还可忽略进一步的请求到车辆的传输。这可迅速终止请求(由于可推测的是停止级联传递的跳转将最早到达与当前的目标/候选车辆在相同区域内的其它候选车辆)并可有助于防止主机车辆接收到来自大量目标车辆的大量响应视频馈送。在403，车辆可按照级联传递的方式将请求发送到本地车辆以终止请求，并且在405，目标车辆可使用主机车辆信息来直接向主机车辆发送终止命令，以防止请求(其正在由目标提供服务)的重新发送。

图5示出了用于请求存续的示意性处理。在此示例中，主机用户可能请求了五分钟的视频馈送或者请求可具有与其相关联的五分钟的超时时间。根据行驶状况，初始目标车辆可能无法在整个指定时间段内向请求提供服务。这个示例并不是强制主机重新发送请求(这也是可能的)，而是示出了目标车辆如何能够在目标无法再向请求提供服务的情况下使请求存续。

在此示例中，在501，可能的目标车辆接收请求并可进行自我选择处理或类似处理。如果在503车辆不能向请求提供服务，则在505，车辆可丢弃请求(如果适当的话，则在将请求传递给其它车辆之后丢弃请求)。

如果目标车辆开始记录，则处理可参照包括的aoi坐标或者在507访问交通数据(在aoi可基于事件规模而是动态的其它实例中)，以在509确定目标车辆是否仍然在合适的aoi内。只要车辆保持在aoi内，则处理可继续发送相机数据。

一旦车辆离开aoi，则处理确定请求是否已结束，在此示例中包括在511检查原始请求的持续时间。例如，如果目标车辆针对三十秒的请求仅能够捕捉几秒的交通状况，则主机车辆驾驶员可能仍然对额外数据感兴趣。在511，目标车辆确定请求时间是否到期，而不是让主机发送新请求。如果请求还没结束，则在515，目标车辆对请求进行中继(例如，利用级联传递模型)。原始主机车辆仍然在请求中被指定，所以如果另一个目标车辆向请求提供服务，则数据将使其返回到主机车辆。否则，在513，目标车辆仅结束传输(如果请求时间已到期)。

利用示意性示例，驾驶员可获得代表感兴趣的区域内或感兴趣的点处的当前事件的实时或接近实时的录像片段和流数据。这可帮助解决涉及行驶缓慢的大量不确定性，并还可向没有经验的驾驶员提供即将到来的区域的图像。通过使用其它车辆和基础设施，可请求和接收数据而不需实施明确地被设计为专门用于收集这些数据的新系统。

尽管上面描述了示例性实施例，但并不意在这些实施例描述了本发明的所有可能形式。更确切地，说明书中使用的词语为描述性词语而非限制性词语，并且应理解的是，可在不脱离本发明的精神和范围的情况下做出各种改变。此外，可以以逻辑方式组合各种实现的实施例的特征，以产生在此描述的实施例的情境适当的变型。