Method and apparatus for on-demand localized video sharing for relay

Abstract

The present invention discloses a method and apparatus for relayed on-demand localized video sharing. A system includes a processor configured to: receive a request from a host vehicle, the request being for a video related to a location specified in the request. The processor is also configured to: determine whether a candidate vehicle receiving the request can provide the requested video upon receiving the request. The processor is also configured to: if the candidate vehicle cannot provide the requested video, relay the request to a transceiver in wireless communication with the candidate vehicle, otherwise record and send the requested video.

Description

Technical Field

[0001] The illustrative embodiments generally relate to methods and apparatus for relayed, on-demand localized video sharing. Background Art

[0002] Route planning and mapping have improved dramatically over the past many years. Customers often use services that provide imagery of a specific location to guide them to their destination or increase familiarity with an area. Unfortunately, these images are typically static, representing a point in time when the mapping occurred. As autonomous vehicles, ride-sharing services, and connected vehicles become more popular, the need to see areas of interest in real time increases.

[0003] Currently, when a traffic jam occurs miles down the road or a construction zone appears on a digital map, users have little information available about the slowdown. While some map data may indicate expected speed limits or delays, users are often left in the dark about the nature, length and duration of the delay.

[0004] The current option is to listen to a local radio station and receive guidance on the nature of the traffic problem. Of course, because few local radio stations provide constant traffic updates, the driver may have to wait nearly an hour before receiving useful information. While the driver can always try to go around the problem or avoid it, in doing so the driver may waste a significant amount of time avoiding what ultimately becomes a fairly minor problem. Because the driver's information may be limited to a map showing that there is a slow moving condition, the driver has no idea of ​​the severity of the problem. Summary of the invention

[0005] In a first illustrative embodiment, a system includes a processor configured to: receive a request from a host vehicle for a video associated with a location specified in the request. The processor is further configured to: determine whether a candidate vehicle receiving the request can provide the requested video upon receiving the request. The processor is further configured to: if the candidate vehicle cannot provide the requested video, relay the request to a transceiver in wireless communication with the candidate vehicle, otherwise record and transmit the requested video.

[0006] In a second illustrative embodiment, a system includes a processor configured to: receive a video request including a location from a host vehicle. The processor is further configured to: access a record of current candidate vehicle locations. The processor is further configured to: determine candidate vehicles within a predefined threshold distance of the location based on the candidate vehicle locations. The processor is further configured to: send instructions to the candidate vehicles to record video. The processor is further configured to: receive recorded video from the candidate vehicles and send the recorded video to the host vehicle.

[0007] In a third illustrative embodiment, a computer-implemented method includes recording a video of an area of ​​interest (AOI) using a candidate vehicle camera in response to a request received from a host vehicle via wireless transmission at a candidate vehicle, the candidate vehicle including the candidate vehicle camera and performing the recording. The method also includes transmitting the recorded video to a plurality of transceivers wirelessly connected to the candidate vehicle, and in response to determining that the candidate vehicle camera no longer sees the AOI, transmitting the request to the plurality of transceivers. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 An illustrative vehicle computing system is shown;

[0009] Figure 2A and Figure 2B An illustrative process for requesting and receiving on-demand video is shown;

[0010] Figure 3 An illustrative process for source vehicle selection is shown;

[0011] Figure 4 An illustrative process for requesting termination is shown;

[0012] Figure 5 An illustrative process for requesting continuation is shown. DETAILED DESCRIPTION

[0013] As required, specific embodiments are disclosed herein; however, it should be understood that the disclosed embodiments are merely illustrative and may be implemented in a variety of alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching those skilled in the art to utilize the claimed subject matter in a variety of forms.

[0014] Figure 1 An example block topology diagram of a vehicle-based computing system (VCS) 1 for a vehicle 31 is shown. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by Ford Motor Company. A vehicle provided with a vehicle-based computing system may include a visual front end interface 4 located in the vehicle. If the interface is provided with, for example, a touch sensitive screen, a user may also be able to interact with the interface. In another exemplary embodiment, the interaction is performed by button presses or a spoken dialog system with automatic speech recognition and speech synthesis.

