Bidirectional wireless transmission-based driving record content in-vehicle infotainment terminal viewing method

Abstract

The invention discloses a two-way wireless transmission-based driving record content in-vehicle infotainment equipment terminal viewing method, which comprises the following steps of: starting an intermediate bridging device, scanning and identifying an interconnection protocol type supported by an in-vehicle infotainment equipment by the intermediate bridging device through a first wireless communication link, and simulating the intermediate bridging device as media source equipment compatible with the interconnection protocol type; the middle bridging device establishes point-to-point wireless connection with the automobile data recorder through a second wireless communication link; the intermediate bridging device broadcasts service to the vehicle machine, and establishes a wireless session after receiving a connection response of the vehicle machine; the intermediate bridging device receives the instruction of the vehicle machine, analyzes the instruction, converts the instruction into a control command which can be executed by the automobile data recorder, and sends the control command to the automobile data recorder through a second wireless communication link; and the intermediate bridging device receives the video data stream returned by the automobile data recorder, carries out format transcoding and adaptation processing, and then pushes the video data stream to the vehicle machine through the first wireless communication link. The method has the advantage that the vehicle machine is wirelessly and directly connected with the automobile data recorder.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent vehicle electronics, more particularly, it relates to a driving record content vehicle machine end viewing method based on bidirectional wireless transmission. BACKGROUND

[0002] With the popularization of intelligent networked vehicles, the functions of vehicle infotainment systems (referred to as "vehicle machines") are increasingly rich, and wireless interconnection protocols such as Apple CarPlay, Android Auto, Huawei HiCar, and Baidu CarLife have become standard equipment for mainstream vehicles. Users can seamlessly interact between smart devices and vehicle machines through wireless means, and driving recorders have become an important demand for users. However, there are still many technical bottlenecks in the interconnection between the recorder and the vehicle machine system.

[0003] The current mainstream solution still needs to connect the driving recorder Wi-Fi hotspot through the smart phone App, and then project the video to the vehicle machine. The operation process is cumbersome, and manual switching of the hotspot, starting the App, etc. is required, and there is a safety risk of operating the phone while driving. The vehicle machine and the recorder lack native wireless interconnection capabilities. Although the vehicle machine supports wireless interconnection protocols, the closed system architecture does not open the underlying interface, and third-party devices are difficult to access directly. Some solutions attempt to bridge the vehicle machine and the recorder through wired means, but are limited by physical constraints such as the number of USB interfaces of the vehicle machine, installation location, etc., and have poor flexibility and cannot be adapted to old vehicle models without extra wired interfaces. Existing wireless transmission solutions mostly only support one-way downlink of video stream from the recorder to the mobile terminal, and cannot realize remote control of the recorder by the vehicle machine, so the user needs to manually operate the recorder body, which is not convenient. Some special bridge devices only support a single vehicle machine protocol. At the same time, the video stream format output by the driving recorder is different from the supported playback format of the vehicle machine, which may cause problems such as stuttering and decoding failure. After the driving recorder detects an emergency event such as a collision through the G-sensor, it can only lock the video file locally and cannot push a notification to the vehicle machine in time, so the user cannot view and retain key evidence in the first time. Although existing technologies attempt to realize some interconnection functions through Bluetooth and OBD interfaces, Bluetooth bandwidth is insufficient to support high-definition video stream transmission, and OBD interfaces require additional wiring and do not solve the problems of multi-protocol adaptation and bidirectional control. SUMMARY

[0004] In order to overcome the defects of the prior art that the driving recorder and the vehicle machine system lack native wireless interconnection capabilities, communication is unidirectional, and multi-protocol adaptation coverage is limited, the present application provides a driving record content vehicle machine end viewing method based on bidirectional wireless transmission.

[0005] The technical scheme of the present application is as follows: A driving record content vehicle machine end viewing method based on bidirectional wireless transmission, comprising the following steps: S1. Activate the intermediate bridging device. The intermediate bridging device scans and identifies the interconnection protocol types supported by the vehicle's infotainment system through the first wireless communication link. The intermediate bridging device simulates a media source device that is compatible with the interconnection protocol types. S2. The intermediate bridging device establishes a point-to-point wireless connection with the vehicle recorder through the second wireless communication link; S3. The intermediate bridging device broadcasts a service to the vehicle's infotainment system and establishes a wireless session after receiving the connection response from the vehicle's infotainment system. S4. The intermediate bridging device receives the instructions from the vehicle's infotainment system, parses them, converts them into control commands that the dashcam can execute, and sends them to the dashcam via the second wireless communication link. S5. The intermediate bridging device receives the video data stream returned by the dashcam and performs format transcoding and adaptation processing, then pushes it to the vehicle's infotainment system through the first wireless communication link.

[0006] Furthermore, in one embodiment, the intermediate bridging device automatically identifies the interconnection protocol type through the following process: S11. Load the built-in multi-protocol feature library, which pre-stores the mDNS service type, SSDP message identifier and device identification rules corresponding to each interconnection protocol; S12. Listen to the mDNS service or SSDP message broadcast by the vehicle's infotainment system, and extract the protocol identifier from the broadcast information for matching; S13. If the identification rule of any protocol in step S11 is matched, the intermediate bridging device determines that it is the corresponding interconnection protocol type, loads the communication driver adapted to the interconnection protocol, and calls the user interface template consistent with the native style of the interconnection protocol, encapsulates it into a display format that the vehicle system can recognize, and pushes it to the vehicle system for the user to perform touch operation.

[0007] Furthermore, in one embodiment, the interconnection protocol type in step S1 includes at least one of Apple CarPlay, Android Auto, Huawei HiCar, and Baidu CarLife; The matching is performed according to the following rules for the interconnection protocol: if the _airplay._tcp identifier is detected, it is determined to be the Apple CarPlay protocol; if the _androidauto._tcp.local identifier is detected, it is determined to be the Android Auto protocol; if the _hicar._tcp identifier or Huawei exclusive device identifier is detected, it is determined to be the Huawei HiCar protocol; if the Baidu identifier or Baidu exclusive device identifier is detected, it is determined to be the Baidu CarLife protocol.

[0008] Furthermore, in one embodiment, an emergency event linkage step is also included: when the dashcam detects a collision event, it sends an event notification and a corresponding video file index to the intermediate bridging device; the intermediate bridging device receives the event notification and the corresponding video file index, performs adaptation processing, and sends them to the vehicle infotainment system, generating a visual emergency alert on the vehicle infotainment system and displaying the corresponding timestamp.

[0009] Furthermore, in one embodiment, the instructions in step S4 include at least one of real-time video preview, historical video playback, video deletion, emergency marking, shooting parameter adjustment, and video recording lock; The intermediate bridging device converts the instructions into control commands through a bidirectional instruction mapping table. The control commands are standardized instructions that conform to the ONVIF protocol or the dashcam's proprietary API specification.

[0010] Further, in one embodiment, the format transcoding and adaptation processing in step S5 specifically involves: the intermediate bridging device first identifying the encoding format of the video stream output by the dashcam, wherein the encoding format is H.264 or H.265; if the encoding format is compatible with the vehicle's interconnection protocol, the intermediate bridging device directly optimizes the frame buffer of the video stream; if the encoding format is incompatible with the vehicle's interconnection protocol, the intermediate bridging device first decodes the video stream into raw audio and video data, and then transcodes the raw audio and video data into the target playback format supported by the vehicle's system.

[0011] Furthermore, in one embodiment, the point-to-point wireless connection in step S2 is a direct Wi-Fi connection; the intermediate bridging device scans for the target dashcam's Wi-Fi hotspot in the 2.4 / 5GHz band, automatically matches and connects using a preset SSID and password. If the connection fails, the matching connection is paused or retried several times. If it still fails after several attempts, the matching connection is terminated, and the action of scanning for the target dashcam's Wi-Fi hotspot in the 2.4 / 5GHz band is repeated until a successful matching connection is established with the target dashcam.

[0012] Furthermore, in one embodiment, after the intermediate bridging device loads the communication driver, it synchronously calls the corresponding user interface template. The layout and button style of the user interface template are consistent with the native style of the interconnection protocol, and are adapted to the vehicle touch operation logic.

[0013] Furthermore, in one embodiment, the visual emergency alert includes a pop-up notification, an audio alarm, and an icon highlight. After the user triggers the pop-up notification entry, the intermediate bridging device prioritizes loading the cached data of the corresponding emergency recording to shorten the video startup delay.