[0015] exist Figure 1In the illustrated exemplary embodiment 1, a processor 3 controls at least a portion of the operation of a vehicle-based computing system. The processor disposed within the vehicle allows for onboard processing of commands and routines. In addition, the processor is connected to both non-persistent memory 5 and persistent memory 7. In this exemplary embodiment, the non-persistent memory is a random access memory (RAM) and the persistent memory is a hard disk drive (HDD) or flash memory. In general, persistent (non-temporary) memory may include all forms of memory that retain data when a computer or other device loses power. These memories include, but are not limited to, HDDs, CDs, DVDs, tapes, solid-state drives, portable USB drives, and any other suitable form of persistent memory.

[0016] The processor is also provided with a number of different inputs that allow the user to interact with the processor. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 (which may be a touch screen display), and a Bluetooth input 15 are all provided. An input selector 51 is also provided to allow the user to switch between the various inputs. The inputs to both the microphone and the auxiliary connector are converted to digital by a converter 27 before being transmitted to the processor. Although not shown, the numerous vehicle components and auxiliary components that communicate with the VCS may transmit data to and from the VCS (or its components) using a vehicle network (such as, but not limited to, a CAN bus).

[0017] The outputs of the system may include, but are not limited to, a visual display 4 and a speaker 13 or stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. Outputs may also be generated to a remote BLUETOOTH device (such as a personal navigation device (PND) 54) or a USB device (such as a vehicle navigation device 60) along the bidirectional data streams shown at 19 and 21, respectively.

[0018] In one illustrative embodiment, system 1 communicates with a user's mobile device 53 (e.g., a cell phone, smart phone, PDA, or any other device with wireless remote network connection capability) using Bluetooth transceiver 15 (17). The mobile device can then be used to communicate with a network 61 outside of vehicle 31 (59) by, for example, communicating (55) with a cellular tower 57. In some embodiments, cellular tower 57 can be a Wi-Fi access point.

[0019] Exemplary communication between the nomadic device and the Bluetooth transceiver is represented by signal 14 .

[0020] The nomadic device 53 may be instructed to pair with the Bluetooth transceiver 15 via a button 52 or similar input. Accordingly, the CPU is instructed that the onboard Bluetooth transceiver will pair with the Bluetooth transceiver in the nomadic device.

[0021] Data may be transferred between the CPU 3 and the network 61 using, for example, a data plan associated with the nomadic device 53, data over voice, or DTMF tones. Optionally, it may be desirable to include an onboard modem 63 having an antenna 18 to transfer data between the CPU 3 and the network 61 over the voice band (16). The nomadic device 53 may then be used to communicate with the network 61 outside the vehicle 31 (59) by, for example, communicating with a cellular tower 57 (55). In some embodiments, the modem 63 may establish communication 20 with the cellular tower 57 to communicate with the network 61. As a non-limiting example, the modem 63 may be a USB cellular modem and the communication 20 may be a cellular communication.

[0022] In one illustrative embodiment, the processor is provided with an operating system including an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to complete wireless communication with a remote Bluetooth transceiver (such as found in a mobile device). Bluetooth is a subset of the IEEE 802PAN (Personal Area Network) protocol. The IEEE 802LAN (Local Area Network) protocol includes Wi-Fi and has considerable cross-functionality with IEEE 802PAN. Both are suitable for wireless communication within a vehicle. Another communication method that can be used in this field is free space optical communication (such as IrDA) and non-standardized consumer infrared (IR) protocols.