[0014] Furthermore, in one embodiment, the first wireless communication link and the second wireless communication link use different Wi-Fi operating frequency bands to avoid signal interference; the intermediate bridging device encrypts the transmitted video data stream and control commands to ensure data transmission security.

[0015] According to the above-described solution, the beneficial effects of this invention are as follows: By constructing a dual wireless communication link through an intermediate bridging device, it achieves a direct wireless connection between the vehicle's infotainment system and the dashcam, completely eliminating reliance on smartphones. Users can view videos and control the device on the vehicle's infotainment system, simplifying the operation process and avoiding the safety hazards of operating a mobile phone while driving. The intermediate bridging device can scan and identify the vehicle's interconnection protocol type and simulate compatible media source devices, effectively solving the problem of protocol incompatibility in existing technologies, resulting in stronger adaptability. Simultaneously, the device performs format transcoding and adaptation processing on the video data stream output by the dashcam, ensuring normal playback of the video on the vehicle's infotainment system and avoiding usage obstacles caused by format incompatibility. Furthermore, the entire solution adopts a fully wireless design, requiring no modification to the original vehicle wiring, making installation convenient and flexibly adaptable to aftermarket demands. It also enables bidirectional data interaction between the vehicle's infotainment system and the dashcam, allowing not only the reception of video streams but also the issuance of control commands. Compared to existing one-way communication technologies, data management efficiency is significantly improved. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the method for viewing driving record content via bidirectional wireless transmission on the vehicle's infotainment system in this embodiment. Figure 2 This is the execution flow of the method for viewing driving record content on the vehicle-mounted device using bidirectional wireless transmission in this embodiment. Figure 1 ; Figure 3 This is the execution flow of the method for viewing driving record content on the vehicle-mounted device using bidirectional wireless transmission in this embodiment. Figure 2 ; Figure 4 This is a schematic diagram showing the relationship between the dashcam, the intermediate bridging device, and the vehicle-mounted unit in this embodiment; Figure 5 This is a block diagram of the intermediate bridging device in this embodiment; Figure 6 This is a flowchart illustrating the in-vehicle infotainment user interface in this embodiment. Detailed Implementation

[0018] The present invention will now be further described with reference to the accompanying drawings and embodiments: It should be understood that those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

[0019] The specific implementation of the application is illustrated through two examples.

[0020] like Figure 1 As shown in the following embodiments, the specific implementation process of the method for viewing dashcam content on the vehicle's infotainment system based on bidirectional wireless transmission is described in detail. This embodiment is adapted to in-vehicle infotainment systems (hereinafter referred to as "vehicle infotainment systems") that support protocols such as Apple CarPlay, Android Auto, Huawei HiCar, and Baidu CarLife, and mainstream Wi-Fi direct-connect dashcams. The intermediate bridging device draws power from the vehicle's power supply through an OBD interface or a USB interface. The relationship between the dashcam, the intermediate bridging device, and the vehicle infotainment system is illustrated in the diagram below. Figure 4 As shown.

[0021] I. Prerequisites Intermediate bridging device: Includes a built-in first wireless communication module (supporting 2.4 / 5GHz Wi-Fi and the aforementioned vehicle infotainment protocols), a second wireless communication module (compatible with IEEE 802.11 a / b / g / n / ac standards), a multi-protocol adapter engine, a media transcoding and buffering unit, and a bidirectional instruction parser, conforming to... Figure 5 The functional module architecture shown; Dashcam: Works in Wi-Fi hotspot mode, supports H.264 / H.265 video encoding, can output media file index and real-time video stream, and has G-sensor collision detection function; In-vehicle infotainment system: Wireless connectivity is activated, enabling it to receive and respond to service broadcasts from external media source devices. Specific implementation steps

[0022] S1: Intermediate bridging device startup and protocol adaptation After the intermediate bridging device is activated, its first wireless communication module initializes and enables the 2.4 / 5GHz Wi-Fi band (first wireless communication link), while simultaneously activating the multi-protocol adaptation engine. This engine is then activated as follows: Figure 3The decision tree logic shown loads a built-in multi-protocol feature library (pre-stored mDNS service type and SSDP message identifier corresponding to each protocol), and extracts protocol identifiers by listening to the mDNS / SSDP signals broadcast by the vehicle's infotainment system: if the identifier "_airplay._tcp" is detected, it is determined to be the Apple CarPlay protocol; if the identifier "_androidauto._tcp.local" is detected, it is determined to be the Android Auto protocol; if the identifier "_hicar._tcp" or a Huawei-specific device ID is detected, it is determined to be the Huawei HiCar protocol; if a Baidu-specific device identifier (such as the prefix "BDCL-") is detected, it is determined to be the Baidu CarLife protocol. After the protocol identification is completed, the intermediate bridging device simulates a compatible media source device of the corresponding protocol to prepare for the subsequent connection with the vehicle's infotainment system. This process corresponds to... Figure 2 The step is "Initialize the first wireless communication module".