[0023] In another embodiment, the nomadic device 53 includes a modem for voice band or broadband data communications. In the data-over-voice embodiment, when the owner of the nomadic device can speak through the device while data is being transmitted, a technique known as frequency division multiplexing can be implemented. At other times, when the owner is not using the device, data transmission can use the entire bandwidth (300Hz to 3.4kHz in one example). Although frequency division multiplexing may be common and still used for analog cellular communications between vehicles and the Internet, it has been largely replaced by a mixture of code domain multiple access (CDMA), time domain multiple access (TDMA), and space domain multiple access (SDMA) for digital cellular communications. If the user has a data plan associated with the nomadic device, the data plan can allow broadband transmission and the system can use a much wider bandwidth (speeding up data transmission). In another embodiment, the nomadic device 53 is replaced by a cellular communication device (not shown) installed to the vehicle 31. In another embodiment, the nomadic device (ND) 53 can be a wireless local area network (LAN) device capable of communicating through, for example (but not limited to), an 802.11g network (i.e., Wi-Fi) or a WiMax network.

[0024] In one embodiment, incoming data may pass through the nomadic device via a data-over-voice or data plan, through the onboard BLUETOOTH transceiver, and into the vehicle's internal processor 3. For example, in the case of certain temporary data, the data may be stored on a HDD or other storage medium 7 until the data is no longer needed.