[0023] S2: The intermediate bridging device establishes a wireless connection with the dashcam. The intermediate bridging device's second wireless communication module initiates a 2.4GHz / 5GHz dual-band scan (second wireless communication link) to search for Wi-Fi hotspots broadcast by the dashcam. The intermediate bridging device has a built-in preset SSID and encryption password for the target dashcam and automatically initiates a connection request: upon successful connection, it immediately obtains the dashcam's media file index (including video filenames, recording timestamps, etc.) and establishes a real-time video stream transmission channel; if the connection fails, it proceeds as follows... Figure 2 The exception handling logic shown initiates a retry mechanism: the initial retry interval is 1 second, increasing by 0.5 seconds each time, with a maximum interval of 5 seconds, and a cumulative retry of 3 times; if it still fails, the scan is paused, or the user can be prompted to manually enter the SSID and password through the vehicle interface after the vehicle is connected in step S3.

[0024] S3: The vehicle's infotainment system establishes a wireless session with the intermediate bridge device. After the intermediate bridging device completes protocol adaptation, it broadcasts media services to the vehicle's infotainment system via the first wireless communication link. The broadcast content includes the device identifier, protocol type, and service capability description. Once the user sees the service option on the vehicle's infotainment interface and clicks "confirm," the system returns a connection response to the intermediate bridging device. Both parties then establish an encrypted wireless session based on the corresponding vehicle infotainment protocol, thus establishing a data transmission channel. This process corresponds to... Figure 2 The process branch is "Broadcast vehicle-mounted unit compatibility service, establish session".

[0025] S4: Vehicle-mounted system command parsing and forwarding After the wireless session is established, the bidirectional command parser of the intermediate bridging device continuously listens for user operation commands from the vehicle's infotainment system (including real-time video preview, historical video playback, video deletion, emergency marking, shooting parameter adjustment, recording lock, etc.). Figure 6 The control button functions on the vehicle's infotainment screen correspond to the following: When the user clicks the "Playback Video" command on the vehicle's large screen: After receiving the command, the intermediate bridging device parses the command type (historical video playback) through a two-way command mapping table; it converts it into a control command that the dashcam can execute: standard functions use the ONVIF protocol format, while dashcam-specific functions (such as recording lock) use their proprietary API format; the control command is encrypted and sent to the dashcam via a second wireless communication link to ensure secure command transmission.

[0026] S5: Video Stream Transcoding Adaptation and In-Vehicle Display After receiving the control command, the dashcam retrieves the video data stream (H.265 encoded) for the corresponding time period and returns it to the intermediate bridging device via the second wireless communication link. The media transcoding and caching unit processes the data according to the following logic: It identifies the video stream encoding format as H.265 and determines its compatibility with the current vehicle infotainment protocol (such as Android Auto). If the format natively supported by Android Auto is incompatible with the H.265 format, transcoding is required. First, the H.265 video stream is decoded into raw audio and video data, then transcoded to a format natively supported by Android Auto. Frame buffering optimization is performed on the transcoded video stream to reduce playback latency. Finally, the processed video stream is pushed to the vehicle infotainment system via the first wireless communication link, and the vehicle infotainment system processes the data as follows: Figure 6 The interface layout shown displays the video, and users can perform operations such as fast forward, rewind, and screenshot through the vehicle's touch control bar to achieve an interactive experience.

[0027] like Figures 2-6 As shown in the following embodiments, the complete implementation of the method for viewing vehicle recording content on the vehicle's infotainment system based on bidirectional wireless transmission is as follows: taking an in-vehicle infotainment system that supports the Apple CarPlay protocol and an H.265 encoded dashcam as the application scenario.

[0028] I. Prerequisites Hardware configuration: The intermediate bridging device integrates a first wireless communication module (supporting 2.4 / 5GHz Wi-Fi and multiple vehicle infotainment protocols such as Huawei HiCar / Apple CarPlay / Android Auto / Baidu CarLife), a second wireless communication module (compatible with IEEE 802.11 a / b / g / n / ac standards), a multi-protocol adapter engine, a media transcoding and buffering unit, a bidirectional instruction parser, and a power management module (powered via the OBD-II interface), conforming to... Figure 3The functional module architecture is shown below; Peripheral status: The dashcam operates in Wi-Fi hotspot mode, broadcasting SSID as "XXX", preset password as "12345678", supports H.265 encoded output, and has a built-in G-sensor collision detection module; Vehicle status: The in-vehicle infotainment system has activated Apple CarPlay wireless connectivity, can broadcast SSDP messages and device identifiers, and supports touch operation and pop-up display.

[0029] II. Complete Implementation Steps (I) S1: Intermediate Bridging Device Startup, Protocol Identification and UI Adaptation The intermediate bridging device starts up after obtaining vehicle power through the OBD-II interface or USB port, and completes protocol identification and adaptation according to the following process: The first wireless communication module initializes and activates the multi-protocol adaptation engine, loading the built-in multi-protocol feature library. This feature library pre-stores the identification rules corresponding to the four major protocols: Apple CarPlay corresponds to the mDNS service type "_airplay._tcp", Android Auto corresponds to the mDNS service type "_androidauto._tcp.local", Huawei HiCar corresponds to the mDNS service type "_hicar._tcp" and Huawei's exclusive device identifier (device ID prefix "HiCar-XXXX"), and Baidu CarLife corresponds to Baidu's exclusive device identifier ("BDCL-XXXX"). The first wireless communication module switches to monitoring mode (the first wireless communication link enables the 2.4 / 5GHz Wi-Fi band), continuously captures the SSDP messages broadcast by the vehicle's infotainment system, and extracts the protocol identifier field "_airplay._tcp" and the device ID "CarPlay-xxx" from them; According to Figure 3 The decision tree logic matches the protocol rules. Upon detecting the "_airplay._tcp" identifier and the CarPlay-specific device identifier, it determines that the vehicle's infotainment system supports the CarPlay protocol. It then loads the communication driver adapted for CarPlay and simultaneously calls the corresponding user interface template—this template uses a HarmonyOS card-style layout, with the video list displayed as timeline cards. The core function buttons (play, rewind, lock, delete) are adapted to the vehicle's touch logic, and the button spacing is increased to accommodate driving operations. The intermediate bridging device encapsulates the UI template into a format recognizable by the CarPlay protocol and pushes it to the vehicle's infotainment system via the first wireless communication link. The vehicle's infotainment system then... Figure 6 The interface layout shown indicates that initialization and adaptation are complete.

[0030] (ii) S2: The second wireless communication module of the intermediate bridging device is activated and establishes a point-to-point wireless connection according to the following procedure (the second wireless communication link uses the 2.4 / 5GHz Wi-Fi band and is adjusted to a different Wi-Fi channel than the first communication link to avoid interference): The second wireless communication module simultaneously scans for Wi-Fi hotspots in the 2.4GHz / 5GHz bands, filters out the target dashcam's SSID "XXX", and automatically calls the preset password "12345678" to initiate a connection request. The first connection fails due to signal interference causing authentication timeout. A retry mechanism is initiated: the matching connection is paused for 1 second before the first retry, the interval increases to 1.5 seconds for the second retry, and the interval increases to 2 seconds for the third retry. If the third retry is successful, a Wi-Fi direct connection is established, and the intermediate bridging device immediately obtains the dashcam's media file index (including video file name, recording timestamp, file size, etc.) and establishes a real-time video stream transmission channel.

[0031] (III) S3: The vehicle-mounted infotainment system establishes a wireless session with the intermediate bridging device. The intermediate bridging device broadcasts "Driving record viewing service" to the vehicle-mounted infotainment system via the first wireless communication link. The broadcast content includes the device identifier, CarPlay protocol type, and service capability description. After the user clicks the service option on the vehicle-mounted infotainment system interface, the system returns a connection response. Both parties establish an encrypted wireless session based on the CarPlay protocol, opening the data transmission channel, as shown below. Figure 2 The process from "broadcast vehicle head unit compatibility service to session establishment" in China.