[0025] Other sources that may interact with the vehicle include a personal navigation device 54 having, for example, a USB connection 56 and / or an antenna 58, a vehicle navigation device 60 having a USB connection 62 or other connection, an onboard GPS device 24, or a remote navigation system (not shown) having the ability to connect to a network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire TM (Apple), i.LINK TM (Sony) and Lynx TM (Texas Instruments), EIA (Electronic Industries Association) serial protocol, IEEE 1284 (Centronics port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of device-to-device serial standards. Most protocols can be implemented for either electrical or optical communication.

[0026] Additionally, the CPU may communicate with various other auxiliary devices 65. These devices may be connected via wireless connections 67 or wired connections 69. Auxiliary devices 65 may include, but are not limited to, personal media players, wireless healthcare devices, portable computers, and the like.

[0027] Additionally or alternatively, the CPU may be connected to a vehicle based wireless router 73 using, for example, a Wi-Fi (IEEE 803.11) transceiver 71. This may allow the CPU to connect to a remote network while within range of the local router 73.

[0028] In addition to the exemplary processing being performed by a vehicle computing system located in a vehicle, in certain embodiments, the exemplary processing may also be performed by a computing system in communication with the vehicle computing system. Such systems may include, but are not limited to, wireless devices (e.g., but not limited to, mobile phones) or remote computing systems (e.g., but not limited to, servers) connected via wireless devices. Such systems may be collectively referred to as vehicle associated computing systems (VACS). In certain embodiments, specific components of the VACS may perform specific portions of the processing depending on the specific implementation of the system. By way of example and not limitation, if a processing has a step of sending or receiving information with a paired wireless device, it is likely that the wireless device will not perform this portion of the processing because the wireless device will not "send and receive" information with itself. One of ordinary skill in the art will understand when it is not appropriate to apply a particular computing system to a given solution.

[0029] In each of the illustrative embodiments discussed herein, exemplary, non-limiting examples of processes that may be performed by a computing system are shown. For each process, the computing system performing the process may become a dedicated processor configured to perform the process for the limited purpose of performing the process. All processes need not be performed in their entirety, and are understood to be examples of various types of processes that may be performed to implement elements of the present invention. Additional steps may be added to or removed from the exemplary processes as desired.

[0030] With respect to the illustrative embodiments described in the accompanying drawings showing illustrative process flows, it should be noted that a general-purpose processor may be temporarily used as a special-purpose processor for the purpose of performing some or all of the exemplary methods shown by these drawings. When executing code providing instructions for performing some or all of the steps of the method, the processor may be temporarily repurposed as a special-purpose processor until the method is completed. In another example, to the extent appropriate, firmware running on a pre-configured processor may cause the processor to act as a special-purpose processor provided for the purpose of performing the method or some reasonable variation of the method.

[0031] Although traffic helicopters and traffic cameras occasionally serve as sources of live traffic information, these systems are typically highly localized and are generally ineffective for more than 90% of existing road slowdowns. Furthermore, the live video provided by these sources is virtually useless to drivers on the road because drivers typically cannot easily access traffic feeds or TV channels.

[0032] An important source of live video is a person with a camera at the scene of the incident, but again, it is essentially useless to most drivers because those drivers cannot receive a live camera feed. That is, even if someone pulls over and starts filming the incident, virtually no one on the road can access the video.

[0033] Many modern vehicles are equipped with onboard exterior cameras as part of the vehicle's sensing suite. These cameras can be used as part of a driver assistance system, but they can also play an important role in the models described above. By recording video of what is happening, the vehicle provides a feed source with a known location and part of a communications network (via telematics).

[0034] If a user has access to the vehicle video feed, the user can see what the vehicle sees. Since most original equipment manufacturers (OEMs) can access data on the vehicle with the driver's permission, the OEM can use the video point source (the vehicle on the road) to distribute video to other customers.

[0035] Of course, video requires a lot of bandwidth and data storage, so having every vehicle on the road constantly record, transmit, and store a continuous video feed may not be very efficient. In addition, random sections of the road where no events are occurring are usually of little interest. However, by using an on-demand model, vehicles can record video in response to requests, which provides targeted live video of areas of interest (AOIs).

[0036] One approach leverages manufacturer capabilities to locate vehicles and seeks vehicles as data providers. In this example, in response to a request for live video, the OEM selects one or more candidate video providing vehicles and requests live feeds from those vehicles. One or more of these live feeds can then be transmitted back to the requesting vehicle to provide on-demand live video coverage of the AOI.

[0037] Another option is to use dedicated short-range communication (DSRC) transceivers and other vehicles to form a mobile mesh or ad-hoc network to relay requests from vehicle to vehicle, from transceiver to vehicle, from vehicle to transceiver, and from transceiver to transceiver along the road. With enough vehicles in the cluster, very long network chains can be established, and requests can be easily transmitted to the location of the incident miles ahead of the driver. Based on the location or area indicated by the request, when the request reaches the indicated area, the local vehicle or multiple local vehicles respond to the request and begin recording video. This video is then relayed back to the requesting vehicle in a similar manner (or sent directly via telematics if preferred). As long as the network chain is not interrupted, the video will eventually reach the target vehicle.

[0038] In networks such as these, a continuous connection is not necessary unless continuous data communication is used. Since the vehicle can store packets until the next hop in the network can be reached, a single vehicle leaving one network (group of vehicle and transceiver) and traveling 20 miles down the road to a new network (group of vehicle and transceiver) can effectively form a one-way bridge between networks, even though no network object has a communication range of more than 1000 feet or so. The moving vehicle simply stores all packets while communicating with the first network, then travels to the second network and relays all stored packets.

[0039] While such gaps prevent uninterrupted streaming, it allows a self-organizing network to essentially cover a nationwide road network without physically providing access points or relays every 100 or 1000 feet. Although the data is not live in real time (i.e., the video is of what happened 5 minutes ago, not what is happening now), even in the worst case the data is actually "live enough" and thus provides the requesting driver with much more information than what might be obtained from a relatively static map. If there is an uninterrupted data stream (the vehicle and transceiver are in close enough proximity between the data source and the requesting vehicle), the data can be relayed back to the requester in near real time.

[0040] Figure 2A and Figure 2B An illustrative process for requesting and receiving on-demand video is shown. In this example, at 201, a user vehicle (host vehicle) requests video from a target location. The user may specify a location by selecting a map location, a map area, a traffic or slow-moving event, a point of interest (POI), etc. Although individual point locations are possible, for convenience an area is referred to herein as an area of ​​interest (AOI).

[0041] Then, at 203, the host vehicle broadcasts a request for video over the DSRC network or using a telematics system. Both options may be used simultaneously, or the vehicle may select a preferred option. The request may include, for example, a host identifier, a host location, and an indicated AOI. When a user may specify a point or area, the process may utilize vehicles that are considered to be within the line of sight of the AOI, so that a vehicle responding to the request does not have to be physically located at the AOI or location to service the request. The determination process may utilize threshold perimeters and camera orientation (what the camera can see) to select specific candidate vehicles.

[0042] In the example of telematics shown, the process utilizes a cellular network (LTE network) to service the request at 205. The host vehicle sends the request to the cloud server, where the cloud server determines one or more vehicles within a threshold distance of the specified AOI at 207. When selecting candidate vehicles, the cloud server may also consider congestion (potentially blocking the low-position camera) and / or the direction of vehicle travel, etc.

[0043] Once the cloud server determines the candidate vehicles, the cloud server sends a request to the determined candidate vehicles 209. The vehicle receives the request, which may also include a set of parameters, such as recording time, AOI coordinates, etc. The vehicle may use the parameters to confirm the suitability of the selected candidate vehicle and may send back a live camera feed if appropriate at 211. If the selected candidate vehicle cannot service the request or does not meet the parameters, the vehicle may reject the request and the cloud server may select another candidate vehicle.

[0044] At 213, the cloud server relays the video from the target vehicle to the host vehicle, which thus receives near-live footage recorded by the target vehicle's camera. As long as the host vehicle continues to request video at 215, processing can continue using the current target vehicle or a new target vehicle if the previous vehicle cannot service the request for some reason.

[0045] In still Figure 2A and Figure 2B In the exemplary alternative illustrated in , at 217, processing utilizes a vehicle-to-vehicle (V2V) and / or vehicle-to-infrastructure (V2I) network (217) to relay the request to one or more candidate vehicles. In this example, a given vehicle receives the request from the host at 219 and self-determines at 211 whether the given vehicle satisfies the parameters associated with the request (for example, but not limitation, whether the given vehicle is within an AOI threshold distance, has a suitable heading, traffic is too dense for useful camera data, etc.).

[0046] If a given vehicle determines that it is not suitable to service the request, the vehicle cascades the request to more vehicles and infrastructure 223. In one model, this may include sending the request to all other vehicles and transceivers in communication with the given vehicle, but other models that limit the cascade may also be utilized. The self-determination process repeats in each vehicle that receives the request until the vehicle confirms that it can service the request.

[0047] An obvious problem with the cascading model is that requests will essentially bounce between vehicles for an indeterminate amount of time while a particular vehicle is already servicing the request. This can result in a large number of candidate vehicles trying to service the request unnecessarily, thus Figure 4 An example of how the request can be terminated after a candidate vehicle has been selected is shown. Another option is to set a short expiration time on the request so that the cascade of requests ends in a reasonably short period of time, and then if one or more vehicles are servicing the request, the host receives the feed, and if the host does not receive the feed within the period of time, the host can resend the request (because the hop-relay will terminate due to a timeout). The host can also have a time buffer built in to accommodate the time it takes for the video to return to the host before retrying, so that the host does not resend the request when the video feed is incoming but just has not yet reached the host.

[0048] Once the appropriate target vehicle receives the request for cascade delivery, then at 224, the vehicle broadcasts a video feed of the requested AOI recorded by the vehicle's camera. At 225, this message is received by other vehicles and infrastructure between the host and target (candidate) vehicles. At 227, each vehicle receiving the feed can self-determine whether the vehicle is the host, and if the vehicle is not the host, then at 229, the vehicle cascades the video feed in a manner similar to the request delivery. In this model, any particular vehicle in the chain can also choose to begin receiving video, which will provide intermediate drivers with occasional video footage of the area of ​​interest, which can be useful if the AOI is an accident or other slow-moving condition that will also affect these drivers.

[0049] Once the request reaches the host vehicle, the host vehicle displays the video clip or feed (which may vary based on network sustainability or user request) 231. If the user wants additional video clips or wants the feed to continue 233, the request and return process may be repeated.

[0050] Figure 3An illustrative process for source vehicle selection is shown. In this example, the process selects one or more candidate vehicles for the requested service using parameters specified by the request. At 301, the process receives a request from a host vehicle, the request indicating at least an area of ​​interest. The direction of travel or location of the host vehicle may also be included, so that in the case where the AOI is related to traffic and there is congestion on the side of the road opposite to the host vehicle, this data may not necessarily be relevant. This may also help prevent the selection of inappropriate candidates (which may sometimes include vehicles traveling in the opposite direction). From a recording perspective, opposing traffic flow can sometimes be useful because it can quickly capture the entire congestion if it is not affected by the congestion, so vehicles traveling in the opposite direction are not always ignored, but in other cases, these vehicles may be located within the correct AOI but not positioned to provide much interesting data.

[0051] At 303, the cloud server receiving the request accesses a database including the current vehicle positions of a plurality of possible candidate vehicles. For example, the cloud server may set a predefined perimeter around the AOI and may check all possible vehicles within the perimeter. The perimeter may be based on what vehicle camera position sees the requested AOI, the density of traffic, trees, buildings, etc. in the area, etc. In one example, a 50-foot perimeter around the AOI may be appropriate, and in another example, a 500-foot perimeter may be appropriate.

[0052] Based on a reasonable expectation that a given vehicle camera can see and record the AOI, the process may select one or more candidate vehicles for servicing the request at 305. If there are no candidates, the process may report an error to the host vehicle at 309. In this example, the process continues to attempt to find a candidate until the host vehicle reaches the target location at 311, although timeouts and other termination conditions may also be considered. Once the host vehicle actually reaches the target location, the process terminates at 313. On the other hand, if a candidate is found before the host reaches the location, the process selects the candidate at 307 and continues to send requests to those vehicles. A single candidate may be sufficient to service most requests, but multiple feeds from multiple candidates may also be used as needed.

[0053] Figure 4An illustrative process for requesting termination is shown. In this example, the process is used to terminate the current request based on the fact that a particular vehicle is currently servicing the process. In a cascade delivery model, it is nearly impossible to determine which vehicles are currently holding requests and attempting to respond, so it may be difficult for the serving vehicle to simply contact all other candidates directly and inform them that a request is being processed. Instead, in this example, at 401, the current target (candidate) vehicle making the record may send a stop command to surrounding vehicles. This may include, for example, sending a request identifier so that surrounding vehicles know which request the stop command relates to.

[0054] Surrounding vehicles that receive the stop command may terminate attempts to service the request and cease relaying the request. If a request identifier is included, these vehicles may also ignore further transmissions of requests to the vehicle. This may terminate the request quickly (since it is presumably that the jump to stop the cascaded transfer will reach other candidate vehicles in the same area as the current target / candidate vehicle at the earliest) and may help prevent the host vehicle from receiving a large number of responsive video feeds from a large number of target vehicles. At 403, the vehicle may send the request to the local vehicle in a cascaded manner to terminate the request, and at 405, the target vehicle may use the host vehicle information to send a termination command directly to the host vehicle to prevent the request (which is being serviced by the target) from being resent.

[0055] Figure 5 An illustrative process for request persistence is shown. In this example, the host user may have requested a five minute video feed or the request may have a five minute timeout associated with it. Depending on driving conditions, the initial target vehicle may not be able to service the request for the entire specified time period. This example is not to force the host to resend the request (which is also possible), but rather to show how the target vehicle can persist the request in the event that the target can no longer service the request.

[0056] In this example, a possible target vehicle receives the request and may perform a self-selection process or similar process 501. If the vehicle cannot provide service to the request 503, the vehicle may discard the request 505 (after passing the request to other vehicles if appropriate).

[0057] If the target vehicle begins recording, the process may reference the included AOI coordinates or access traffic data at 507 (in other instances where the AOI may be dynamic based on the size of the event) to determine if the target vehicle is still within the appropriate AOI at 509. As long as the vehicle remains within the AOI, the process may continue to send camera data.

[0058] Once the vehicle leaves the AOI, the process determines whether the request has ended, including in this example checking the duration of the original request at 511. For example, if the target vehicle was only able to capture a few seconds of traffic conditions for a thirty-second request, the host vehicle driver may still be interested in additional data. At 511, the target vehicle determines whether the request time has expired, rather than having the host send a new request. If the request has not ended, at 515, the target vehicle relays the request (e.g., utilizing a cascade delivery model). The original host vehicle is still specified in the request, so if another target vehicle services the request, the data will make it back to the host vehicle. Otherwise, at 513, the target vehicle simply ends the transmission (if the request time has expired).

[0059] By way of illustrative example, a driver may obtain real-time or near real-time video footage and streaming data representing current events within an area or point of interest. This may help resolve a great deal of uncertainty associated with slow travel and may also provide an image of an upcoming area to an inexperienced driver. By using other vehicles and infrastructure, data may be requested and received without the need to implement a new system explicitly designed specifically for collecting such data.

[0060] Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of the invention. In addition, the features of various implemented embodiments may be combined in a logical manner to produce context-appropriate variations of the embodiments described herein.

Claims

1. A system for video sharing, comprising: The processor is configured as: receiving a request from a host vehicle for a video associated with a location specified in the request; determining whether the candidate vehicle receiving the request can provide the requested video upon receiving the request; If the candidate vehicle can provide the requested video, recording and sending the requested video; If the candidate vehicle is unable to provide the requested video and the original time limit associated with the request has not expired, the request is relayed to a transceiver in wireless communication with the candidate vehicle.

2. The system of claim 1, wherein: The request includes a host identifier, and wherein the processor is configured to include the host identifier in the transmission of the requested video.

3. The system of claim 1, wherein: The transceiver is a transceiver of another vehicle.

4. The system of claim 1, wherein: The transceiver is an infrastructure transceiver.

5. The system of claim 1, wherein: The processor is configured to send the requested video directly back to the host vehicle over a cellular network based on a host vehicle identification included in the request.

6. The system of claim 1, wherein: The processor is configured to transmit the requested video to a transceiver in wireless communication with the candidate vehicle.

7. The system of claim 1, wherein: The processor is further configured to: receiving, at the candidate vehicle, a video transmission from a wirelessly connected vehicle including a host identifier; Based on determining that the candidate vehicle corresponds to the host identifier, the video transmission is returned.

8. The system of claim 7, wherein: The processor is further configured to: providing a video transmission for return based on determining that the candidate vehicle does not correspond to the host identifier; The video transmission is relayed to a transceiver in wireless communication with the candidate vehicle.

9. The system of claim 7, wherein: The wirelessly connected vehicle is the video originating vehicle.

10. The system of claim 7, wherein: The wirelessly connected vehicle is another candidate vehicle other than the video originating vehicle.

11. The system of claim 1, wherein: The processor is further configured to set a new time limit to an amount of time remaining in the original time limit, and wherein the request relayed to the transceiver in wireless communication with the candidate vehicle is a request including the new time limit.

12. A method for video sharing, comprising: recording a video of an area of ​​interest (AOI) using a candidate vehicle camera in response to a request from a host vehicle received at the candidate vehicle via wireless transmission, the candidate vehicle including the candidate vehicle camera and performing the recording; transmitting the recorded video to a plurality of transceivers wirelessly connected to the candidate vehicles; In response to determining that the candidate vehicle camera can no longer detect the region of interest and an original time limit associated with the request has not expired, the request is sent to the plurality of transceivers.

13. The method of claim 12, wherein: The determining that the candidate vehicle camera can no longer detect the region of interest is based on a candidate vehicle position compared to the region of interest.

14. The method of claim 12, wherein: The determining that the candidate vehicle camera can no longer detect the region of interest is based on a direction of travel of the candidate vehicle causing the candidate vehicle camera to be pointed such that the candidate vehicle camera can no longer detect the region of interest.

15. The method of claim 12, further comprising: The new time limit is set to the amount of time remaining in the original time limit, and wherein sending the request includes sending the request including the new time limit.

Images