[0032] (iv) S4: Vehicle-mounted command parsing and forwarding After the wireless session is established, the bidirectional command parser of the intermediate bridging device continuously listens for user operation commands on the vehicle's infotainment system. Specifically, the user clicks "Lock the video recorded on 2025-12-04 14:30" (a historical video playback command) on the vehicle's UI. The vehicle generates a corresponding operation command and sends it to the intermediate bridging device. Upon receiving the command, the bidirectional command parser queries its built-in bidirectional command mapping table, determines that the command is a standard function, and converts it into a control command conforming to the ONVIF protocol. Subsequently, the user clicks "Adjust the recorder resolution to 1080P" (a shooting parameter adjustment command). The parser determines that this command is a function specific to the dashcam and converts it into a control command in its proprietary API format. The intermediate bridging device encrypts and sends the control command to the dashcam via a second wireless communication link. After the dashcam executes the operation, it returns a "Successful Operation" response. The bridging device pushes the response result to the vehicle's infotainment system, which then displays a pop-up message indicating "Operation Complete."

[0033] (v) S5: Video format transcoding and adaptation push The dashcam returns the corresponding video data stream (real-time video stream or historical video stream) according to the vehicle's instructions. The media transcoding and caching unit of the intermediate bridging device processes the data according to the following rules: After receiving the historical video stream, it first identifies the encoding format as H.265, queries the protocol adaptation rules, and determines that the H.265 format is incompatible with the CarPlay protocol; it first decodes the H.265 video stream into raw audio and video data, and then transcodes it into the HLS format supported by the CarPlay protocol; it negotiates the vehicle's CPU clock speed to 1.8GHz and dynamically adjusts the bitrate of the transcoded video stream to 4Mbps; it optimizes the frame caching of the transcoded HLS video stream, caching the most recent 30 frames to reduce playback latency; and it pushes the processed video stream to the vehicle's infotainment system via the first wireless communication link. The vehicle's infotainment system displays the video, and the user can perform fast forward and rewind operations via the touch control bar, achieving seamless interaction.

[0034] (vi) Emergency Response Procedures When a sudden collision occurs during driving, the dashcam's G-sensor detects an acceleration of 1.2g (exceeding the threshold), immediately classifying it as a collision event. It locks the currently recorded video (to prevent overwriting), generates an event notification (including a "collision event" identifier and timestamp) and the corresponding video file index, and sends it to the intermediate bridging device via a second wireless communication link. The intermediate bridging device receives and adapts the data, extracts the timestamp information, generates standardized emergency alert data, and pushes it to the vehicle's infotainment system via the first wireless communication link. The vehicle's infotainment system immediately triggers a visual emergency alert: a floating pop-up window displays "..." Emergency video has been saved! Do you want to view it immediately? [Yes][No] Figure 6 (Example of a pop-up window), a 3-second low-volume alarm sound is played simultaneously, and the corresponding item in the video list is highlighted in red; after the user clicks "Yes", the intermediate bridging device prioritizes loading the cached data of the emergency recording, with a startup delay of ≤0.5 seconds, enabling quick viewing.

[0035] (vii) Data transmission security and anti-interference guarantee Throughout the implementation process, the communication link uses the 2.4 / 5GHz Wi-Fi band (to transmit video streams and ensure high bandwidth). The first and second wireless communication links use different Wi-Fi bands (to transmit control commands and ensure connection stability). Frequency band isolation avoids signal interference. All video data streams and control commands are encrypted, and the key is dynamically negotiated and generated through the vehicle's local area network to ensure that the data transmission process is not stolen or tampered with, thus protecting privacy and data integrity.

[0036] Therefore, as can be seen from the above embodiments, this invention addresses the core pain points of existing in-vehicle dashcam viewing technologies, such as reliance on smartphones, protocol incompatibility, one-way communication, and complex modifications. It proposes an innovative solution with an intermediate bridging device, dual wireless communication links, and end-to-end adaptation optimization. Its core logic is as follows: using an intermediate bridging device as a hub, one end establishes a point-to-point Wi-Fi direct connection with the dashcam, while the other end identifies the mainstream interconnection protocols supported by the in-vehicle system and simulates compatible media sources, achieving bidirectional wireless communication between the in-vehicle system and the dashcam. The core innovation of this invention lies in breaking through the closed nature of in-vehicle systems, eliminating the need to modify the original vehicle wiring, and achieving direct, smartphone-free interaction through key technologies such as multi-protocol automatic identification, command parsing and conversion, and video format transcoding adaptation. Users can perform real-time preview, historical playback, recording lock, parameter adjustment, and other full-scenario operations on the in-vehicle large screen. It also supports emergency alerts for collision events, balancing driving safety, ease of operation, and compatibility, perfectly meeting the diverse needs of the aftermarket automotive electronics market. The entire technical solution has a closed-loop process and coherent logic. Each step (protocol identification → connection establishment → session setup → command interaction → video push) is deeply coupled with the functional modules of the intermediate bridging device. All technical features have clear implementation paths, conform to the conventional understanding and technical implementation logic of those skilled in the art, and can be accurately reproduced.

[0037] Finally, it should be noted that the intermediate bridging device in this application is not an abstract concept or an undisclosed innovative hardware, but a feasible device formed by modular integration and logic adaptation based on existing mature technologies in the field. Those skilled in the art can accurately reproduce it using conventional technical means. From the perspective of core modules, the first / second wireless communication modules can use commercially available mature Wi-Fi chips. These chips natively support IEEE 802.11 a / b / g / n / ac standards and 5GHz / 2.4GHz dual-band, and are compatible with the communication requirements of protocols such as CarPlay, Android Auto, HiCar, and Carlife, which are standard choices for in-vehicle wireless devices. The core logic of the multi-protocol adaptation engine (mDNS / SSDP monitoring, protocol feature library matching) can be implemented by porting existing open-source protocol stacks. The media transcoding and caching unit can use dedicated hardware transcoding chips, which natively support H.264 / H.265 decoding and encoding. Frame buffer optimization can be implemented through embedded memory management technology; related solutions are already very mature in in-vehicle video players. The instruction mapping table and protocol conversion logic of the bidirectional instruction parser can be developed based on the ONVIF protocol specification and the private API documentation publicly available by dashcam manufacturers, which is a standard technical means for device interconnection. The power management module adopts an OBD-II / USB-C power supply solution, adapted to a vehicle 12V power supply to 5V / 2A output, and the relevant power chips and power supply interfaces are all standard components in the automotive electronics field. Encryption processing uses the AES-128 algorithm, which can be implemented by integrating an open-source encryption library without additional innovation. In summary, all modules of the intermediate bridging device are based on existing mature hardware and software technologies, and the selection, integration, and working logic of each module are within the conventional understanding and capabilities of those skilled in the art, meeting the requirements of sufficient disclosure and feasibility.

[0038] The present invention has been described above with reference to the accompanying drawings. Obviously, the implementation of the present invention is not limited to the above-described manner. Any improvements made using the inventive concept and technical solution of the present invention, or the direct application of the inventive concept and technical solution of the present invention to other situations without modification, are all within the protection scope of the present invention.

Claims

1. A method for viewing driving recorder content on a vehicle-mounted infotainment system based on bidirectional wireless transmission, characterized in that, Includes the following steps: S1. Activate the intermediate bridging device. The intermediate bridging device scans and identifies the interconnection protocol types supported by the vehicle's infotainment system through the first wireless communication link. The intermediate bridging device simulates a media source device that is compatible with the interconnection protocol types. S2. The intermediate bridging device establishes a point-to-point wireless connection with the vehicle recorder through the second wireless communication link; S3. The intermediate bridging device broadcasts a service to the vehicle's infotainment system and establishes a wireless session after receiving the connection response from the vehicle's infotainment system. S4. The intermediate bridging device receives the instructions from the vehicle's infotainment system, parses them, converts them into control commands that the dashcam can execute, and sends them to the dashcam via the second wireless communication link. S5. The intermediate bridging device receives the video data stream returned by the dashcam and performs format transcoding and adaptation processing, then pushes it to the vehicle's infotainment system through the first wireless communication link.

2. The method for viewing driving record content on a vehicle-mounted terminal based on bidirectional wireless transmission according to claim 1, characterized in that, The intermediate bridging device automatically identifies the interconnection protocol type through the following process: S11. Load the built-in multi-protocol feature library, which pre-stores the mDNS service type, SSDP message identifier and device identification rules corresponding to each interconnection protocol; S12. Listen to the mDNS service or SSDP message broadcast by the vehicle's infotainment system, and extract the protocol identifier from the broadcast information for matching; S13. If the identification rule of any protocol in step S11 is matched, the intermediate bridging device determines that it is the corresponding interconnection protocol type, loads the communication driver adapted to the interconnection protocol, and calls the user interface template consistent with the native style of the interconnection protocol, encapsulates it into a display format that the vehicle system can recognize, and pushes it to the vehicle system for the user to perform touch operation.

3. The method for viewing driving record content on a vehicle-mounted terminal based on bidirectional wireless transmission according to claim 2, characterized in that, The interconnection protocol type in step S1 includes at least one of Apple CarPlay, Android Auto, Huawei HiCar, and Baidu CarLife; The matching is performed according to the following rules for the interconnection protocol: if the _airplay._tcp identifier is detected, it is determined to be the Apple CarPlay protocol; if the _androidauto._tcp.local identifier is detected, it is determined to be the Android Auto protocol; if the _hicar._tcp identifier or Huawei exclusive device identifier is detected, it is determined to be the Huawei HiCar protocol; if the Baidu identifier or Baidu exclusive device identifier is detected, it is determined to be the Baidu CarLife protocol.

4. The method for viewing driving record content on a vehicle-mounted terminal based on bidirectional wireless transmission according to claim 1, characterized in that, It also includes an emergency event linkage step: when the dashcam detects a collision event, it sends an event notification and the corresponding video file index to the intermediate bridging device; The intermediate bridging device receives the event notification and the corresponding video file index, performs adaptation processing, and sends them to the vehicle's infotainment system. A visual emergency alert is generated on the vehicle's infotainment system, and the corresponding timestamp is displayed.

5. The method for viewing driving record content on a vehicle-mounted terminal based on bidirectional wireless transmission according to claim 1, characterized in that, The instructions in step S4 include at least one of the following: real-time video preview, historical video playback, video deletion, emergency marking, shooting parameter adjustment, and video recording lock. The intermediate bridging device converts the instructions into control commands through a bidirectional instruction mapping table. The control commands are standardized instructions that conform to the ONVIF protocol or the dashcam's proprietary API specification.

6. The method for viewing driving record content on a vehicle-mounted terminal based on bidirectional wireless transmission according to claim 1, characterized in that, The format transcoding and adaptation process in step S5 specifically involves the following steps: The intermediate bridging device first identifies the encoding format of the video stream output by the dashcam, which is either H.264 or H.

265. If the encoding format is compatible with the vehicle's interconnection protocol, the intermediate bridging device directly optimizes the frame buffer of the video stream. If the encoding format is incompatible with the vehicle's interconnection protocol, the intermediate bridging device first decodes the video stream into raw audio and video data, and then transcodes the raw audio and video data into the target playback format supported by the vehicle's interconnection protocol.

7. The method for viewing driving record content on a vehicle-mounted terminal based on bidirectional wireless transmission according to claim 1, characterized in that, The point-to-point wireless connection in step S2 is a direct Wi-Fi connection; the intermediate bridging device scans for the target dashcam's Wi-Fi hotspot in the 2.4 / 5GHz band, automatically matches and connects using a preset SSID and password. If the connection fails, the matching connection is paused or retried several times. If it still fails after several attempts, the matching connection is terminated, and the scanning for the target dashcam's Wi-Fi hotspot in the 2.4 / 5GHz band is repeated until a successful matching connection with the target dashcam is achieved.

8. A method for viewing driving record content on a vehicle-mounted terminal based on bidirectional wireless transmission according to claim 2, characterized in that, After the intermediate bridging device loads the communication driver, it synchronously calls the corresponding user interface template. The layout and button style of the user interface template are consistent with the native style of the interconnection protocol, and are adapted to the vehicle touch operation logic.

9. A method for viewing driving recorder content on a vehicle-mounted terminal based on bidirectional wireless transmission according to claim 4, characterized in that, The visual emergency alert includes pop-up notifications, sound alarms, and icon highlighting. After the user triggers the pop-up notification entry, the intermediate bridging device prioritizes loading the cached data of the corresponding emergency recording to shorten the video startup delay.

10. A method for viewing driving record content on a vehicle-mounted terminal based on bidirectional wireless transmission according to claim 1, characterized in that, The first wireless communication link and the second wireless communication link use different Wi-Fi operating frequency bands to avoid signal interference; the intermediate bridging device encrypts the transmitted video data stream and control commands to ensure data transmission security.

Images